GEgetaxonflow
MCP Connectors

Execute MCP command (write)

Execute a write command via an MCP connector.

This follows the MCP Tool pattern for data modification. For read operations, use /mcp/resources/query.

Audit Logging

All MCP execute operations are automatically logged to the mcp_query_audits table with:

  • Request phase: SQLi detection results, dangerous operation blocking
  • Result: Rows affected, success/failure, error messages, duration

Each audit entry includes audit_id for correlation. Operation type (INSERT, UPDATE, DELETE) is stored in the operation field.

post/mcp/tools/execute

Request

Headers

X-Axonflow-Approval-Idstring uuid

The approval a retry spends (#4370). A call held for a person's approval is answered a pending_approval naming an id; once a person approves it in the portal, the caller retries the SAME call naming that id here (or in the body's approval_id field, for a client that cannot set headers - a header and a field naming different ids are refused approval_not_found).

The retry is decided exactly as the first call was. Only when it is again held for approval, and the approval is approved by a person who is not the caller, before its expiry, unspent, and granted for this very call (the same input, tool, route, requester and requirement), does it pass - and the approval is spent: it admits exactly one call. A call that is allowed anyway spends nothing; no approval lifts a deny. Every other outcome is refused with one of the ApprovalHoldReason codes. Enterprise; the Community build has no approval queue and ignores the header.

WHAT "THE SAME CALL" MEANS. On the MCP routes: the connector, the tool, the operation, the statement and its parameters (and the row limit on /mcp/resources/query). On /api/v1/decide: the WHOLE request the engine decided - stage, target, query AND context. A retry that changes any of it is refused bound_input_changed: resend the same context, and carry per-request values (request ids, timestamps) in headers, never in context - the correlation id is a header.

Authorizationstring required
Example:Basic bXktb3JnOkFYT04tVjIteHh4

OAuth2-style Basic authentication header. Format: Basic base64(clientId:clientSecret)

  • clientId: Your organization identifier (required)
  • clientSecret: Authentication credential (optional for community mode)

Not required when DEPLOYMENT_MODE=community.

Request body

approval_idstring uuid

The approval a retry spends (#4370), for a client that cannot set the X-Axonflow-Approval-Id header (see that parameter). Never part of what the approval binds.

client_idstring required
license_keystring
user_tokenstring
connectorstring required
operationstring
action'INSERT' | 'UPDATE' | 'DELETE' required
statementstring
parametersobject
timeoutstring

Response

Command executed successfully

successboolean
connectorstring
rows_affectedinteger
duration_msinteger
messagestring
redactedboolean

Whether any fields in the response were redacted by policy

redacted_fieldsstring[]

JSON paths of fields that were redacted

engine'anchored'

Which policy engine authored this verdict: the ADR-065 decision plane, the only author on this route (PRD v11 §1.1). It rides this body and the 403 envelope of a refusal by the same pass. Omitted on a refusal no engine decided - an authentication failure, or a request refused before the policy pass ran.

subject_typestring

The type of principal the verdict was decided for (PRD v11 §1.6): User for a verified user token, Client when the request presented no user identity and its client credential is the principal. Omitted wherever engine is.

policy_bundlestring

The digest of the policy set that decided: the system corpus's restriction for this route and the organization root - the organization's active typed document composed with the deployment's baseline permission pack, or, while it has published nothing, the implicit bundle of that pack and the organization template. A rollback reinstates an earlier digest. Omitted wherever engine is.

policy_packsstring[]

The add-on policy packs (PRD v11 §1.9) whose controls composed into policy_bundle on the response pass, each as <pack id>@<digest of the pack document the deployment instantiated>, sorted. Omitted when the deployment installs no pack or none binds on this route.

Changes

No recorded changes to this operation across all 1 revision of this API.