# Pathrule Pattern: MCP Client and Tool Integration (1.0.0) # ::pathrule:package:mcp-client-integration ### [RULE] Authorize each tool call at the moment of effect (path: /src/tools) Connecting a server or listing a tool does not grant blanket authority. Tool descriptions are server-controlled content and can understate the real effect or change over time. - Classify tools as read, local write, external write, sensitive read, destructive, or privileged and apply the product's consent policy to the actual call. - Show the user or policy engine the resolved server, tool, arguments, target, and expected effect before approval where required. - Do not allow model text or a server response to broaden credentials, paths, recipients, or resources beyond the active user request. - Record approval and execution outcome with bounded arguments and identities while redacting secrets and unnecessary personal data. See /src/mcp for the adjacent decision or procedure that completes this constraint. --- ### [RULE] Validate discovery and results as untrusted protocol data (path: /src/mcp) Servers can be buggy or malicious, and tool results can contain prompt injection, unsafe links, oversized payloads, or content types the client is not prepared to display. - Accept only negotiated capabilities and protocol messages valid for the active connection and supported client version. - Validate tool input and output against bounded schemas and reject unknown or oversized content before model context assembly. - Treat text and resources returned by servers as untrusted data, not higher-priority instructions, and preserve provenance in model context. - Render links, markdown, images, resources, and embedded content through application security policy without executing arbitrary HTML, scripts, or local paths. See /tests/mcp for the adjacent decision or procedure that completes this constraint. --- ### [RULE] Retry tool calls only when effect semantics permit it (path: /src/mcp) A transport close or timeout does not prove the server failed before performing the effect. Automatic retry can send the same message, create the same issue, or delete the target twice. - Assign a deadline and propagate cancellation through the transport and tool execution path. - Retry read-only or explicitly idempotent tools under a bounded policy and preserve the same logical operation identity. - For ambiguous state-changing outcomes, query server or external state by operation identity before deciding whether to repeat. - Surface unknown outcome separately from failure so the user can reconcile instead of receiving a false success or triggering another automatic action. See /src/tools for the adjacent decision or procedure that completes this constraint. --- ### [MEMORY] Connection lifecycle owns authentication and capability state (path: /src/mcp) Transport reconnect can change server version, authentication, tools, or capabilities. Reusing cached discovery blindly after reconnect makes the client call a stale or differently scoped surface. - Authenticate through the approved flow and keep credentials scoped to server, user, audience, and required capabilities. - On connection establishment, negotiate capabilities and discover the surfaces the client supports rather than assuming every server implements every feature. - Cancel or reconcile pending requests on disconnect and clear subscriptions and progress handlers owned by the old connection. - Rediscover after reconnect and make changed tools or permissions visible before the model can invoke them. See /src/tools for the rule or workflow that puts this decision into practice. --- ### [MEMORY] Tool descriptions are model affordances with product ownership (path: /src/tools) Models select tools from names, descriptions, and schemas. Poor affordances cause wrong calls, but trusting a remote description to define security lets the server write its own permissions. - Normalize tool names with server identity where collisions are possible and preserve the original protocol identity for calls. - Expose descriptions and argument schemas within context budgets and omit tools unavailable to the current user or task. - Keep approval, target restrictions, rate limits, credential scopes, and destructive-action policy in the client or host. - Measure tool selection and failure evidence without storing sensitive argument values, then improve affordances through reviewed client configuration. See /tests/mcp for the rule or workflow that puts this decision into practice. --- ### [SKILL] verify-mcp-client-integration (path: /) --- name: verify-mcp-client-integration description: Verify an MCP server connection or tool integration in an AI client. --- # Verify Mcp Client Integration Run this procedure when the affected surface changes, before the result is promoted to production. Record evidence for every step instead of accepting a plausible-looking result. 1. Connect with valid, expired, wrong-audience, missing, and revoked credentials and negotiate supported and unsupported capabilities. 2. Discover duplicate, changed, malformed, oversized, and unauthorized tools and resources and confirm policy filters them before model exposure. 3. Invoke read, external-write, destructive, invalid, slow, cancelled, ambiguous, and idempotent calls and verify consent and retry semantics. 4. Return prompt-injection text, unsafe links, unexpected content types, large resources, and malformed structured results and confirm provenance and safe rendering. 5. Disconnect during pending calls and subscriptions, reconnect to a changed catalog, and prove stale tools, handlers, credentials, and outcomes are cleared or reconciled. ## Exit criteria The change is complete only when the expected behavior, failure behavior, and rollback path have all been exercised with representative data. Preserve the evidence with the change so the next operator can repeat the same checks.