Every AI product spent 2024 and 2025 building its own integration format. Each one had a different way of declaring what a tool could do, a different auth story, and a different set of clients that supported it. If you built a service and wanted assistants to reach it, you built the same integration several times and maintained all of them.
The Model Context Protocol is the answer to that. It is a specification for how an AI client talks to a service it does not own: how it discovers what tools exist, how it authenticates, and how it calls them.
Practically, it means a service implements one server and every MCP-capable client can use it. That is the whole pitch, and it is enough.
Local servers and remote servers
Most early MCP servers were local: a process running on your machine that the client launched and spoke to over stdin and stdout. Good for developer tooling, awkward for a product. It means the user installs something, keeps it updated, and runs it on every device they want the integration on. A phone is out of the question.
A remote MCP server is an HTTP endpoint. The client connects to a URL over the internet and authenticates with OAuth. Nothing is installed, nothing is kept updated, and the same connection works from the desktop app, the web app and the phone.
For a hosted product this is the only sensible shape, and it is what EvyOS ships: one URL, https://api.evyos.com/mcp, that ChatGPT and Claude both connect to from the same paste.
How the connection actually happens
The part people find surprising is how little of it you do.
You paste the URL. That is genuinely all the user-facing setup, and the reason it works is a short chain of discovery:
- The client calls the endpoint with no credentials, and gets a 401 carrying a
WWW-Authenticateheader that points at the protected-resource metadata. This one header is the entire mechanism by which a client learns where to authenticate — leave it off and the connector fails with no explanation the user can act on. - From that metadata the client finds the authorization server, then registers itself under RFC 7591 dynamic client registration. No developer signs up for anything; the client provisions its own credentials.
- It starts a PKCE flow. Your browser opens the service, you sign in normally, and a consent screen names the app that asked and the scopes it wants.
- You approve, and the client receives a token it can refresh.
Notice what did not happen: you never generated an API key, never pasted a secret into a chat interface, and never gave the AI client your password or your session. That matters, because a long-lived key pasted into a third-party tool is a credential you cannot rotate, cannot scope, and will forget you issued.
Why "one URL" is a design constraint, not a slogan
It is tempting to publish a setup guide instead: here is the endpoint, here is the client id, here is where to paste the secret. It works, and roughly nobody completes it.
The single-URL flow only holds together if every piece of discovery is correct — the challenge header, the metadata documents, the registration endpoint, the issuer identity. Each of those is a place where a small mistake produces a failure with no useful error at all: the client just says it could not connect. Getting them all right is most of the work of shipping a connector, and it is invisible when it works.
What a productivity MCP server should expose
A read-only server is a demo. If the assistant can tell you what is overdue but cannot move anything, you are still doing the typing, and the typing was the problem.
The EvyOS server declares 57 tools across every record type in the product: tasks including subtasks and comments, projects and their milestones, goals, habits, skills with practice logging, notes and folders, and calendar events. Plus evyos_get_today, which answers overdue, due-today, habits and calendar in a single call, and evyos_search for when the model needs an id and should not be guessing.
Two design details are worth stealing if you are building one of these.
Prefer specific tools to generic updates. evyos_complete_task rather than "set status to done". A model choosing between eight verbs makes fewer mistakes than a model constructing a partial update, and the specific tool can carry the side effects — logging the completion, invalidating the right caches — that a generic setter would miss.
Send the model the domain once, at connection time. The server's instructions explain how the records relate: goals hold projects, projects hold tasks, a task with no project is in the inbox, completing a habit is a per-day record rather than a status change, deleting is not the same as finishing. A model that knows the shape of the data asks far better questions than one inferring it from tool names.
The part that keeps it honest
The failure mode for this kind of integration is drift. The connector reimplements a bit of product logic, the real endpoint changes, and six months later creating a task through the assistant behaves subtly differently from creating one in the app — different validation, no activity log entry, a quota that does not apply.
The way out is to not reimplement anything. Every tool call in EvyOS is dispatched as an in-process request against the same application that serves the web app, through an ASGI transport. Quotas, workspace scoping, activity logging and cache invalidation are inherited from the real route rather than reproduced beside it. Adding a tool is adding a declaration, not adding a code path.
It also means a new API endpoint becomes a new tool almost for free, which is the difference between a connector that keeps up with the product and one that quietly rots.
What to check before you connect one to your data
Whatever product you are connecting, four questions:
- Does it use OAuth, or does it want a pasted key? A key you paste into a chat client is a credential you cannot scope and will forget about.
- Can you see and revoke connections? There should be a list, it should show when each connection was last used, and revoking should kill every token under it immediately.
- Can a connected app authorise another one? It should not be able to. If holding one integration's token is enough to mint a second integration's access, one compromised client is all of them.
- What happens on a delete? Soft deletes and a model told to prefer completing over removing are cheap safeguards, and their absence is a real risk once something can act on your data.
Where to go next
The EvyOS MCP server page has the full tool catalogue, the scopes, the transport details and how the tokens are stored. If you would rather see what it feels like than how it works, run EvyOS from ChatGPT and Claude covers the same ground from the user's side, and how to make ChatGPT actually useful for your to-do list is the practical version.