The tool family below is a documented contract: each tool mirrors one Intent API operation and is held to that operation’s request and response schemas. composerID does not yet run a hosted MCP server. An agent reaches these tools through the REST operation each one names, served today by the reference sandbox. Separately, the “Connect to MCP” option in the menu on every page of these docs connects an assistant to the Mintlify-hosted documentation server, which searches and reads this documentation. It does not call the Intent API.
The front-door rule
An agent may browse and read the destination system freely. When a decision is required it callsintent_create; it never creates records in the destination directly. composerID then mints the Intent ID, plans, preflights and publishes, and the destination system keeps its role as the system of record.
Tools
intent_create
Intent: initialises a record and returns a stable intent_id
intent_create
Intent: initialises a record and returns a stable intent_id
Mirrors
POST /v1/intent (scope intents:write). Input schema IntentCreateRequest: a payload object of canonical intent fields such as channel, role_title, start_date, location and quantity. Output schema IntentRecord. The intent_id it returns never changes; later amendments bump intent_version.intent_patch
Intent: updates the diagnostics, routing and admin payloads
intent_patch
Intent: updates the diagnostics, routing and admin payloads
Mirrors
PATCH /v1/intent/{intent_id} (scope intents:write). Input schema IntentPatchRequest; output schema IntentRecord. A patch bumps the intent’s version.plan_generate
Routing: applies the Channel Map to identify the target destinations
plan_generate
Routing: applies the Channel Map to identify the target destinations
Mirrors
POST /v1/plan (scope intents:write). Input schema PlanGenerateRequest; output schema PlanGenerateResponse.mapping_preflight
Routing: validates the intent against the destination's requirements and returns enrichment gaps
mapping_preflight
Routing: validates the intent against the destination's requirements and returns enrichment gaps
Mirrors
POST /v1/preflight (scope intents:write). Input schema PreflightRequest; output schema PreflightResponse. When the tenant’s mandatory fields are not satisfied the REST operation answers 422 with an enrichment_request, surfaced before anything is published.adapter_publish
Execution: idempotent publish that records external IDs and a receipt
adapter_publish
Execution: idempotent publish that records external IDs and a receipt
Mirrors
POST /v1/publish (scope publish). Input schema PublishRequest; output schema PublishReceipt. Publishing is idempotent on {intent_id}-{intent_version}-{target_system}: a replayed publish returns the stored receipt with replayed: true and never creates a second record in the destination.Guardrails
State guardrails
State guardrails
Each transition requires a minimum viable intent. Overrides are never silent: they are recorded as explicit events in the intent’s timeline.
Enrichment loop
Enrichment loop
If the target system needs fields the intent lacks, emit an
enrichment_request rather than failing the publish. The gap goes back to the requester through POST /v1/enrichment-request, and the answers fill it without a version bump.Passthrough with anchors
Passthrough with anchors
Raw platform calls are allowed through
POST /v1/passthrough (scope passthrough), but every one carries the intent_id, the version and a rationale, recorded in the timeline.Next steps
Authentication
The scope each tool’s REST operation requires.
API reference
The Intent API the tools mirror, generated from its OpenAPI document.
Quickstart
Run the sandbox the tools call today.