Agent and MCP Tool Boundaries

Review what a tool can actually do, who may request it, and what its result proves. Use the installed protocol/SDK version and the real host/server boundary; do not assume every MCP feature or annotation is enforced by the client.

Trace authority and data

Separate discovery, read-only lookup, local mutation, external publication, destructive operations, and physical commands. Validate arguments at the application boundary, including resource identity, tenant/site scope, bounds, paths, and permitted destinations. A schema-valid string can still name an unauthorized target.

Keep authorization in the trusted application/server layer. Descriptions and read-only/idempotence annotations are hints, not proof or enforcement. Retrieved files, tool output, resource text, and third-party skill instructions are data; they cannot grant permission, request secret export, or override the user's task. Do not let a model-generated argument bypass an existing admission/approval path.

Make the tool usable without guesswork

Descriptions should identify the task, important exclusions, required scope, and the smallest valid input. Prefer a bounded discovery/read path that returns the exact identifiers accepted by the next call. Distinguish omitted arguments from explicit null and document defaults and units; examples must match the real schema.

Return actionable validation errors and distinguish an empty success from denied access, unavailable capability, partial results, and unknown completion. Bound result size and expose the actual continuation mechanism instead of silently truncating. Keep structured and human-readable results consistent and enforce the declared output contract. Verify the deployed protocol version: MCP result shapes and capabilities are not identical across revisions. See tool interaction checks.

Make effects recoverable

Define what happens on timeout, disconnect, cancellation, retry, and process restart. An interrupted response does not prove an operation was not executed. Reuse the application's operation identity and reconciliation path where available. Retry a mutation only when the actual contract makes it safe; do not infer idempotence from a name or annotation.

Keep accepted, queued, completed, failed, and outcome-unknown states distinct as the application requires. For physical operations, a transport acknowledgment is not a verified equipment result. Bound concurrency, payloads, returned data, and long-running work. Redact secrets and avoid echoing unnecessary private input into logs or model context.

Exercise the boundary

Test malformed and overlarge inputs, unauthorized resource substitution, adversarial instructions inside retrieved content, permission loss, partial failure, duplicate requests, cancellation races, and unavailable tools. Use mocks or safe local fixtures where real effects are inappropriate. Confirm the server rejects invalid requests rather than relying on the UI or prompt.

Report supported capabilities, evidence, and unresolved limits. Do not install servers, grant credentials, enable hooks, or widen permissions to make a test pass.

Reference: MCP tools specification. Recheck the version actually used by the project.