Connect AI Agents to Humans with MCP

MCP

The goal of MCP is to expose human execution as a small set of tools that an AI agent can discover and invoke. Its contract should make real-world uncertainty explicit while remaining familiar to engineers building software and agent workflows.

When an agent should call a human

When an agent should call a human should be documented as an explicit part of this interface. The caller needs to know which fields affect routing, which values are authoritative and which states can change after a human has accepted work.

MCP tool surface

A production treatment of MCP tool surface needs both the normal path and the exception path. Human execution is reliable only when the client knows what happens when the environment does not match the request.

get_quote(capability, location, deadline)
create_task(capability, location, instructions, evidence_required, budget)
get_task_status(task_id)
get_evidence(task_id)
request_revision(task_id, missing_items)

Tool descriptions and schemas

Tool descriptions and schemas should be documented as an explicit part of this interface. The caller needs to know which fields affect routing, which values are authoritative and which states can change after a human has accepted work.

get_quote(capability, location, deadline)
create_task(capability, location, instructions, evidence_required, budget)
get_task_status(task_id)
get_evidence(task_id)
request_revision(task_id, missing_items)

Permission and spend boundaries

A production treatment of Permission and spend boundaries needs both the normal path and the exception path. Human execution is reliable only when the client knows what happens when the environment does not match the request.

Task state inside an agent loop

Task state inside an agent loop is where the implementation should expose physical-world constraints rather than abstracting them away. If access, timing, identity or evidence changes the result, the schema should say so.

MCP versus direct REST

For MCP versus direct REST, prefer a small number of well-defined fields over free-form conventions. The physical worker may read natural-language instructions, but software should get structured values for anything that affects control flow.

Tool Descriptions Are Control Logic

An MCP tool description influences when a model chooses human execution. It should say what the tool can do, what information is required, what it costs conceptually and when another source should be tried first. Ambiguous descriptions can cause unnecessary dispatches or under-specified tasks.

Keep the Tool Surface Small

A compact tool set is easier for models to select correctly. create_task, get_task_status and get_evidence can cover many workflows when the task schema carries capability-specific fields. New tools should exist because the operation differs, not because a new marketing page exists.

Agent Loop Design

The agent should create the task, persist its ID and suspend or branch its plan rather than repeatedly creating new work while waiting. When the result arrives, the agent validates required fields before treating the physical fact as true. That pattern keeps human latency compatible with autonomous planning.

Error Model

Model offline exceptions deliberately. The important question is not only whether a request was valid but whether the intended observation or action could occur under real conditions.

Production Readiness

A release checklist should cover authentication, idempotency, spend limits, exception states, evidence permissions and reconciliation between events and canonical objects.

Common Integration Mistake

Tool descriptions must tell the model when not to call a human; otherwise an agent may dispatch work for questions it could answer digitally.

Next Step

Implement one mcp flow against the canonical task lifecycle, inspect the real payloads and only then generalize the client for more capabilities or locations.

Implementation Notes for MCP

When an agent should call a human

When implementing when an agent should call a human for MCP, define the contract in a way that another service can validate without reading hidden UI state. Document required fields, optional fields, state-dependent behavior and at least one exception. Because HumanTask API can create real-world work, every ambiguous write operation should also have a traceable client reference or audit path.

MCP tool surface

When implementing mcp tool surface for MCP, define the contract in a way that another service can validate without reading hidden UI state. Document required fields, optional fields, state-dependent behavior and at least one exception. Because HumanTask API can create real-world work, every ambiguous write operation should also have a traceable client reference or audit path.

Tool descriptions and schemas

When implementing tool descriptions and schemas for MCP, define the contract in a way that another service can validate without reading hidden UI state. Document required fields, optional fields, state-dependent behavior and at least one exception. Because HumanTask API can create real-world work, every ambiguous write operation should also have a traceable client reference or audit path.

Permission and spend boundaries

When implementing permission and spend boundaries for MCP, define the contract in a way that another service can validate without reading hidden UI state. Document required fields, optional fields, state-dependent behavior and at least one exception. Because HumanTask API can create real-world work, every ambiguous write operation should also have a traceable client reference or audit path.

Task state inside an agent loop

When implementing task state inside an agent loop for MCP, define the contract in a way that another service can validate without reading hidden UI state. Document required fields, optional fields, state-dependent behavior and at least one exception. Because HumanTask API can create real-world work, every ambiguous write operation should also have a traceable client reference or audit path.

MCP versus direct REST

When implementing mcp versus direct rest for MCP, define the contract in a way that another service can validate without reading hidden UI state. Document required fields, optional fields, state-dependent behavior and at least one exception. Because HumanTask API can create real-world work, every ambiguous write operation should also have a traceable client reference or audit path.

Test Matrix

A MCP integration should be tested against more than the happy path. Include a valid request, invalid input, duplicate retry, no matching supply, worker exception, incomplete evidence and cancellation where the interface supports it. The result of each test should be observable in the canonical task object so developers can reconcile UI, API and agent behavior.