Team MCP adoption needs an audit receipt, not one generic log schema.
In team deployments, the hard part is not only recording that a tool was called. The hard part is saying where caller identity came from, what policy authorized the call, and where the evidence is incomplete.
The split that matters
Local stdio
Identity usually comes from the OS process/user boundary. The MCP message does not need to carry `member_id`; attribution is implicit unless the process is wrapped.
Hosted HTTP
Identity comes from the transport/session boundary: OAuth subject, API gateway identity, or per-member token. The raw MCP `tools/call` frame is still identity-agnostic.
Treating both transports as if the protocol carries the same caller identity creates misleading docs and weak audits. The receipt should make the identity source explicit.
Minimal receipt shape
deployment_model: local_stdio | hosted_http | wrapped_stdio workspace_id: acme-prod server_id: github-mcp operation: tools/call tool_name: create_issue identity: source: os_user | oauth_subject | api_gateway | per_member_token | unknown member_id_present: true upstream_credential: shared | per_user | unknown authorization: policy_source: gateway | server | client_config | manual | unknown allowlist_match: true | false | not_checked decision: allowed | denied | error | incomplete evidence: request_seen: true response_seen: true args_recorded: full | redacted | omitted | truncated output_recorded: full | redacted | omitted | truncated tamper_evidence: hash_chain | signed | append_only | none audit_coverage: complete | partial | unobservable coverage_gap: - identity_from_transport_not_mcp - shared_upstream_token - output_truncated - server_side_policy_unobserved verdict: pass | fail | incomplete
What the receipt prevents
- claiming per-user attribution when identity only exists at the gateway
- treating a hash-chained row as proof that payload evidence is complete
- mixing allowlist outcome with audit completeness
- hiding shared-token risk behind a clean `tools/call` success
Offboarding check
A useful team MCP receipt should make offboarding testable. The question is not "did we rotate a token?" but "which user, server, policy, and upstream credential can still produce a tool call after access is removed?"
offboarding_check: removed_member_id: user_123 per_member_token_revoked: true shared_upstream_token_rotated: false cached_sessions_invalidated: true residual_access: unknown verdict: incomplete
Use this as a fit check
Send one MCP server or team workflow. I will tell you whether a receipt like this would help, what fields are missing, and whether the honest verdict should be `pass`, `fail`, or `incomplete`.