new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

MCP Server Development in Practice · all subjects

Client differences

5 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Server works in Claude Code but not Cursor — why?

Almost always one of these: (1) Transport — the client expects stdio or an older SSE setup while you only speak streamable HTTP, or vice versa; check which transports that client version supports. (2) Auth — the client only supports OAuth flows, or only static headers, and you offered the other; Cursor historically lagged Claude Code on header-based auth for remote servers. (3) Config format — each client has its own JSON shape (mcpServers vs mcp.servers vs UI-only setup), and a config that parses in one is ignored in another. (4) Tool count/context limits truncating your tool list. Debug order: confirm the client's supported transport in its current docs, then its auth method, then test with a one-tool server to isolate config from protocol.

Which MCP features can I rely on across clients as of early 2026?

Tools are universal — every meaningful client calls tools; build your core value there. Everything else is patchwork and you must test per client before depending on it: resources and prompts are supported in some clients, ignored in others; roots (client telling the server which directories it may see) are implemented unevenly; sampling (server asking the client's model for a completion) is supported by few clients and often gated behind user consent; elicitation (server asking the user for structured input mid-tool, added in 2025-06-18) is newer still. Practical rule: ship tools-only first, expose resources/prompts as progressive enhancement, and never design a flow that REQUIRES sampling or elicitation unless you control which client runs it.

Does the model or the client decide when my tool fires?

The model decides per-call, but the client decides what the model sees and is allowed to do — that split explains most 'works here, not there' mysteries. Clients differ in: whether tools are auto-approved or need per-call user consent (Claude Code has permission modes; Cursor has its own approval settings; a tool the user must approve every time effectively never fires); how many tools are injected before truncation; and system-prompt nudges that bias toward or against tool use. Two servers with identical tool lists can therefore behave differently across clients with the same underlying model. When debugging 'the agent ignores my tool', first rule out an approval prompt sitting unanswered in the UI — it looks identical to the model declining the call.

ChatGPT connectors and Codex — what do they expect from my server?

ChatGPT's deep-research connectors impose a specific contract rather than a generic tool list: they expect tools named `search` (taking a query, returning a list of id/title/url results) and `fetch` (taking an id, returning the full document) — deviate from that shape and the connector indexes nothing, even though your server is perfectly valid MCP. Codex CLI reads its own config (config.toml, not the Claude/Cursor JSON), supports stdio and streamable HTTP servers, and passes tool results into its own context management. As of early 2026 these integrations change monthly: pin your expectations by testing against the current client, and keep a `search`/`fetch`-compatible pair on any server you want ChatGPT to use — it costs you two thin wrappers.

My server exposes prompts and resources — why don't users see them?

Because clients surface them inconsistently. Slash-command style prompt discovery exists in some clients (Claude Code surfaces MCP prompts as commands), while others ignore prompts entirely or bury resources behind a UI nobody opens. The silent failure: your server reports capabilities at initialize, the client accepts them, and nothing ever calls prompts/list — no error anywhere. If a feature matters, implement it as a tool first (tools are the only universally-invoked primitive), then mirror it as a prompt/resource for clients that support it. Check capability support per client version before filing a bug against your own server — as of early 2026, the support matrix still differs release to release.

Give your agent this brain