What this MCP server does

This is a small remote Model Context Protocol server run by one person, its owner. Its MCP endpoint is https://mcp.gov-evo.org/mcp. It speaks MCP revision 2026-07-28 and also answers clients of 2025-11-25. Every MCP request needs an OAuth access token issued by this server for that endpoint.

Tools

• memo_write saves a plain-text note (up to 10000 characters) for the signed-in user and returns its id.
• memo_search finds that user's notes: a note matches when it contains every word of the query, ignoring case and accents; an empty query lists the newest. It returns up to 50 notes, newest first, each with id, text and created_at.
• upload stores a file and returns a url on this host. That link is public: anyone who has it can open the file without signing in. The link holds a random 32-character id, so it cannot be guessed, but it can be shared. Input: filename, content_base64 (the bytes, base64) and content_type; at most 2 MB once decoded. Files are served with a sandboxing Content-Security-Policy, so an uploaded page cannot run scripts on this host.
• transcribe takes the url of an audio file on the public internet (https only, at most 25 MB) and returns segments, each with start and end in seconds and the text. The server downloads the file itself, refusing private and local network addresses and any redirect to one, and sends it to OpenAI's speech-to-text API (model whisper-1). OpenAI receives the audio under its own API data terms; this server keeps neither the audio it downloads from a link nor the transcript (a file uploaded with upload stays, as below). The server sends at most 30 files to OpenAI per UTC day, counting every client together and failed calls too; past that, transcribe answers that the daily limit is reached and that it resets at 00:00 UTC.

Every tool result is structured content that matches the output schema the tool declares, plus the same JSON as text. A mistake the caller can fix comes back as a tool error that says how; a server fault comes back only as a reference id.

How sign-in works

This server is its own OAuth 2.1 authorization server. Discovery starts from the WWW-Authenticate header of a 401 on /mcp, which points to the protected resource document at https://mcp.gov-evo.org/.well-known/oauth-protected-resource/mcp.

• Any MCP client may identify itself, either by a Client ID Metadata Document (its client_id is an https URL) or by dynamic client registration. Registering lets a client ask; it does not let it in.
• Only the owner can let a client in. There is one account, the owner's; sign-up is closed. The owner signs in with a password and then approves or denies the client on a consent page that names it. Nobody else can sign in, so nobody else can grant access.
• The authorization code flow requires PKCE with S256. Access tokens are signed JWTs bound to the https://mcp.gov-evo.org/mcp resource (RFC 8707); a token issued for any other audience is refused. Access tokens last one hour; a client that asked for offline_access also gets a refresh token.
• All clients the owner approves act for the same user, so they see the same notes and files.

What data it keeps, and for how long

• Notes: the text and the time it was saved, per user, until the owner deletes them on the server. There is no automatic expiry.
• Uploaded files: the bytes, the file name and media type, until the owner deletes them on the server. The link stays public while the file exists.
• Sign-in records: the owner's account with a password hash (never the password), browser sessions (7 days), registered OAuth clients and their metadata (until the owner removes them), the owner's consents, authorization codes (10 minutes, single use), refresh tokens (30 days, replaced on each use) and the server's token signing keys. Access tokens for /mcp are signed JWTs and are not stored; each is valid for one hour. A client that names no resource gets an opaque access token instead, which /mcp refuses; that one is stored only as a hash.
• Logs, as JSON lines: one line per request with the method, path (no query string) and status; a reference id with the error message for server faults; the sign-in library's own warnings and errors (auth_warn, auth_error), such as "Invalid password", with their message (and, for an error, its detail); and the requests the MCP library rejects and the errors it reports while serving one (mcp_error), with its message, which may quote a protocol name a client sent, such as a method or tool name or a protocol version. Tool arguments (note text, file contents, audio, links), tokens and passwords are never logged, except as part of a request path or a protocol name a client sent (a file link's path holds its file name), as the host of a transcribe link that a failed download's error may name, or inside a redirect address a client sent to the sign-in API that the library refuses as untrusted: its auth_error line quotes that whole address, query included.
• Audio given to transcribe is held in memory for that one call and not stored; the transcript is returned and not stored.

Everything lives on one server (SQLite and plain files) run by the owner. There is no analytics and no third party except OpenAI for transcribe calls.