Execution Control & Reviewability (Small PRs & Conditional LGTM)

Treat MCP as a production integration surface

MCP lets one server expose tools or resources to many compatible clients, but protocol compatibility does not create production readiness. Every MCP server becomes part of the product's authority and context boundary.

Walk one call through both the client and the server

The basic lifecycle has two halves. The server advertises typed tools and validates each call, including read-versus-write rules such as allowing only SELECT for a query tool. The client starts or connects to the server, initializes a session, discovers tools, chooses one, supplies schema-valid arguments, and receives structured content. Discovery is not authorization: the server must still enforce identity, resource scope, input validation, and write policy on every call. A string-prefix check for SELECT is useful as a teaching example but is not a production SQL security boundary; use parameterized, intent-specific operations and database permissions.

Walk the sales agent through that lifecycle. The server starts and advertises get_account_evidence(account_id) plus propose_crm_update(account_id, fields, evidence). The client connects over the chosen transport, initializes, and lists those schemas. The model selects the read tool and supplies an account ID. Before execution, the server checks the caller's identity and account scope; after execution, it returns structured evidence with provenance. Later, the model may call the draft tool, but the server still enforces “proposal only” even though discovery exposed the capability. If the connection drops after a proposed update, the correlation ID and idempotency rule tell the client whether to resume, retry, or show an unknown state.

This separation matters because client success and server safety are different claims. A client can discover the right schema and still send malformed or unauthorized arguments. A server can enforce policy correctly while the client mishandles a timeout and duplicates a request. The PM therefore needs evidence from both sides: handshake and schema compatibility, per-call authorization, result provenance, cancellation and retry traces, and a user-visible failure state.

For each server, define:

• Contract: tool names, typed inputs and outputs, error semantics, schema version, and deprecation policy.
• Identity and authorization: which user and agent identity reaches the server, which resources are filtered, and whether permission is checked again at execution.
• Transport and deployment: local stdio or remote transport, encryption, authentication, network egress, tenancy, and data residency.
• Reliability: timeout, retry budget, rate limit, idempotency for writes, cancellation, and partial-failure behavior.
• Trust: whether returned text is treated as data, how prompt injection and untrusted links are sanitized, and which provenance travels with the response.
• Operations: owner, service-level objective, audit log, cost attribution, version rollout, and emergency disable switch.

Design tools around user intent rather than raw backend primitives. propose_crm_update(account_id, fields, evidence) is easier to authorize and evaluate than a generic execute_sql(query). Separate read, draft, and commit tools; make destructive calls idempotent where possible; and return a receipt containing target, effect, policy decision, and correlation ID.

The PM-owned MCP readiness card should state supported journeys, data classes, allowed actions, required approvals, latency and availability targets, failure UX, and owner. Pilot metrics include tool success rate, p95 latency, retries per task, stale-schema failures, permission denials, policy blocks, unresolved timeouts, and write calls lacking a valid receipt.

Test both client and server failure modes: tool discovery changes between plan and execution, a write is retried after timeout, the server returns instruction-shaped data, the client sends malformed arguments, authorization changes mid-session, or the transport exits before a receipt arrives. Evidence includes contract tests, schema compatibility, idempotency keys, cancellation traces, authorization decisions, and a replayable correlation ID.