Files

T

retoor 251c3dc2ba research: mcp-client-support subject (106 sources, 3 conclusions)

- wire spec: lifecycle, stdio + Streamable HTTP transports, tools,
  utilities, legacy SSE, versioning, changelog (14 Tier 1)
- client ecosystem: Claude Code/VS Code/Cursor/Codex configs,
  mcp-remote, Smithery, registries, Glama (12 Tier 1)
- security/ops: authorization draft, trust model, poisoning,
  rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards
- conclusions: minimal stdlib client on 2025-11-25, normalizer +
  resolver agent for pasted configs/GitHub URLs, untrusted-until-
  consent trust model; nothing built yet
- audit PASS (14 subjects, 797 sources, 32 conclusions)

2026-10-18 19:23:02 +02:00

2.9 KiB

Raw Blame History

Specification - Model Context Protocol

Metadata

Field	Value
Institute	Molodetz Institute - Research & Retrieval Division
Subject	mcp-client-support
Document type	Source Dossier
Tier	1
Source title	Specification - Model Context Protocol
Source URL	https://modelcontextprotocol.io/specification/draft/index
Source publisher / author	MCP specification authors
Source type	standard
Source date (published)	Unknown - not stated (draft)
Date researched	2026-10-18
Researched by	tai (agent), model: Claude Sonnet 5, on behalf of retoor
Research method	gather-subagent direct page fetch, parent synthesis from evidence pack
Confidence	High
Status	Active

Summary

The draft spec's Security and Trust and Safety section places consent and data-handling duties on hosts: explicit user consent before tool invocation, treating tool behavior descriptions as untrusted unless from a trusted server, consent before exposing user data, and no onward transmission of resource data without consent. In the same passage it admits MCP itself cannot enforce these principles at the protocol level, and asks implementors to build consent flows, documentation, access controls, best practices, and privacy handling instead.

Key findings

"Hosts must obtain explicit user consent before invoking any tool" and "Users should understand what each tool does before authorizing its use."
"descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server."
"Hosts must obtain explicit user consent before exposing user data to servers" and hosts "must not transmit resource data elsewhere without user consent."
The unenforceability admission: "While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: 1. Build robust consent and authorization flows..." plus documentation, access controls, best practices, and privacy protections.

Pros / strengths

States the consent mandate plainly, covering tools, user data, and resource data in one place.
The untrusted-annotations rule directly justifies client-side distrust of tool descriptions.
Honest about the enforcement gap instead of implying the protocol handles it.

Cons / limitations / caveats

"Trusted server" is never defined, so the annotations exception has no testable meaning.
No consent UX shape is specified (what the user must see, per-call vs per-session), leaving the hard design work to each client.
The SHOULD list is advisory; two compliant clients can offer very different real protection.

Relevance to tai

This is the spec's consent mandate vs. reality gap in one paragraph: consent is required of hosts but explicitly unenforceable by the protocol, so the tai client must build it.

Changelog

Date	Change
2026-10-18	Initial dossier created.

2.9 KiB Raw Blame History