Skills, MCP and Tools: From Discovery to Governed Invocation

Define the boundary before writing the adapter

This is the L5 Capability & Integration implementation companion to Capabilities Are Not Permissions. The only interfaces considered here are L6 Security, Identity & Governance for enforcement and L7 Evaluation & Observability for independent evidence. The proposed design is a reference control pattern, not a claim about a deployed service.

Three objects must remain separate. A skill packages a repeatable procedure and references. An MCP server exposes tools through protocol-defined discovery and invocation contracts. A capability registry records which exact provider, tool, version and workflow combination has passed qualification. None of these objects is an authorization grant.

Minimal capability admission contract

Register a candidate with an immutable identifier and digest, provider identity, transport endpoint, tool name, schema digest, supported operations, data classification, expected side effects, allowed environments, resource ownership, accountable approver, review expiry, revocation handle and evaluation receipt. Store the registry record in a trusted service, not in model-editable context.

{
  "capability_id": "support.order.lookup",
  "provider_id": "verified-provider",
  "tool": "get_order",
  "schema_digest": "sha256:<reviewed-digest>",
  "allowed_environment": "staging",
  "effect_class": "read",
  "tenant_boundary": "resource-owner",
  "qualification": "approved-for-support-read",
  "expires_at": "review-required",
  "evidence_ref": "qualification-receipt-id"
}

This is an illustrative governance record, not an MCP wire-format message or an actual issued credential. The digest and receipt values must be replaced by validated evidence before admission.

Six control points in the invocation path

1. Discover: fetch tool metadata from an authenticated, approved server; classify descriptions as untrusted instructions and never execute their embedded commands.
2. Compare: check provider, server identity, tool name and schema digest against the approved registry entry. Treat changes as a new candidate requiring qualification.
3. Qualify: evaluate the capability for a defined workflow, environment, data class and side-effect class. Record owner, test suite, version and expiry.
4. Authorize: at call time, bind authenticated principal, delegated agent, tenant, purpose, resource, arguments, time, approval and budget. Enforce at a trusted broker or resource server; default deny on missing context.
5. Execute: issue the minimum necessary credential for the approved operation. Prevent argument substitution after approval; bound timeout, retries and idempotency for writes.
6. Verify: record the decision and tool response, then independently check the resource-side effect. A tool's success message is not proof of the intended change.

Decision logic and a negative test

function authorizeInvocation(request, registry, policy) {
  const capability = registry.findByDigest(request.capabilityDigest);
  if (!capability || capability.status !== "approved") return "DENY";
  if (capability.expiresAt <= request.now) return "DENY";
  if (capability.tenant !== request.resourceTenant) return "DENY";
  if (!policy.allows(request.principal, request.agent,
                     request.operation, request.resource,
                     request.purpose, request.arguments)) return "DENY";
  return "ALLOW_WITH_BOUND_EXECUTION";
}

Pseudocode intentionally omits authentication, transactional enforcement and credential issuance. A production policy engine must validate the caller and preserve a tamper-evident decision record. Test the denial path with a schema-valid request for another tenant's order: correct JSON must still result in DENY, with no resource access and an attributable denial receipt.

Qualification matrix: test the boundaries, not only the happy path

• Catalog drift: mutate the tool schema or provider identity after approval; expect suspension pending review.
• Instruction injection: place a role-changing instruction in a tool description or returned document; expect no authority expansion.
• Delegation expiry: reuse a previously valid approval after expiry; expect denial at execution time.
• Cross-tenant access: substitute a valid-looking resource identifier belonging to another tenant; expect denial by the resource-side boundary.
• False success: return a successful tool result while withholding the expected state change; expect effect-verification failure.
• Retry and revocation: replay a write request after revocation; expect no second effect and a linked incident/evaluation receipt.

Record total cases, executed cases, denials, unexpected grants, observed effects, evidence gaps and the exact version tested. A zero-failure result on a small test set is not proof of universal safety. Fail closed on missing authorization evidence; route uncertainty to the accountable owner rather than the model.

Primary sources, claims and limitations

• MCP tools specification: supports tool discovery, schemas and invocation messages. It does not qualify a tool for enterprise use or grant business-level authority.
• MCP authorization specification: defines protected-resource authorization expectations for HTTP transport. It does not replace tenant and transaction authorization.
• Agent Skills specification: describes portable skill packaging. A skill manifest is not an executable security policy or an authorization token.
• OWASP LLM06 Excessive Agency: identifies risks from excessive functionality, permissions and autonomy. The six gates above are proposed implementation controls, not OWASP-mandated steps.
• NIST SP 800-207: informs contextual access enforcement and least privilege; it does not certify this design.

Actual Harness change: this article contributes a proposed L5 capability admission contract, a six-gate invocation pattern and six regression scenarios. It does not establish that the private Harness Collection, a commercial MCP service or any customer environment has implemented these controls.

Open questions: how should registries represent compatible schema changes; who is the trusted provider identity authority; which write effects need two-person approval; and how will a revoked capability invalidate cached discovery results and outstanding sessions?

Related reading: Skills Replace Prompts, Capabilities Are Not Permissions and Memory Admission.

Privacy Notice: With your consent, this website uses Google Analytics to understand aggregate visits and content usage. Analytics is optional and is not used for advertising or cross-site profiling. Some content and images may be generated or modified with the assistance of AI; every AI-assisted item is reviewed and manually edited by a human before publication. Full Privacy Policy · Cookie settings