Harness Theory Part 05｜Capability Engineering: How Tools, Skills, Hooks, Plugins and MCP Differ

Connecting an agent to a function is easy.

The harder problem arrives when the same system can use a shell, browser, database, GitHub, email, Slack, internal APIs, MCP servers, skills and plugins. Which capabilities should the model see? Which one should it choose? Who is allowed to execute it? What should come back into the next reasoning step?

Consider an agent asked to find overdue invoices for the week, prepare reminder drafts and send them after approval:

The invoice query might be a tool, an SQL CLI or an MCP tool.
Reminder rules and writing guidance might belong in a skill.
A pre-send review could be a hook or a policy gate.
Gmail integration might be installed by a plugin or exposed by an MCP server.
A2A only becomes relevant if the work is delegated to an independent finance agent.

Those terms are not synonyms, and they do not occupy the same architectural layer.

Capability engineering covers how capabilities are described, discovered, selected, authorised, executed, observed and governed over time. Putting function names into a prompt completes only a small part of that work.

Responsibility layers for tools, skills, plugins, hooks, MCP and A2A

Figure 5-1 | A tool is an executable unit; a skill packages a method; a plugin extends a host; a hook attaches behaviour to a lifecycle point; MCP and A2A address different interoperability boundaries.

Separate the terms before selecting the technology

Capability systems often fail because the same label means different things across products. Rather than memorising one framework’s vocabulary, identify the question each mechanism answers.

Term	The question it answers	Typical content
Tool	What specific capability can the agent execute?	`search_documents`, `run_tests`, `send_email`
Command	Which explicit entry point did a user or system invoke?	`/eval`, a CLI command, an API route
Skill	What method should the agent follow for this class of task?	SOP, tool order, decision rules, acceptance criteria
Plugin	Which package of capabilities can this host install?	Tools, skills, commands, hooks, UI, configuration
Listener	Who receives a notification after an event?	Telemetry, audit, analytics
Hook	What behaviour runs at a lifecycle point?	`PreToolUse`, `PostCompact`, `SessionEnd`
Middleware	What wraps a request or response pipeline?	Authentication, tracing, normalisation, rate limiting
Interceptor	What may inspect or alter a particular operation?	Tool validation, approval, policy extension
MCP	How does an AI host connect to external tools, resources and prompts?	Host, client and server capability protocol
A2A	How do independent agents discover one another and manage delegated work?	Agent Card, Task, Message, Artifact
Full harness protocol	How does a client drive the complete agent runtime?	Thread, turn, streaming, approval, diff, resume

A host may support several of these at once:

Harness
├── Command Router
├── Skill Library
├── Plugin Manager
│ └── MCP Client Adapter
├── Hook / Middleware System
├── Tool Registry
└── Policy / State / Verification

This tree is not a maturity ranking. It marks responsibility boundaries.

A tool is an executable unit. A skill tells the agent how to carry out a class of work. A plugin installs a package into a host. A hook inserts behaviour into an existing lifecycle. MCP exposes capabilities across processes or products. A2A treats another agent as a remote collaborator with its own runtime.

Calling all of them “tools” removes the precision needed for architecture review.

Visible, discoverable, authorised and executed are different states

Capability governance is often compressed into one claim: “The model has this tool, so it can use it.”

That claim merges several states:

Registered: the tool contract exists in the registry.
Discoverable: the current actor may see its catalogue metadata.
Model-visible: the complete schema is loaded into this turn.
Authorised for this call: the actor may perform this operation on the canonical resource.
Executed with a known outcome: the runtime has run it and committed a correlated terminal result.

Appearing in model context establishes at most part of the first three. It does not establish per-call permission or prove that an external side effect completed.

The same boundary applies to built-in tools, plugin tools, MCP tools and server-executed tools. Execution location may vary, but the product still needs owners for identity, tenant scope, business policy, approval, side-effect evidence and completion.

A production tool call does not jump directly from model output to a handler

A structured tool request is a proposed operation.

A more complete execution lifecycle is:

Resolve catalogue snapshot
→ Parse and schema-validate
→ Canonicalise arguments and resources
→ Classify effect, risk and concurrency
→ Final authorisation / approval
→ Bind execution context
→ Execute in boundary
→ Normalise result
→ Commit audit and observation

Tool Execution Lifecycle

Figure 5-2 | The harness resolves one canonical operation before applying resource-specific authorisation, execution controls and correlated result commitment.

Resolve the catalogue snapshot

The runtime fixes:

stable tool identifier
tool version
catalogue version
handler or transport
host, tenant, region and runtime availability
name-collision policy
deprecation or disabled state

A model-produced name is not an executable pointer.

If the model saw billing.send_reminder@v2 and only a semantically different v3 remains at execution time, the runtime should return a structured stale or unavailable result. It should not silently substitute another tool.

Parse and schema-validate

The runtime checks request structure, required fields, types, enums, formats and additional-property rules.

Schema validity establishes shape. It does not establish that the resource is correct or authorised.

Canonicalise arguments and resources

Policy has to evaluate the operation that will actually run.

For example:

./exports/../payments/config.json

If policy evaluates the raw string and the file API resolves it later, authorisation and execution may refer to different resources.

A safer order is:

Parse
→ resolve aliases
→ canonicalise path / URL / entity / command
→ resolve resource identity
→ evaluate policy against that operation

A coarse entitlement filter may run before catalogue search to prevent metadata leakage. Per-call final authorisation must still happen after canonicalisation.

Classify effect, risk and concurrency

The same tool can have different risk for different arguments:

read_file against a README or credential directory
run_sql for SELECT or DELETE
send_email to a test account or a customer
deploy to preview or production

Each call should be classified for:

read, write, destructive or external-send effect
sensitive data
financial or production impact
idempotency
shared-resource conflict
parallel-execution safety
human approval

Tool annotations may inform policy; they are not security guarantees. The MCP 2025-11-25 tools specification requires clients to treat annotations as untrusted unless they come from trusted servers.¹

Apply final authorisation and approval

The decision should bind to actor, tenant, workspace, canonical resource, action, argument digest, tool and catalogue versions, policy version and current state version.

A useful decision set is:

allow | deny | ask | passthrough

A lower-authority hook or plugin must not override a higher-authority denial. A typical precedence might be:

Immutable / hard deny
> enterprise or tenant deny
> resource-specific deny
> mandatory ask
> session grant
> project or user allow
> default policy

The exact sources may differ. Precedence must be testable, traceable and fail closed on unresolved conflict.

Bind and execute

Before execution, the runtime binds:

least-privilege credentials
sandbox, filesystem and network boundaries
timeout and cancellation
rate and concurrency limits
idempotency key
external operation identifier
trace, run and tool-call identifiers

Credentials should not come from model arguments or become available merely because a skill or plugin requested them.

Execution outcomes should distinguish:

success
validation_failed
permission_denied
approval_required
timeout
cancelled
partial
background_accepted
unknown_outcome
unavailable_tool

Failure does not establish the absence of a side effect. Retry, idempotency, unknown outcomes and compensation are covered in Part 08.

Normalise the result

Raw API, CLI or MCP results should not be copied directly into model context.

A normalised result should include terminal status, structured output, error taxonomy, retryability, provenance, external operation identifier, latency, partial state, redaction, and an artefact reference or pagination.

The complete payload may be retained as an artefact. The model receives only the bounded observation needed for the next step.

Commit audit and observation

The audit record and model-visible observation are different products.

Audit may retain a canonical-argument digest, policy-decision identifier, approval identifier, catalogue and tool versions, start and finish times, external operation identifier, result hash and unknown state.

The observation answers a narrower question: what does the model need for its next decision?

Every tool request must receive one correlated terminal result. Background work may emit progress and a later completion event, but that completion must not masquerade as a second result for the original request.

A tool contract needs execution semantics, not only parameter shapes

A governable registry entry needs more than a name and input schema.

The following is illustrative rather than a standard product schema:

{
 "id": "billing.invoice.send_approved_reminders",
 "version": "2.1.0",
 "owner": "billing-platform",
 "description": "Send reminders for an approved reminder batch.",
 "input_schema": {
 "type": "object",
 "properties": {
 "batch_id": {"type": "string"},
 "approval_token": {"type": "string"}
 },
 "required": ["batch_id", "approval_token"],
 "additionalProperties": false
 },
 "output_schema": {
 "type": "object",
 "properties": {
 "operation_id": {"type": "string"},
 "sent_count": {"type": "integer"},
 "failed_count": {"type": "integer"}
 },
 "required": ["operation_id", "sent_count", "failed_count"]
 },
 "effects": ["external_send", "customer_communication"],
 "risk_class": "high",
 "approval_class": "mandatory",
 "idempotency": {"required": true, "scope": "batch_id"},
 "concurrency": "exclusive_per_batch",
 "timeout_ms": 15000,
 "error_taxonomy": [
 "approval_invalid",
 "batch_stale",
 "rate_limited",
 "unknown_outcome"
 ],
 "redaction": ["approval_token"],
 "deprecated": false
}

This illustrates that a registry may need:

stable identifier, version and owner
input and output contracts
side effects and risk
approval and idempotency
concurrency
timeout
error taxonomy
sensitive-field redaction
deprecation

It does not show that fifteen seconds is a suitable timeout, that the handler is idempotent, that business authorisation is correct, or that a model can select the tool reliably.

A contract is the entry point for governance, not a quality certificate.

New tools should fail closed. Before review, they should not be assumed to be read-only, safe for concurrent execution, automatically approved or idempotent.

The Agent-Computer Interface is a user interface

Anthropic places the Agent-Computer Interface, or ACI, alongside the Human-Computer Interface and recommends investing comparable care in tool documentation and testing.²

Function calling does not make an ambiguous interface clear merely because it uses JSON.

A strong ACI tends to provide:

names with distinct, stable meanings
parameters that can be understood without hidden formatting rules
enums and controlled resource identifiers instead of vague free text
a visible separation between reads and destructive actions
stable result structures
errors that explain how the call can be corrected
pagination, field selection or artefact references for large results
neighbouring tools whose purposes can be distinguished by the model

Do not hide an entire business domain behind `manage()`

This interface looks flexible:

{
 "name": "manage_invoice",
 "arguments": {
 "action": "string",
 "payload": "object"
 }
}

The model must now infer the permitted action values, payload shapes, reversibility and success semantics.

A safer interface might expose:

search_overdue_invoices
preview_reminder_drafts
approve_reminder_batch
send_approved_reminders

The purpose is not to maximise the tool count. It is to create enforceable boundaries around meaning, permission and side effects.

Poka-yoke: make common errors difficult

Instead of repeating “be careful” in the prompt, the interface can remove some invalid paths:

accept a controlled invoice_id rather than arbitrary SQL
separate Preview from Commit
allow the send tool to accept only an approved draft_batch_id
require an approval_token for a high-risk action
avoid a field that accepts dates, timestamps and natural-language time expressions at once

ACI quality must eventually be measured with real model behaviour: wrong-tool selection, invalid arguments, correction attempts, completion time and confusion between adjacent capabilities. A tidy schema proves that the schema is tidy.

More capability is not always better: the surface has a budget

Every active tool, skill, plugin instruction and MCP server consumes context and selection attention.

Anthropic’s context-engineering guidance highlights bloated or overlapping tool sets as a common source of ambiguous decisions. Tools should be self-contained, clearly differentiated and economical in what they return.³

A Capability Surface Budget includes:

tool names and descriptions
input and output schemas
examples
skill metadata and instructions
server-level guidance
hook behaviour
policy guidance
error documentation
tool-result payloads

A more useful activation model is:

Always-on core capabilities
+ task-retrieved tools
+ explicitly activated skills
+ temporary subagent capabilities

It is rarely helpful to expose every capability in the organisation on every turn.

Capability surface budget and dynamic discovery

Figure 5-3 | Keep a small always-on surface, retrieve a limited candidate set from the catalogue for the current task, then authorise each call at runtime. Discovery is not permission.

Dynamic tool discovery: restrict discoverability before search

As the catalogue grows, loading every complete schema increases cost, confusion and cache churn.

A stronger discovery path is:

Task intent + actor scope
→ filter discoverable catalogue metadata
→ search candidate tools
→ return a small candidate set
→ load complete schemas from one catalogue snapshot
→ model proposes a call
→ canonicalise operation
→ per-call final authorisation
→ execute

Catalogue metadata should include:

stable identifier, name, version and owner
description and example tasks
input and output schemas
domain, tags and namespace
side-effect, risk and approval class
latency and cost class
tenant, region and entitlement availability
deprecation state
compatibility constraints

Discovery relevance is not authorisation

Semantic search establishes task relevance.

If catalogue metadata is itself sensitive, actor, tenant, region and entitlement filters should run before search. Execution authority is still re-evaluated after the canonical operation exists.

The embedding model is not the permission engine.

Use one coherent catalogue snapshot

One model turn should see coherent versions of:

model-visible schemas
execution handlers
policy metadata
prompt guidance
discovery index
audit metadata
catalogue version

Plugin enablement, MCP disconnection, tool upgrades and policy changes should invalidate schema caches, prompt tool sections, discovery indexes, authorisation caches, subagent catalogues and replay or evaluation manifests.

When a server disappears or a tool is revoked, the runtime should increment the catalogue version and return unavailable_tool for stale requests. It must not use a removed handler or silently map the request to a namesake.

Skills, plugins and hooks carry different responsibilities

A skill packages a reusable method

A skill behaves like an on-demand SOP. It may contain:

activation conditions
a task-specific decision procedure
recommended tool order
failure handling
templates
scripts
references
acceptance criteria
evaluation cases

The public Agent Skills specification requires a directory containing at least a SKILL.md file and permits scripts/, references/, assets/ and other files. SKILL.md includes frontmatter with required name and description fields; allowed-tools is currently marked experimental.⁴

invoice-reminder/
├── SKILL.md
├── scripts/ # optional
├── references/ # optional
├── assets/ # optional
└── ...

This article additionally recommends evals/ or extra metadata for maintainability. Those are not required Agent Skills directories.

A skill may recommend tools and load its method through progressive disclosure. It does not raise runtime permission merely by declaring allowed-tools.

A skill should not contain:

secrets, tokens or private URLs
repository-specific facts presented as a universal method
undisclosed destructive behaviour
a large manual forced into every turn
instructions that cannot be evaluated or traced

A plugin is a package installed under a host contract

There is no single plugin format across all agent hosts. In this series, a plugin means a capability package installed under a particular host’s discovery, installation, registration, permission and lifecycle contract.

It may contain:

tools
skills
commands
hooks
UI
configuration
MCP client or server settings

A plausible lifecycle is:

Discover
→ validate provenance and compatibility
→ install
→ initialise
→ register
→ enable
→ execute
→ upgrade / disable
→ unload / revoke

A manifest should describe:

unique identifier, name and version
host and API compatibility
entry point
requested permissions and resources
bundled capabilities
configuration schema
migration and rollback
publisher, provenance, digest or signature
disable and revoke path

A plugin must not bypass the host’s tool registry, tenant boundary, sandbox or immutable denials. An extension’s authority ceiling cannot exceed the security core it extends.

A hook attaches behaviour to a stable lifecycle point

Hooks attach validation, logging, context injection, cleanup and policy extensions to explicit events rather than turning the core loop into intertwined conditionals.

Common event points include:

SessionStart
UserPromptSubmit
PreModelCall / PostModelCall
PreToolUse / PostToolUse / ToolFailure
PreCompact / PostCompact
TaskCreated / TaskCompleted
Stop / SessionEnd
ConfigChanged
WorkspaceChanged

The event name is not the contract. A production hook definition needs:

trigger timing
input and output schemas
whether input or output may change
whether the hook may block, ask, cancel or retry
authority ceiling
multiple-hook ordering
conflict resolution
timeout
failure policy
side-effect policy
trace fields
re-entrancy guard

Several hooks should not always be composed through “first non-empty result wins”. Denial and cancellation generally have high precedence; additional context may accumulate within a budget; updated input needs explicit conflict resolution; retry requests remain subject to budgets and idempotency.

Critical security hooks should fail closed. A non-critical telemetry listener may fail open when its risk allows it.

Listener, hook, middleware, interceptor and policy gate

Mechanism	Typical semantics	May change the main flow?
Listener	Receives notification after an event	Usually no
Hook	Runs an extension at a lifecycle point	Depends on the contract
Middleware	Wraps a pipeline	Yes
Interceptor	Intercepts a specific operation	Yes
Policy gate	Applies authority to allow, deny or ask	Must be able to

Do not infer authority from the name.

A PreToolUse hook that can deny an operation behaves as an interceptor or policy extension. It still cannot override enterprise denial, tenant isolation, sandbox boundaries or mandatory approval.

A listener that can be removed by a plugin should not be the only enforcement mechanism for a critical rule.

Select the integration surface by the interaction semantics you must preserve

The same capability may be exposed through a CLI, SDK, MCP or a complete app-server protocol. The choice is not merely stylistic. Each surface preserves a different amount of lifecycle information.

Selection matrix for full harness protocol, MCP, SDK and Exec

Figure 5-4 | Choose an integration surface according to session lifecycle, streaming, approvals, artefacts, diffs, portability and deployment boundaries.

Full harness protocol or App Server

Use a richer protocol when the client needs:

a durable thread lifecycle
bidirectional streaming
approval requests and responses
incremental progress
diffs and artefacts
pause, resume, fork and archive
a rich client UI

When OpenAI designed the Codex App Server, the team first experimented with exposing Codex as an MCP server. The VS Code integration needed richer session semantics, diff updates and server-initiated approval flows, so they adopted a bidirectional JSON-RPC surface that mirrors more of the complete agent loop. OpenAI now distinguishes invoking Codex through MCP as a callable tool from using the App Server when the full harness surface is required.⁵

MCP

MCP is a good fit when:

the host already has an MCP client
the capability should be reusable across AI applications
tools, resources and prompts are sufficient
full provider-specific session semantics are not required

MCP uses a host, client and server architecture with JSON-RPC messages. It supports capability negotiation, tools, resources, prompts, progress, cancellation and logging.⁶

That makes it a broad capability protocol, not a universal replacement for every harness lifecycle.

SDK or library

An SDK suits:

embedding inside an application using the same language
direct control over local runtime APIs
avoiding a separate client protocol

The trade-off is tighter coupling across process, language, upgrades and isolation.

Exec or CLI

Exec and CLI modes suit:

one-shot automation
CI and batch work
clear exit codes
structured standard output
established authentication and operator workflows

MCP does not make a mature CLI obsolete. When the model already understands the commands, output can be reduced with tools such as jq or grep, and the command set is small, a CLI may remain the lower-cost and more testable surface.

It is less suitable for long-lived bidirectional interaction, detailed approval UI and durable session control.

MCP and A2A: capability integration and agent collaboration

MCP and A2A operate at different interoperability layers.

MCP and A2A responsibility boundary

Figure 5-5 | An agent may use MCP for tools, resources and prompts, and A2A for tasks, messages and artefacts with another independent agent. Remote completion still passes through local acceptance.

MCP connects a host to capability providers

The main relationship is:

AI Host
└── MCP Client
 └── MCP Server
 ├── Tools
 ├── Resources
 └── Prompts

The server may wrap a database, SaaS API, filesystem, search service or another capability.

MCP tool descriptions, annotations and resource content are not automatically trustworthy. The host validates source, version and permission boundaries.

A2A connects independent agent systems

A2A 1.0.0 targets independent, potentially opaque agent systems and defines discovery, messages, tasks, artefacts, streaming and long-running interaction. One goal is collaboration without exposing internal state, memory or tool implementations.⁷

A2A is appropriate when the remote party has:

its own runtime
its own task state
potentially long-running work
streaming or push updates
artefact production
a cross-team, framework or vendor boundary

If the compliance service is only a structured rules check, a tool or service API may be simpler. Wrapping a function as an agent adds task lifecycle, authentication, retry, versioning and remote-trust costs.

They can be composed

Agent A
├── MCP → Billing Tools / Customer Data
└── A2A → Compliance Agent B
 └── MCP → Policy Database / Audit Tools

The official A2A material describes the protocols as complementary: MCP handles tool and resource integration, while A2A handles agent-to-agent coordination.⁸

However:

agent discovery is not trust
an Agent Card needs source, version, signature or endpoint validation
delegation carries actor, tenant, scope and provenance
a remote completed state does not establish local task acceptance
push callbacks need replay protection and allow-lists
extensions need compatibility policy

The local harness still applies its own contract, policy and evidence through a local acceptance gate.

Plugins and MCP may be composed

A compact distinction is:

Plugin = a capability package installed into a host
MCP = a standard protocol between a host and external capabilities

A plugin may:

install an MCP client adapter
manage an MCP server’s configuration and lifecycle
provide UI, commands, skills and hooks alongside it

An MCP server may itself be installed by a plugin.

A plugin is often natural when the capability serves one host and needs deep UI or lifecycle integration. MCP becomes attractive when the same service should be reused across IDEs, agents and runtimes.

Do not rewrite the business implementation simply to claim MCP support. Keep the protocol adapter thin and retain the core rules in an independently testable service or library.

Programmatic tool calling moves mechanical data work out of the main context

A conventional tool loop may run a model inference after every call and append each raw response to the transcript.

For large queries, filtering, aggregation and transformation, that pattern increases both latency and context pollution.

Programmatic tool calling lets the model generate controlled code that invokes allowlisted tools inside a sandbox. Only the necessary summary, evidence and errors return to the main context.

Suitable workloads include:

aggregating many API requests
analysing CSV, JSON or logs
filtering large document sets
deterministic dependencies between tools
large raw data with a small final set of statistics or citations

Required boundaries include:

sandboxed generated code
a tool allowlist
CPU, memory, network, wall-clock and call budgets
credentials kept out of generated code
raw results retained in the isolated environment by default
tighter controls around side-effecting tools
traces for generated code, tool calls and outputs

The point is not to grant arbitrary execution power. It is to move programmable mechanical work outside the limited reasoning window.

MCP is not the required starting point

A script does not become reliable because a protocol is placed in front of it.

A healthier maturity path is:

Library
→ Stable CLI / API
→ Machine-readable Output
→ Agent-ready SOP and Safety Rules
→ Structured Service Adapter
→ MCP Server or Host-specific Plugin
→ Optional Third-party Extension Surface

Stabilise the underlying capability first:

a predictable interface
explicit error codes
timeout and cancellation
separate read and write actions
defined idempotency
a run identifier and trace
observable authentication and human-action state

Then decide whether MCP, a plugin or an SDK is warranted.

Otherwise the result is simply an unreliable script that more agents can call remotely. Portability improves, and the blast radius goes sightseeing.

Evaluate tool quality in layers

A tool being callable proves that transport and parsing work.

Part 10 develops full evaluation. Part 05 needs five layers:

Layer	Main question
Definition	Are name, description, schema, examples and errors understandable?
Selection	Does the model choose the right tool and avoid unnecessary calls?
Arguments	Are resource, scope, format and permission inputs correct?
Execution	Are latency, timeout, rate limiting, idempotency and side effects reliable?
Outcome	Did the task complete with sufficient evidence at reasonable cost?

Model-generated feedback can be a diagnostic candidate. It does not replace ground truth, metrics and adversarial cases.

Walk through the invoice-reminder task

Return to the opening task: find overdue invoices, prepare reminders and send them after approval.

Existing CLI or library

If the billing system already has a stable read-only CLI, keep it:

billing invoices overdue --account <id> --format json

It handles the query. It does not send email, and it does not let the model invent the tenant scope.

Skill

An invoice-reminder-skill can describe:

when the process applies
overdue-invoice rules
the recommended query sequence
accounts that must not be handled automatically
fields required in each draft
the step that must wait for approval
completion evidence

Tools

The harness exposes narrowly bounded tools:

search_overdue_invoices
preview_reminder_drafts
request_batch_approval
send_approved_reminders

send_approved_reminders accepts only an approved batch identifier.

Hook or policy gate

PreToolUse(send_approved_reminders) checks:

whether the approval token is valid
whether the batch still has the approved version
whether recipients remain in scope
whether the daily send limit has been exceeded

An audit listener records the outcome but does not own allow or deny authority.

Plugin or MCP

If the Gmail integration serves only this host and needs host-specific UI, OAuth configuration and approval screens, a plugin is a natural package.

If several agent runtimes need the same mail capability, keep a shared Mail Service and expose it through a thin MCP server.

A2A

A2A is justified only if compliance review is delegated to another agent with independent state, a task lifecycle and collaborative interaction. If compliance is a bounded structured check, an ordinary tool or service API may be more appropriate.

There is no universal answer, but each responsibility should have an explicit owner.

A practical capability-selection sequence

For a new integration requirement, ask:

Is this a concrete operation, reusable method, host extension or remote agent?
Is there already a stable library, service, API or CLI?
Does the tool have a stable identifier, version, owner, input/output contract and error taxonomy?
Are model visibility, discovery, per-call authorisation and execution separate?
Are arguments canonicalised before final policy evaluation?
Are risk, concurrency, idempotency and approval evaluated per call?
Is the active capability surface small enough to evaluate for the task?
Are the catalogue snapshot, handlers, policy metadata, index and caches coherent?
Are provenance, permissions, authority ceiling and revocation clear for skills, plugins and hooks?
Does the integration require rich session semantics, or is a callable capability sufficient?
Is the remote party a capability provider or an agent with its own task lifecycle?
How are definition, selection, arguments, execution and outcome tested?

If questions two to six remain unanswered, an MCP server is premature. A protocol cannot supply a stable core contract.

Theory to practice: Part 05 checklist

References

Model Context Protocol, Tools specification 2025-11-25, accessed 8 July 2026. ↩
Anthropic, Building effective agents, 19 December 2024. ↩
Anthropic, Effective context engineering for AI agents, 29 September 2025. ↩
Agent Skills, Specification, accessed 8 July 2026. ↩
OpenAI, Unlocking the Codex harness: how we built the App Server, 4 February 2026. ↩
Model Context Protocol, Specification 2025-11-25, accessed 8 July 2026. ↩
A2A Protocol, Agent2Agent Protocol Specification 1.0.0, accessed 8 July 2026. ↩
A2A Protocol, A2A and MCP: Detailed Comparison, accessed 8 July 2026. ↩