{
  "run_id": "exa-labs--exa-mcp-server-claude-haiku-5-5-1792794299081156372",
  "checker": {
    "claims": [
      {
        "claim": "The hosted MCP server offers web search anonymously",
        "command": " tools/call {\"tool\": \"web_search_exa\", \"arguments\": {\"query\": \"Model Context Protocol specification\"}}",
        "evidence": "Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you\u2019re building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need. This specification defines the authoritative protocol requirements, based on the TypeScript schema in schema.ts. For implementation guides and examples, visit modelcontextprotocol.io. The key words \u201cMUST\u201d, \u201cMUST NOT\u201d, \u201cREQUIRED\u201d, \u201cSHALL\u201d, \u201cSHALL NOT\u201d, \u201cSHOULD\u201d, \u201cSHOULD NOT\u201d,",
        "expected": "Search results with MCP text returned by web_search_exa",
        "input": "{\"tool\": \"web_search_exa\", \"arguments\": {\"query\": \"Model Context Protocol specification\"}}",
        "kind": "claim",
        "outcome": "Real input produced the expected result: Model Context Protocol (MCP) is an open protocol",
        "source": "The hosted MCP server works anonymously with rate limits.",
        "source_checked": true,
        "source_file": "README.md",
        "verdict": "yes"
      }
    ],
    "cycle_checks": [
      {
        "claim": "Scheduled or looping main behavior",
        "command": "",
        "evidence": "Entry points inspected (README, package.json scripts, src/stdio-cli.ts, src/runtime-server.ts, api/): the product is an MCP server that answers tool calls on request. No cron, scheduler, loop, webhook, --once or --now trigger exists in README or source; the only schedules are in .github/workflows CI, which are not product cycles.",
        "expected": "identify the product trigger",
        "input": "source inspection",
        "kind": "cycle",
        "outcome": "Entry points inspected (README, package.json scripts, src/stdio-cli.ts, src/runtime-server.ts, api/): the product is an MCP server that answers tool calls on request. No cron, scheduler, loop, webhook, --once or --now trigger exists in README or source; the only schedules are in .github/workflows CI, which are not product cycles.",
        "source": "repository entry points",
        "verdict": "yes"
      }
    ],
    "details": {
      "hosting": "remote",
      "kind": "mcp_http",
      "protocolVersion": "2025-06-18",
      "scope": "remote hosted MCP initialize + tools/list",
      "serverInfo": {
        "description": "Exa web search, page fetching and research-agent tools for AI agents over MCP.",
        "icons": [
          {
            "mimeType": "image/svg+xml",
            "sizes": [
              "any"
            ],
            "src": "https://exa.ai/images/logo/exa-logomark-blue.svg"
          },
          {
            "mimeType": "image/png",
            "sizes": [
              "32x32"
            ],
            "src": "https://exa.ai/images/favicon-32x32.png"
          }
        ],
        "name": "exa-search-server",
        "title": "Exa",
        "version": "3.5.0",
        "websiteUrl": "https://exa.ai"
      },
      "tool_result": {
        "content": [
          {
            "_meta": {
              "searchTime": 375.2
            },
            "text": "Title: N/A\nURL: https://modelcontextprotocol.io/specification/2026-07-28\nPublished: N/A\nAuthor: N/A\nHighlights:\n# Specification\n\nModel Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you\u2019re building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need. This specification defines the authoritative protocol requirements, based on the TypeScript schema in schema.ts. For implementation guides and examples, visit modelcontextprotocol.io. The key words \u201cMUST\u201d, \u201cMUST NOT\u201d, \u201cREQUIRED\u201d, \u201cSHALL\u201d, \u201cSHALL NOT\u201d, \u201cSHOULD\u201d, \u201cSHOULD NOT\u201d, \u201cRECOMMENDED\u201d, \u201cNOT RECOMMENDED\u201d, \u201cMAY\u201d, and \u201cOPTIONAL\u201d in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.\n\nOverview\n\nMCP provides a standardized way for applications to:\n\n- Share contextual information with language models\n- Expose tools and capabilities to AI systems\n- Build composable integrations and workflows\n\nThe protocol uses JSON-RPC 2.0 messages to establish communication between:\n\n- Hosts: LLM applications that initiate connections\n- Clients: Connectors within the host application\n- Servers: Services that provide context and capabilities\n\nMCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.\n\nKey Details\n\nBase Protocol\n\n- JSON-RPC message format\n- Stateless, self-contained requests\n- Per-request capability negotiation\n\nFeatures\n\nServers offer any of the following features to clients:\n\n- Resources: Context and data, for the user or the AI model to use\n- Prompts: Templated messages and workflows for users\n- Tools: Functions for the AI model to execute\n\nClients may offer the following features to servers:\n\n- Elicitation: Server-initiated requests for additional information from users\n\nAdditional Utilities\n\n- Configuration\n- Progress tracking\n- Cancellation\n- Error reporting\n\nExtensions\n\nBeyond the core protocol, MCP defines optional extensions that add modular, specialized, or experimental functionality. Extensions are always opt-in and require explicit support from both client and server, negotiated during initialization. Notable extensions include:\n\n- Tasks: Asynchronous execution of long-running operations, with polling, mid-flight input, and durable handles\n- Skills over MCP: Rich, structured instructions for agent workflows, discovered and consumed through MCP\n- MCP Apps: Interactive UI elements (charts, forms, video players) rendered inline within conversations\n\n...\n\nSecurity and Trust & Safety\n\nThe Model Context Protocol enables powerful capabilities through arbitrary data access and code execution paths. With this power comes important security and trust considerations that all implementors must carefully address.\n\nKey Principles\n\n1. User Consent and Control\n\n- Users must explicitly consent to and understand all data access and operations\n- Users must retain control over what data is shared and what actions are taken\n- Implementors should provide clear UIs for reviewing and authorizing activities\n2. Data Privacy\n\n- Hosts must obtain explicit user consent before exposing user data to servers\n- Hosts must not transmit resource data elsewhere without user consent\n- User data should be protected with appropriate access controls\n3. Tool Safety\n\n- Tools represent arbitrary code execution and must be treated with appropriate caution. \n\n- In particular, descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server.\n- Hosts must obtain explicit user consent before invoking any tool\n- Users should understand what each tool does before authorizing its use\n\nImplementation Guidelines\n\nWhile MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD:\n\n1. Build robust consent and authorization flows into their applications\n2. Provide clear documentation of security implications\n3. Implement appropriate access controls and data protections\n4. Follow security best practices in their integrations\n5. Consider privacy implications in their feature designs\n\n---\n\nTitle: Overview - Model Context Protocol\nURL: https://modelcontextprotocol.io/specification/2025-11-25/basic\nPublished: N/A\nAuthor: N/A\nHighlights:\n# Overview\n\nThe Model Context Protocol consists of several key components that work together:\n\n- Base Protocol: Core JSON-RPC message types\n- Lifecycle Management: Connection initialization, capability negotiation, and session control\n- Authorization: <secret>\n- Server Features: Resources, prompts, and tools exposed by servers\n- Client Features: Sampling and root directory lists provided by clients\n- Utilities: Cross-cutting concerns like logging and argument completion\n\nAll implementations MUST support the base protocol and lifecycle management components. Other components MAY be implemented based on the specific needs of the application. These protocol layers establish clear separation of concerns while enabling rich interactions between clients and servers. The modular design allows implementations to support exactly the features they need.\n\n...\n\nMessages\n\nAll messages between MCP clients and servers MUST follow the JSON-RPC 2.0 specification. The protocol defines these types of messages:\n\nRequests\n\nRequests are sent from the client to the server or vice versa, to initiate an operation.\n\n```\n{\n  jsonrpc: \"2.0\";\n  id: string | number;\n  method: string;\n  params?: {\n    [key: string]: unknown;\n  };\n}\n\n```\n\n-\n\n...\n\nAuth\n\nMCP provides an Authorization framework for use with HTTP. Implementations using an HTTP-based transport SHOULD conform to this specification, whereas implementations using STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment. Additionally, clients and servers MAY negotiate their own custom authentication and authorization strategies. For further discussions and contributions to the evolution of MCP\u2019s auth mechanisms, join us in GitHub Discussions to help shape the future of the protocol!\n\nSchema\n\nThe full specification of the protocol is defined as a TypeScript schema. This is the source of truth for all protocol messages and structures. There is also a JSON Schema, which is automatically generated from the TypeScript source of truth, for use with various automated tooling.\n\nJSON Schema Usage\n\nThe Model Context Protocol uses JSON Schema for validation throughout the protocol. This section clarifies how JSON Schema should be used within MCP messages.\n\nSchema Dialect\n\nMCP supports JSON Schema with the following rules:\n\n1. Default dialect: When a schema does not include a `$schema` field, it defaults to JSON Schema 2020-12\n2. Explicit dialect: Schemas MAY include a `$schema` field to specify a different dialect\n3. Supported dialects: Implementations MUST support at least 2020-12 and SHOULD document which additional dialects they support\n4. Recommendation: Implementors are RECOMMENDED to use JSON Schema 2020-12.\n\n---\n\nTitle: Schema Reference - Model Context Protocol\nURL: https://modelcontextprotocol.io/specification/2025-11-25/schema\nPublished: N/A\nAuthor: N/A\nHighlights:\nSchema Reference - Model Context Protocol\n\n# Schema Reference\n\nJSON-RPC\n\n`JSONRPCErrorResponse`\n\ninterface JSONRPCErrorResponse { jsonrpc: \u201c2.0\u201d; id?: RequestId; error: Error; }\n\nA response to a request that indicates an error occurred.\n\njsonrpc: \u201c2.0\u201d\n\nid?: RequestId\n\n`JSONRPCMessage`\n\nJSONRPCMessage: JSONRPCRequest | JSONRPCNotification | JSONRPCResponse\n\nRefers to any valid JSON-RPC object that can be decoded off the wire, or encoded to be sent.\n\n`JSONRPCNotification`\n\ninterface JSONRPCNotification { method: string; params?: { [key: string]: any }; jsonrpc: \u201c2.0\u201d; }\n\nA notification which does not expect a response.\n\nmethod: string\n\nInherited from Notification.method\n\nparams?: { [key: string]: any }\n\nInherited from Notification.params\n\njsonrpc: \u201c2.0\u201d\n\n`JSONRPCRequest`\n\ninterface JSONRPCRequest { method: string; params?: { [key: string]: any }; jsonrpc: \u201c2.0\u201d; id: RequestId; }\n\nA request that expects a response.\n\nmethod: string\n\nInherited from Request.method\n\nparams?: { [key: string]: any }\n\nInherited from Request.params\n\njsonrpc: \u201c2.0\u201d\n\n`JSONRPCResponse`\n\nJSONRPCResponse: JSONRPCResultResponse | JSONRPCErrorResponse\n\nA response to a request, containing either the result or error.\n\n`JSONRPCResultResponse`\n\ninterface JSONRPCResultResponse { jsonrpc:\n\n---\n\nTitle: Overview\nURL: https://modelcontextprotocol.io/specification/draft/basic\nPublished: N/A\nAuthor: N/A\nHighlights:\nOverview - Model Context Protocol\n\n# Overview\n\nThe Model Context Protocol consists of several key components that work together:\n\n- Base Protocol: Core JSON-RPC message types\n- Versioning and Compatibility: Protocol version negotiation, extension negotiation, and interoperability with earlier protocol revisions\n- Message Patterns: Messaging patterns supported by the core protocol including request and response, multi round-trip requests (MRTR), and subscribe and notify\n- Authorization: <secret>\n- Server Features: Resources, prompts, and tools exposed by servers\n- Client Features: Elicitation, sampling and root directory lists provided by clients\n- Utilities: Cross-cutting concerns like logging and argument completion\n\nAll implementations MUST support the base protocol, versioning, and the message patterns. Other components MAY be implemented based on the specific needs of the application. These protocol layers establish clear separation of concerns while enabling rich interactions between clients and servers. The modular design allows implementations to support exactly the features they need.\n\n...\n\nMessages\n\nAll messages between MCP clients and servers MUST follow the JSON-RPC 2.0 specification. The protocol defines these types of messages:\n\nRequests\n\nRequests are sent from the client to the server, to initiate an operation.\n\n```\n{\n  jsonrpc: \"2.0\";\n  id: string | number;\n  method: string;\n  params?: {\n    [key: string]: unknown;\n  };\n}\n\n```\n\n- Requests MUST include a string or integer ID.\n- Unlike base JSON-RPC, the ID MUST NOT be `null`.\n- The request ID MUST NOT match the ID of any other request the sender has issued and not yet received a response for.\n\nResponses\n\nResponses are sent in reply to requests, containing either the result or error of the operation.\n\nResult Responses\n\nResult responses are sent when the operation completes successfully.\n\n```\n{\n  jsonrpc: \"2.0\";\n  id: string | number;\n  result: {\n    resultType: string;\n    [key: string]: unknown;\n  };\n}\n\n```\n\n- Result responses MUST include the same ID as the request they correspond to.\n- Result responses MUST include a `result` field.\n- The `result` MAY follow any JSON object structure.\n- The `result` MUST include a `resultType` field to indicate the type of the result.\n\n##### ResultType\n\nThe `resultType` field in a result indicates the type of the result being returned. MCP supports polymorphic result types, allowing servers to return different structures based on the outcome of the request. The `resultType` field is a string that clients can use to determine how to parse and handle the `result` object.\n\n- A `resultType` of `\"complete\"` indicates the request completed successfully and the result contains the final content.\n- A `resultType` of `\"input_required\"` indicates the request is incomplete and more information is needed to process the request. The result contains an `InputRequiredResult` object with additional information needed.\n- Extensions MAY add additional `ResultType` values. The set of supported `ResultType` values MUST be created from the set defined in the core protocol and include any additional values of supported extensions that are advertised via capabilities.\n- A `resultType` of any value unrecognized by the client MUST be considered invalid.\n- For backward compatibility with servers implementing earlier protocol versions, which do not include `resultType`, clients MUST treat an absent `resultType` as `\"complete\"`.\n\nError Responses\n\nError responses are sent when the operation fails or encounters an error.\n\n```\n{\n  jsonrpc: \"2.0\";\n  id?: string | number;\n  error: {\n    code: number;\n    message: string;\n    data?: unknown;\n  }\n}\n\n```\n\n- Error responses MUST include the same ID as the request they correspond to (except in error cases where the ID could not be read due a malformed request).\n- Error responses MUST include an `error` field with a `code` and `message`.\n- Error codes MUST be integers.\n- Error responses MAY include a `data` member with additional information of any type, such as nested errors.\n\n...\n\n;\n  };\n}\n\n```\n\nMessage Patterns\n\nThe Model Context Protocol (MCP) supports several Message Patterns that define how clients and servers interact:\n\n1. Request and Response: A client sends a request to the server, and the server responds with a result or error.\n2. Multi Round-Trip Requests (MRTR): A server requires additional client input (sampling, elicitation, or roots) to complete a request.\n3. Subscribe and Notify: A client subscribes to a stream of notifications from the server, which are sent as they occur.\n\nStatelessness\n\nThe Model Context Protocol (MCP) is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream. Specifically:\n\n- Servers MUST NOT rely on prior requests over the same connection to establish context (e.g., capabilities, protocol version, client identity). Every request supplies this metadata in its `_meta` field.\n- Servers SHOULD be prepared to handle requests associated with multiple tasks, threads, or conversations.\n- Servers SHOULD NOT require that a client reuse the same connection or process to perform related operations.\n- Clients SHOULD NOT use an individual task, thread, or conversation as the lifetime boundary for the stdio process.\n- State that needs to span multiple requests (e.g., long-running tasks, application-level handles) MUST be referenced by an explicit identifier the client passes on each request.\n\nThis implies that an open connection, such as a STDIO process, is not a conversation or session: clients may interleave unrelated requests on the same transport, and a server must not treat connection or process identity as a proxy for conversation or session continuity.\n\nLong-lived requests like `subscriptions/listen` remain request/response; the response is just an open stream of notifications. Their state is scoped to the request itself, not to the connection underneath.\n\n...\n\nAuth\n\nMCP provides an Authorization framework for use with HTTP. Implementations using an HTTP-based transport SHOULD conform to this specification, whereas implementations using STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment. Additionally, clients and servers MAY negotiate their own custom authentication and authorization strategies. For further discussions and contributions to the evolution of MCP\u2019s auth mechanisms, join us in GitHub Discussions to help shape the future of the protocol!\n\nSchema\n\nThe full specification of the protocol is defined as a TypeScript schema. This is the source of truth for all protocol messages and structures. There is also a JSON Schema, which is automatically generated from the TypeScript source of truth, for use with various automated tooling.\n\nJSON Schema Usage\n\nThe Model Context Protocol uses JSON Schema for validation throughout the protocol. This section clarifies how JSON Schema should be used within MCP messages.\n\nSchema Dialect\n\nMCP supports JSON Schema with the following rules:\n\n1. Default dialect: When a schema does not include a `$schema` field, it defaults to JSON Schema 2020-12\n2. Explicit dialect: Schemas MAY include a `$schema` field to specify a different dialect\n3. Supported dialects: Implementations MUST support at least 2020-12 and SHOULD document which additional dialects they support\n4. Recommendation: Implementors are RECOMMENDED to use JSON Schema 2020-12.\n\n---\n\nTitle: Lifecycle - Model Context Protocol\nURL: https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle\nPublished: N/A\nAuthor: N/A\nHighlights:\nLifecycle - Model Context Protocol\n\n# Lifecycle\n\nThe Model Context Protocol (MCP) defines a rigorous lifecycle for client-server connections that ensures proper capability negotiation and state management.\n\n1. Initialization: Capability negotiation and protocol version agreement\n2. Operation: Normal protocol communication\n3. Shutdown: Graceful termination of the connection\n\nLifecycle Phases\n\nInitialization\n\nThe initialization phase MUST be the first interaction between client and server. During this phase, the client and server:\n\n- Establish protocol version compatibility\n- Exchange and negotiate capabilities\n- Share implementation details\n\nThe client MUST initiate this phase by sending an `initialize` request containing:\n\n- Protocol version supported\n- Client capabilities\n- Client implementation information\n\n...\n\nVersion Negotiation\n\nIn the `initialize` request, the client MUST send a protocol version it supports. This SHOULD be the latest version supported by the client. If the server supports the requested protocol version, it MUST respond with the same version. Otherwise, the server MUST respond with another protocol version it supports. This SHOULD be the latest version supported by the server. If the client does not support the version in the server\u2019s response, it SHOULD disconnect.\n\nIf using HTTP, the client MUST include the `MCP-Protocol-Version: ` HTTP header on all subsequent requests to the MCP server. For details, see the Protocol Version Header section in Transports.\n\nCapability Negotiation\n\nClient and server capabilities establish which optional protocol features will be available during the session. Key capabilities include:\n\n| Category | Capability | Description |\n| --- | --- | --- |\n| Client | `roots` | Ability to provide filesystem roots |\n| Client | `sampling` | Support for LLM sampling requests |\n| Client | `elicitation` | Support for server elicitation requests |\n| Client | `tasks` | Support for task-augmented client requests |\n| Client | `experimental` | Describes support for non-standard experimental features |\n| Server | `prompts` | Offers prompt templates |\n| Server | `resources` | Provides readable resources |\n| Server | `tools` | Exposes callable tools |\n| Server | `logging` | Emits structured log messages |\n| Server | `completions` | Supports argument autocompletion |\n| Server | `tasks` | Support for task-augmented server requests |\n| Server | `experimental` | Describes support for non-standard experimental features |\n\nCapability objects can describe sub-capabilities like:\n\n- `listChanged`: Support for list change notifications (for prompts, resources, and tools)\n- `subscribe`: Support for subscribing to individual items\u2019 changes (resources only)\n\n...\n\nOperation\n\nDuring the operation phase, the client and server exchange messages according to the negotiated capabilities. Both parties MUST:\n\n- Respect the negotiated protocol version\n- Only use capabilities that were successfully negotiated\n\nShutdown\n\nDuring the shutdown phase, one side (usually the client) cleanly terminates the protocol connection. No specific shutdown messages are defined\u2014instead, the underlying transport mechanism should be used to signal connection termination:\n\nstdio\n\nFor the stdio transport, the client SHOULD initiate shutdown by:\n\n1. First, closing the input stream to the child process (the server)\n2. Waiting for the server to exit, or sending `SIGTERM` if the server does not exit within a reasonable time\n3. Sending `SIGKILL` if the server does not exit within a reasonable time after `SIGTERM`\n\nThe server MAY initiate shutdown by closing its output stream to the client and exiting.\n\nHTTP\n\nFor HTTP transports, shutdown is indicated by closing the associated HTTP connection(s).\n\n---\n\nTitle: modelcontextprotocol/modelcontextprotocol\nURL: https://github.com/modelcontextprotocol/specification/\nPublished: N/A\nAuthor: N/A\nHighlights:\n# Model Context Protocol (MCP)\n\n_Just heard of MCP and not sure where to start? Check out our documentation website._\n\nThis repo contains the:\n\n- MCP specification\n- MCP protocol schema\n- Official MCP documentation\n\nThe schema is defined in TypeScript first, but\nmade available as JSON Schema as well, for wider\ncompatibility.\n\nThe official MCP documentation is built using Mintlify and <email>.\n\n---\n\nTitle: Specification\nURL: https://modelcontextprotocol.io/specification/2025-06-18\nPublished: 2025-06-18T00:00:00.000Z\nAuthor: N/A\nHighlights:\n# Specification\n\nModel Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you\u2019re building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need. This specification defines the authoritative protocol requirements, based on the TypeScript schema in schema.ts. For implementation guides and examples, visit modelcontextprotocol.io. The key words \u201cMUST\u201d, \u201cMUST NOT\u201d, \u201cREQUIRED\u201d, \u201cSHALL\u201d, \u201cSHALL NOT\u201d, \u201cSHOULD\u201d, \u201cSHOULD NOT\u201d, \u201cRECOMMENDED\u201d, \u201cNOT RECOMMENDED\u201d, \u201cMAY\u201d, and \u201cOPTIONAL\u201d in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.\n\n...\n\nOverview\n\nMCP provides a standardized way for applications to:\n\n- Share contextual information with language models\n- Expose tools and capabilities to AI systems\n- Build composable integrations and workflows\n\nThe protocol uses JSON-RPC 2.0 messages to establish communication between:\n\n- Hosts: LLM applications that initiate connections\n- Clients: Connectors within the host application\n- Servers: Services that provide context and capabilities\n\nMCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.\n\n...\n\nKey Details\n\nBase Protocol\n\n- JSON-RPC message format\n- Stateful connections\n- Server and client capability negotiation\n\nFeatures\n\nServers offer any of the following features to clients:\n\n- Resources: Context and data, for the user or the AI model to use\n- Prompts: Templated messages and workflows for users\n- Tools: Functions for the AI model to execute\n\nClients may offer the following features to servers:\n\n- Sampling: Server-initiated agentic behaviors and recursive LLM interactions\n- Roots: Server-initiated inquiries into uri or filesystem boundaries to operate in\n- Elicitation: Server-initiated requests for additional information from users\n\nAdditional Utilities\n\n- Configuration\n- Progress tracking\n- Cancellation\n- Error reporting\n- Logging\n\n...\n\nSecurity and Trust & Safety\n\nThe Model Context Protocol enables powerful capabilities through arbitrary data access and code execution paths. With this power comes important security and trust considerations that all implementors must carefully address.\n\nKey Principles\n\n1. User Consent and Control\n\n- Users must explicitly consent to and understand all data access and operations\n- Users must retain control over what data is shared and what actions are taken\n- Implementors should provide clear UIs for reviewing and authorizing activities\n2. Data Privacy\n\n- Hosts must obtain explicit user consent before exposing user data to servers\n- Hosts must not transmit resource data elsewhere without user consent\n- User data should be protected with appropriate access controls\n3. Tool Safety\n\n- Tools represent arbitrary code execution and must be treated with appropriate caution. \n\n- In particular, descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server.\n- Hosts must obtain explicit user consent before invoking any tool\n- Users should understand what each tool does before authorizing its use\n4. LLM Sampling Controls\n\n- Users must explicitly approve any LLM sampling requests\n- Users should control: \n\n- Whether sampling occurs at all\n- The actual prompt that will be sent\n- What results the server can see\n- The protocol intentionally limits server visibility into prompts\n\n...\n\nImplementation Guidelines\n\nWhile MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD:\n\n1. Build robust consent and authorization flows into their applications\n2. Provide clear documentation of security implications\n3. Implement appropriate access controls and data protections\n4. Follow security best practices in their integrations\n5. Consider privacy implications in their feature designs\n\n---\n\nTitle: Model Context Protocol specification\nURL: https://spec.modelcontextprotocol.io/specification/2025-03-26/\nPublished: 2025-03-28T04:55:21.000Z\nAuthor: N/A\nHighlights:\nModel Context Protocol specification \u2013 Model Context Protocol Specification\n\n# Model Context Protocol specification\n\n\u2139\ufe0f\n\nProtocol Revision: 2025-03-26\n\nModel Context Protocol(MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you\u2019re building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.\n\nThis specification defines the authoritative protocol requirements, based on the TypeScript schema in schema.ts.\n\nFor implementation guides and examples, visit modelcontextprotocol.io.\n\nThe key words \u201cMUST\u201d, \u201cMUST NOT\u201d, \u201cREQUIRED\u201d, \u201cSHALL\u201d, \u201cSHALL NOT\u201d, \u201cSHOULD\u201d, \u201cSHOULD NOT\u201d, \u201cRECOMMENDED\u201d, \u201cNOT RECOMMENDED\u201d, \u201cMAY\u201d, and \u201cOPTIONAL\u201d in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.\n\n...\n\n## Overview\n\nMCP provides a standardized way for applications to:\n\n- Build composable integrations and workflows\n- Expose tools and capabilities to AI systems\n- Share contextual information with language models\n\nThe protocol uses JSON-RPC 2.0 messages to establish communication between:\n\n- Servers: Services that provide context and capabilities\n- Clients: Connectors within the host application\n- Hosts: LLM applications that initiate connections\n\nMCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.\n\n...\n\n## Key Details\n\n### Base Protocol\n\n- Server and client capability negotiation\n- Stateful connections\n- JSON-RPC message format\n\n### Features\n\nServers offer any of the following features to clients:\n\n- Tools: Functions for the AI model to execute\n- Prompts: Templated messages and workflows for users\n- Resources: Context and data, for the user or the AI model to use\n\nClients may offer the following feature to servers:\n\n- Sampling: Server-initiated agentic behaviors and recursive LLM interactions\n\n### Additional Utilities\n\n- Logging\n- Error reporting\n- Cancellation\n- Progress tracking\n- Configuration\n\n...\n\n## Security and Trust & Safety\n\nThe Model Context Protocol enables powerful capabilities through arbitrary data access and code execution paths. With this power comes important security and trust considerations that all implementors must carefully address.\n\n### Key Principles\n\nUser Consent and Control\n\n- Implementors should provide clear UIs for reviewing and authorizing activities\n- Users must retain control over what data is shared and what actions are taken\n- Users must explicitly consent to and understand all data access and operations\n\nData Privacy\n\n- User data should be protected with appropriate access controls\n- Hosts must not transmit resource data elsewhere without user consent\n- Hosts must obtain explicit user consent before exposing user data to servers\n\nTool Safety\n\nTools represent arbitrary code execution and must be treated with appropriate caution.\n\n- In particular, descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server.\n\nLLM Sampling Controls\n\nUsers should control:\n\n- What results the server can see\n- The actual prompt that will be sent\n- Whether sampling occurs at all\n\n### Implementation Guidelines\n\nWhile MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD:\n\n1. Consider privacy implications in their feature designs\n2. Follow security best practices in their integrations\n3. Implement appropriate access controls and data protections\n4. Provide clear documentation of security implications\n5. Build robust consent and authorization flows into their applications\n6. The protocol intentionally limits server visibility into prompts\n\n---\n\nTitle: N/A\nURL: https://spec.modelcontextprotocol.io/specification/\nPublished: 2025-01-08T14:31:44.000Z\nAuthor: N/A\nHighlights:\nSpecification \u2013 Model Context Protocol Specification\n\n# Specification\n\n---\n\nTitle: Model Context Protocol Specification\nURL: https://modelcontextprotocol.info/specification/\nPublished: N/A\nAuthor: N/A\nHighlights:\nSpecification \u2013 Model Context Protocol \uff08MCP\uff09\n\n# Model Context Protocol Specification\n\nThe Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. This section contains the detailed technical specifications for implementing the protocol.\n\n## Available Versions \n\nMCP is under active development. The following specifications are available:\n\nCurrent version:\n\n- English 2026-07-28 specification\n- \u4e2d\u6587 2026-07-28 \u89c4\u8303\n\nSpecification (Latest) Specification (Previous) Specification (Older) Specification (Legacy)\n\n### Version History \n\n- 2026-07-28 - Latest\n\n- Stateless protocol with per-request version and capability metadata\n- Removed protocol-level sessions and the initialization handshake\n- Added mandatory `server/discover` capability discovery\n- Introduced Multi Round-Trip Requests (MRTR)\n- Moved Tasks from the core protocol to an official extension\n- 2025-11-25 - Previous Stable\n\n- OpenID Connect Discovery support\n- Icons metadata for tools/resources/prompts\n- Incremental scope consent\n- URL mode elicitation support\n- Sampling tool calling support\n- OAuth Client ID metadata documents\n- Experimental Tasks support\n- 2025-06-18 - Older Stable\n\n- Removed JSON-RPC batching support\n- Structured tool output\n- OAuth Resource Server classification\n- Resource Indicators (RFC 8707)\n- Elicitation feature support\n- Resource links support\n- 2024-11-05 - Legacy\n\n- Initial stable version",
            "type": "text"
          }
        ]
      },
      "tool_result_checked": true,
      "tool_schema_bytes": 2421,
      "tools": [
        "web_search_exa",
        "web_fetch_exa"
      ],
      "transport": "streamable-http",
      "url": "https://mcp.exa.ai/mcp",
      "working": true
    },
    "evidence_strength": "readme_checked",
    "example_checks": [
      {
        "claim": "Local tests or runnable examples for the README",
        "command": "",
        "deferred": false,
        "evidence": "README documents no local test, example or run command. Its only runnable setup is the hosted endpoint https://mcp.exa.ai/mcp (exercised by the probe and claim) and client commands (claude plugin install, codex mcp add) that need external clients. Local stdio build (npm ci, npm run build:stdio) and CI (npm run ci) are in package.json/.github and not README; node/npm is not installed in this guest, so they were not run.",
        "expected": "documented command completes successfully",
        "input": "",
        "kind": "example",
        "outcome": "README documents no local test, example or run command. Its only runnable setup is the hosted endpoint https://mcp.exa.ai/mcp (exercised by the probe and claim) and client commands (claude plugin install, codex mcp add) that need external clients. Local stdio build (npm ci, npm run build:stdio) and CI (npm run ci) are in package.json/.github and not README; node/npm is not installed in this guest, so they were not run.",
        "source": "README.md",
        "verdict": "blocked"
      }
    ],
    "status": "PASS"
  },
  "diagnosis": null
}