Remote MCP Server for AI Agent Management

The platform exposes a remote Model Context Protocol (MCP) endpoint so external AI tools can create, manage, coordinate, message, wait on, and attach files to agents through your existing platform API key.

Remote MCP provides a conversational agent-timeline API. Each agent is a long-lived AI employee with one unified timeline, history, and context. MCP clients append messages to that timeline, read timeline events with durable cursors, and wait for matching timeline events. The MCP server does not create a separate task, run, conversation, or session abstraction for agent work.

Endpoint

Use the Streamable HTTP endpoint:

• Production: https://your-deployment.example/api/v1/mcp/

The platform reports protocol version 2025-11-25 in its initialize response and exposes JSON-RPC over Streamable HTTP. Each request is a new POST with one JSON-RPC object; batches are unsupported. The endpoint returns application/json for requests and 202 Accepted for notifications/responses. The platform does not open a standalone GET SSE stream in v1, so GET /api/v1/mcp/ returns 405 Method Not Allowed.

References:

• MCP Streamable HTTP transport: https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
• MCP tools protocol and structured tool results: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
• MCP resources and resource links: https://modelcontextprotocol.io/specification/2025-11-25/server/resources
• MCP schema reference: https://modelcontextprotocol.io/specification/2025-11-25/schema
• MCP HTTP authorization guidance: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization

Authentication

Use an existing platform API key. Send it on every request with either header:

X-Api-Key: $API_KEY

or:

Authorization: Bearer $API_KEY

Do not put API keys in query strings. Organization API keys scope tools to organization-owned agents; personal API keys select agents in the user's global personal workspace. Organization-private and Team agents require an organization key even if the personal-key owner created them. UI collaborator access does not expand that owner filter. Staff/superuser administrative targeting is described below.

Resource-scoped service credentials also use this MCP transport when both installation and Organization gates are enabled. Discovery returns their exact allowed tools within the current scope ceiling. They cannot use staff targeting, creation, messaging, timeline/wait/debug tools, human approvals or control administration. Supported mutations use identity-scoped replay across rotation, with current grants and every involved resource rechecked before returning a retained response. Member-key rules below remain unchanged.

Remote MCP also honors the key's access level. tools/list only advertises tools the key can call:

• agents:read: list/get/config, links, timelines, waits, debug traces, and resource/file reads.
• agents:operate: send_agent_message and upload_agent_file, in addition to read tools.
• agents:manage: agent configuration and links, plus Team, integration, credential-grant, and machine-identity mutations. Scope alone does not confer Organization or Team administration.

For application requests, agent-wide timeline/debug/wait and filespace list/read or attachment reuse are unavailable when any application history belongs to another principal/former owner or is purged. Use scoped request routes; broad tools return application_request_scope_required. Exact application attachment resources require current-principal retained root/reply/decision links and remain identity-bound across service rotation. Management scope and staff targeting do not implicitly inspect application data. The general filespace and generated model context are shared agent resources, not independent confidentiality compartments.

Organization keys retain their Organization boundary and the issuing member's current workspace and settings authority. Creating any current profile requires an active Owner or Admin. Every MCP request, including discovery, resource reads and response replay, requires the same issuer to retain active membership and Organization agent-management authority. Agent Admin can use a previously issued key. Member, Viewer and Security Admin keys cannot authenticate, including for control tools; those roles have no narrower Organization key profile. Personal keys can discover their own Organization membership metadata but must use an eligible Organization key to operate those resources.

Inactive or removed creators never inherit another administrator's authority. The Console shows unauthorized keys as Blocked, without changing their scopes or revoking them. Restoring the issuer's authority restores access unless the key was explicitly revoked. Browser approvals also check issuer authority, and an earlier approval does not authorize a retry after authority is lost. Blocking applies to subsequent requests and does not cancel already accepted work.

Client Request Shape

Initialize:

curl -X POST https://your-deployment.example/api/v1/mcp/ \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": "init-1",
    "method": "initialize",
    "params": {
      "protocolVersion": "2025-11-25",
      "capabilities": {},
      "clientInfo": {"name": "example-client", "version": "1.0.0"}
    }
  }'

List tools:

curl -X POST https://your-deployment.example/api/v1/mcp/ \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"jsonrpc":"2.0","id":"tools-1","method":"tools/list","params":{}}'

Call a tool:

curl -X POST https://your-deployment.example/api/v1/mcp/ \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": "call-1",
    "method": "tools/call",
    "params": {
      "name": "list_agents",
      "arguments": {"page_size": 10}
    }
  }'

The platform validates Mcp-Method and Mcp-Name request headers when clients send them. Read the version from the initialize response body's result.protocolVersion, then send that value in the MCP-Protocol-Version request header on subsequent calls. The current handler does not validate that header or select another version from the client's requested version. An accepted request therefore does not establish support for a different MCP version. See Errors and recovery for transport, JSON-RPC, and tool-result failures.

For create_agent and send_agent_message, send a unique Idempotency-Key header. The default retention is 24 hours. A replay returns Idempotency-Replayed: true; changing the tool arguments with the same key returns 409 Conflict. A new JSON-RPC request ID is allowed on a retry. See the complete retry contract.

Tools

Tool	Purpose
list_agents	List accessible persistent agents.
get_agent	Retrieve one agent.
create_agent	Create an agent through the platform's normal provisioning path.
update_agent	Update mutable agent settings.
archive_agent	Soft-delete/archive an agent.
get_agent_config_options	Discover supported agent config fields and option limits.
list_agent_links	List peer-agent links.
link_agents	Create or enable a peer-agent link.
unlink_agents	Remove a peer-agent link while preserving history.
send_agent_message	Send an authenticated platform MCP message to an agent, optionally uploading and attaching small files in the same call.
get_agent_timeline	Fetch timeline events and processing state using durable cursors.
get_agent_debug_trace	Fetch bounded, sanitized debugging context for one accessible agent.
wait_for_agent_event	Bounded long-poll for matching timeline events after a cursor.
read_agent_resource	Read a file or image from a agent:// resource URI as native MCP content.
list_agent_files	List the default filespace with scan/active/pending status and bounded limit/cursor pagination.
upload_agent_file	Upload a small base64 file into the agent filespace.

The platform exposes authenticated file resources alongside its tools. File and timeline results include resource_link content blocks; clients can use resources/read or read_agent_resource to retrieve the bytes. The platform does not expose MCP prompts.

Full input and output schemas for all 34 tools are in the generated MCP tool reference, also available as JSON. The live tools/list response is filtered to the key's scopes, rather than every resource's current permissions or readiness. Resource discovery uses resources/list (an empty list), resources/templates/list (file and attachment URI templates), and resources/read. Follow returned resource links to discover individual files.

Staff administrative targeting

Some agent tools declare optional user_id and organization_id inputs. Nonempty values require the authenticating user to be platform staff or a superuser; ordinary keys receive admin_scope_required. The key still needs the tool's scope. Consult the individual input schema: the workspace/integration control tools do not accept these overrides.

• user_id alone selects that active user's global personal workspace.
• organization_id alone selects an active Organization and resolves an active owning user there.
• Both select that Organization with the specified user, who must have an active membership.
• Without overrides, listings use the key's normal owner scope. Staff agent-ID lookups can additionally access a live, non-eval agent outside that scope.

Cross-account results can include access metadata identifying the operator, target, and requested scope. For send_agent_message with admin_access: true, the target agent's owner supplies the sender identity used for web-contact authorization and the stored conversation; the staff operator remains identified in access.operator_user_id. This staff mechanism does not give ordinary keys collaborator access or let a control tool administer another Organization. Treat the authenticated key's owner and the selected target as separate identities.

Agent Config

Use get_agent_config_options before setting operational config. It returns the current owner scope, supported fields, intelligence tiers, retired credit-field metadata, schedule semantics, and policy options for the API key.

The tools expose these configuration fields; consult each tool's input schema for which can be set on create versus update:

• preferred_llm_tier: the agent's preferred intelligence level. Values are the configured agent intelligence tier keys, commonly standard, premium, max, ultra, and ultra_max. Deployed intelligence policy and runtime limits are enforced.
• daily_credit_limit: Deprecated, inactive historical read retained until an explicit breaking-release decision. Setting it returns an actionable retirement error; usage tracking does not enforce credit budgets.
• schedule: optional cron-like schedule, @daily, or @every interval. On create, omitted, empty, or null means unscheduled. On update, omitted preserves the current schedule, while empty or null unschedules the agent. Invalid schedules return an MCP tool result with isError: true and field details.
• whitelist_policy and is_active: policy and lifecycle fields.
• proactive_opt_in: supported by both create_agent and update_agent. Creation defaults to true when omitted; false is persisted during provisioning.
• team_id: optional on creation. Choose an active Team returned by list_workspaces. Use move_agent for later placement changes. Agent reads and lists include team_id and an explicit workspace with Organization, Team, and primary user metadata.

Creation uses the same provisioning path as REST. Active creation requests initial processing and normally creates a separate first-check-in timer even with a null primary schedule. Prepare an inactive agent when configuration must precede execution; see creation and setup effects. MCP's config fields are narrower than REST: template_code, email_sending_mode, preferred_contact_endpoint, and enabled_personal_server_ids are not MCP create/update inputs. Use supported product settings for those fields.

update_agent changes only fields supplied in the call. Every omitted mutable field retains its current value. For nullable fields, send null explicitly to clear the value.

Unsupported fields are not ignored. A tool call with unsupported arguments returns isError: true with unsupported_fields and supported_fields.

Teams and integration setup

The control tool families are:

Workflow	Tools
Discovery and placement	list_organizations, list_workspaces, list_workspace_members, move_agent
Teams	create_team, update_team, set_team_member
Integrations	list_integrations, get_integration, configure_openapi_integration, set_agent_integration
Credentials	list_credentials, set_credential_grant, get_integration_setup
Machine identities	list_machine_identities, configure_machine_identity_destination, set_machine_identity_grant
Preflight	get_agent_readiness

For an Organization setup, use this sequence:

1. Discover list_workspaces and list_workspace_members. Control lists accept page from 1–10,000 and page_size from 1–100 (default 20); follow has_next. Organization-private workspace metadata accompanies the paged Team list.
2. Call create_team with a name and a client-generated UUID request_id. Complete the browser approval below, then retry identical arguments to obtain the Team ID.
3. Call create_agent with that team_id, is_active: false, and proactive_opt_in: false. Supply name when the Organization requires agent names; otherwise it is optional. Use the existing Idempotency-Key HTTP header for creation retries. Link the agents with link_agents.
4. Use list_integrations with kind: native or kind: openapi, then get_integration. Supply agent_id to inspect effective native connection ownership, skills, enabled tools, and scopes. A native catalog read without an agent reports connection status as unknown.
5. For OpenAPI, configure_openapi_integration supports create, update, import, operations, publish, enable, and disable. Its schema declares the fields required by each action. Import a bundled JSON/YAML specification without credentials, inspect its revision and paged operations, select supported operations, and publish the revision. Policies are read, autonomous, and approval.
6. Inspect list_credentials, then bind an existing OpenAPI credential with set_agent_integration. Only a member credential's owner can use set_credential_grant to share it with an agent they manage. Revoking a grant removes that agent's active binding and enabled integration tools. Organization agent administrators configure bindings and approvers; a member's grant alone does not confer that authority.
7. Run get_agent_readiness with the agent and integration. Optionally select one published OpenAPI operation_id or a native capability from discovery.

Team administration follows the console: Organization Owners, Admins, and Agent Admins have inherited Team authority. Team admins can manage membership and names; Team availability changes require Organization agent administration. Member creation remains subject to Organization policy and Team role. move_agent stays inside the current key's ownership boundary, preserves name-conflict checks, and removes inaccessible MCP assignments. Team-to-Organization-private moves remain disabled. Cross-Organization moves and personal/Organization transfers require the console's supported flow.

Workspace and agent secrets are inherited automatically under their existing ownership and domain restrictions. They are not copied or rebound to unrelated agents. Native connections similarly follow the effective workspace's connection precedence; set_agent_integration enables/disables the associated system skill and tools using existing services. Disabling a skill does not revoke credentials or remove shared tools. Managed native MCP connections are inherited by the workspace and do not support an independent per-agent connection toggle. Agent email authentication remains an authenticated console workflow.

Machine-identity viewing and management require their separate Organization capabilities: agent administration alone is insufficient. Organization security administrators can grant access to governed agents, as in the console. Destination configuration preserves public/private network restrictions, method/path grants, custom trust semantics, and audit. Certificate import and custom CA entry use the authenticated console. Readiness never decrypts certificate material.

Browser approval and secure entry

All new mutation tools require a UUID request_id. Reuse it with identical arguments for retries. Team and machine-identity mutations first return:

{
  "status": "action_required",
  "code": "recent_authentication_required",
  "request_id": "client-generated-uuid",
  "action": {
    "type": "browser_approval",
    "url": "/console/mcp/authorizations/request-uuid/"
  },
  "retry": {"tool": "create_team", "same_arguments": true}
}

Resolve relative URLs against the deployment's origin. The key issuer signs in, reviews the exact request, and approves it in the browser. This preserves Organization SSO, MFA, recent-authentication and session-revocation checks. Approval lasts at most ten minutes and may expire sooner under Organization session policy. Approval itself does not execute the mutation: retry the same MCP call. Roles and resource access are checked again. A completed request replays its result with replayed: true; changed input returns request_id_conflict.

Requests and results are encrypted at rest. The existing idempotency retention setting defaults to 24 hours, and cleanup uses the existing retention job. There can be at most 100 uncompleted, unexpired setup requests per key. After expiry, inspect current state before generating a new request ID. request_id for these tools is independent of the HTTP Idempotency-Key used by agent creation and messaging; an action-required response is not cached as a completed mutation.

get_integration_setup returns action_required, a stable reason code, an authenticated setup URL, workspace/agent context, and a follow-up inspection tool when credential entry, certificate import, or OAuth is needed. Complete authentication directly in the console, then inspect again. No MCP argument or result accepts or returns private keys, certificate material, passwords, OAuth tokens, or client secrets. OAuth completion is never simulated. Existing provider callbacks retain their normal agent wake-up behavior.

Reading a readiness result

Each check contains check, status, code, next_step, and details. Status is one of:

• ready: this particular stored-state or authorization check passes.
• blocked: a known configuration, lifecycle, assignment, grant, or limit prevents use.
• action_required: a human authentication, credential-renewal, or runtime approval step remains.
• unknown: the condition has not been tested or cannot be resolved without execution.

Overall status prioritizes blocked, action-required, then unknown. configuration_ready is false for known configuration blockers, null when a configuration check is untested, and true only when all applicable configuration checks pass. execution_tested is always false. Worker queue execution, DNS, endpoint reachability, TLS trust, and external provider authorization remain unknown. A parameterized operation path also leaves concrete destination authorization unknown until runtime substitution. This API takes no arbitrary probe URL and performs no network probe, infrastructure change, or migration.

OpenAPI OAuth credentials that execution can refresh return unknown with code credential_refresh_required when their expiry is within two minutes or absent. This includes authorization-code credentials with a refresh token and client-credentials flows. Preflight does not attempt refresh or verify provider acceptance. Authorization-code credentials without a refresh token return action_required once refresh is due; missing, revoked, and expired non-OAuth credentials also require action.

Installation operators must apply migration 0509_remote_mcp_mutations through the normal deployment process before using the new mutation tools. The MCP API does not apply migrations.

Timeline And Messaging

send_agent_message appends an authenticated MCP-originated message to the agent's unified timeline. The event uses channel mcp, source kind mcp, and the installation's product name followed by MCP as its source label; it does not impersonate the API key's user as the visible sender. The tool returns message_id, agent_id, cursor, latest_cursor, created_at, accepted_state, external actor metadata, and the serialized timeline event.

trigger_processing defaults to true. False stores the message with status and accepted_state set to stored; true returns queued to describe requested processing. Neither is proof of worker execution, and later policy or emergency admission can block it. Ordinary calls check the authenticated user's web-contact permissions even though the visible channel is MCP; staff cross-account calls use the target owner as described above. An inactive agent returns a tool error with agent_inactive details.

get_agent_timeline reads the unified timeline. Use after_cursor for events strictly newer than a cursor, or cursor plus direction (initial, older, newer) for scroll-style reads. after_cursor takes precedence if both cursor forms are supplied. The event with the exact after_cursor is excluded. Results include events, next_cursor, latest_cursor, oldest_cursor, newest_cursor, has_more, and processing state. Timeline reads default to 40 events and reject limits outside 1–100; REST instead clamps that limit. Empty windows can have null boundary cursors, so keep the last non-null cursor. Events can include messages, tool/step clusters, thinking entries, and plan updates when those exist in the agent timeline.

After an agent has received an MCP message within the configured web-session retention window, it can use send_mcp_message from any run. While processing an MCP request, the tool replies to that bound request; otherwise it appends to the newest qualifying MCP conversation. The outbound event uses channel mcp, and its inReplyToMessageId points to that inbound message so clients can correlate the response without treating the underlying web conversation as a human delivery channel.

wait_for_agent_event is the v1 wait primitive. It polls the same timeline for up to timeout_seconds with a server cap. Inputs include agent_id, after_cursor, event_types, and supported filters:

• from_actor_type: agent, human_user, external, or system, derived from the serialized event. Outbound or peer messages are agent; inbound web user messages are human_user; MCP and other inbound messages are external; steps/thinking/plan events are system.
• from_agent_id: supported for message events from an agent. For non-peer outbound messages this is the owner agent; for inbound peer-agent messages this is the peer agent.
• to_agent_id: supported for message events addressed to an agent. For non-peer inbound messages this is the owner agent; for outbound peer-agent messages this is the peer agent. Ordinary agent-to-human/external replies do not have a to_agent_id.
• message_id, peer_link_id, and channel: supported for message events. message_id does not override after_cursor; to wait for a known message, pass a cursor captured before that message or omit after_cursor and rely on the recent initial timeline window.
• status and tool_name: supported for tool/step events

The wait tool returns matched, timed_out, events, next_cursor, latest_cursor, and waited_seconds.

Debug Traces

get_agent_debug_trace pulls a bounded support/debug view for one agent that the API key can already access. It reuses the platform's audit timeline data and keeps the normal long-lived agent timeline model; it does not create a separate run, task, or conversation.

Inputs:

• agent_id is required.
• limit defaults to 20 and is capped at 50 per returned section.
• recent_minutes defaults to 60 when no cursor or explicit since is supplied. Set it to null to rely only on limit and cursor bounds.
• since and until accept ISO8601 timestamps. Time windows are capped at seven days.
• cursor accepts the previous response's audit.next_cursor for older audit/debug events.
• include can request any of timeline, audit_events, completions, eval_debug_artifacts, and diagnostics.
• detail can be summary, standard, or verbose. All levels still redact secrets and omit raw prompt archive payloads.
• eval_run_id can narrow eval debug artifacts to one eval run owned by the same agent.

Outputs include agent metadata, request scope, sanitized timeline/audit events, completion model/usage/cost metadata, prompt archive IDs and token-fit metadata, eval task debug artifacts when present, diagnostics, warnings, and redaction notes. Business and validation failures return normal MCP tool results with isError: true; they are not transport failures.

Sanitization is intentionally conservative. The tool recursively redacts sensitive key names and common credential patterns such as bearer tokens, API keys, private keys, cookies, and access tokens. It returns IDs, timestamps, tool names and status summaries, sanitized parameters/results, prompt archive metadata, usage/cost fields, and artifact links/IDs. It does not return full environment values, authorization headers, raw prompt archive payloads, or arbitrary unbounded transcripts.

Example:

{
  "name": "get_agent_debug_trace",
  "arguments": {
    "agent_id": "00000000-0000-0000-0000-000000000000",
    "limit": 20,
    "recent_minutes": 120,
    "include": ["audit_events", "completions", "diagnostics"],
    "detail": "standard"
  }
}

Agent Links

Agent links are symmetric peer-agent messaging links backed by the platform's AgentPeerLink model. link_agents creates or re-enables a link between two accessible agents that share an owner or organization. The link enforces a rolling message quota with messages_per_window and window_hours.

Linked-agent messages appear as peer direct-message events in each participating agent's unified timeline. The sender's timeline receives an outbound peer message and the recipient's timeline receives an inbound peer message. unlink_agents removes the link while preserving historical conversations and messages.

Files And Attachments

When a file already exists in the agent filespace:

1. Upload a small file with upload_agent_file, or create/upload the file in the agent filespace through the product.
2. Send a message with send_agent_message.
3. Pass filespace paths in attachment_file_paths, for example ["/uploads/brief.pdf"].

When a client already has the bytes, it can instead pass up to 10 items in the message call's attachments array. Each item contains path, content_base64, optional mime_type, and optional overwrite; the platform attempts to upload and attach them in one call. Pending malware scans can prevent immediate attachment; use the staged workflow below for protected uploads.

File and message results can return authenticated agent:// resource URIs. A pending_scan upload does not yet include a resource_uri. Use MCP resources/read for standard resource content, or read_agent_resource when a tool-centric client needs an image surfaced directly as MCP image content. Reads re-check API-key access, enforce the platform file-size limit, and verify stored checksums when available. Resource URIs are not public download links.

These flows use the platform's existing filespace and attachment models. Arbitrary URL fetching is intentionally not exposed through the MCP server. Uploads and reads enforce MAX_FILE_SIZE (10 MiB by default), so adding an oversized file through another surface does not bypass the MCP read limit. Use agent-side processing for larger files where the deployment supports it.

A protected upload can return status: "pending_scan", scan_status, and available: false. List the file to obtain its resource URI, then retry a bounded read after scanning; resource reads remain blocked until the file is clean. list_agent_files does not itself expose scan status. Once readable, send attachment_file_paths in a separate message. Do not blindly retry an inline message upload: scanning may have created the file even if attaching it failed. See File security.

Hermes Example

For Hermes, configure the platform as a Streamable HTTP MCP server in the profile's config.yaml. Store the API key in the profile environment and reference it by variable name; do not paste keys into shared config or docs. The field names and environment references below follow the Hermes MCP configuration reference. This example's tool allowlist selects the agent tools; add the documented control-tool names only when that client needs them.

mcp_servers:
  agent-platform:
    url: "https://your-deployment.example/api/v1/mcp/"
    headers:
      Authorization: "Bearer ${API_KEY}"
    timeout: 60
    connect_timeout: 10
    tools:
      include:
        - list_agents
        - get_agent
        - create_agent
        - update_agent
        - archive_agent
        - get_agent_config_options
        - list_agent_links
        - link_agents
        - unlink_agents
        - send_agent_message
        - get_agent_timeline
        - get_agent_debug_trace
        - wait_for_agent_event
        - read_agent_resource
        - list_agent_files
        - upload_agent_file

For production, use https://your-deployment.example/api/v1/mcp/. For preview deployments, create or request a fresh API key for the current preview database snapshot before testing; keys from older preview deployments may not exist in the new ephemeral database.

Smoke Test Flow

Use this flow for local dev, preview, or production smoke testing. Archive temporary agents at the end when safe.

1. list_agents
2. get_agent_config_options
3. create_agent twice without schedule
4. update_agent on one agent with a supported preferred_llm_tier
5. link_agents
6. send_agent_message
7. Capture the preceding message call's cursor, then read get_agent_timeline with after_cursor to include fast replies
8. get_agent_debug_trace; verify returned sections are bounded and sanitized
9. wait_for_agent_event with that message cursor and a short timeout; advance latest_cursor on each wait and verify match/timeout behavior
10. upload_agent_file
11. list_agent_files, then read its resource_link
12. Once the uploaded file is readable, send_agent_message with its attachment_file_paths
13. unlink_agents
14. archive_agent for temporary agents

Limitations

• The endpoint is stateless and does not issue Mcp-Session-Id values.
• Standalone GET SSE streams are not exposed in v1.
• MCP task augmentation and progress streams are not implemented. No future protocol feature or release date is promised here.
• Tool results include both MCP text content and structuredContent.
• All tool calls run with the permissions of the provided platform API key.
• Origin headers are validated for browser-originated requests to reduce DNS rebinding risk.
• Debug traces are sanitized support artifacts, not full audit exports. Use staff audit tooling for raw prompt archive inspection where policy allows it.

General admission limits

Deployments may enable shared request quotas, concurrent-wait capacity and queued-input backpressure. Accepted replays do not reserve new work capacity; ordinary HTTP quotas still apply. Honor Retry-After on 429/503 and keep the original protected-write key/body. Pending publication remains accepted input and is recovered independently of the caller. Enforced legacy task submission requires omission of wait; shared application/timeline waits remain bounded to 30 seconds. Validate throughput in your own environment.

REST setup companion

The reproducible REST setup workflow reuses workspace/native/OpenAPI services without private Console calls. Named schedules have deterministic REST CRUD and conditional revisions; the MCP natural-language agent schedule workflow remains unchanged. Member-only REST setup/binding controls do not extend service MCP authority. OAuth, secret/certificate entry and recent-authenticated control approval remain guarded browser steps.

Structured persistent-agent results are available only through the separately gated REST application request workflow. Remote MCP send inputs and meanings are unchanged; there is no advertised MCP result tool for clients. The internal runtime result tool is not a Remote MCP API.

HTTP responses expose generated X-Request-ID and valid caller X-Client-Correlation-ID through CORS. They correlate the synchronous call/logs independently of the JSON-RPC ID, tool setup request_id, client_reference and durable application identities. X-API-Contract does not replace MCP JSON-RPC errors or result.isError, change successful action-required results into failures, or introduce a universal retry guarantee. MCP/Console/runtime agent configuration edits advance the same agent revision used by conditional REST clients, while MCP update_agent retains its existing unconditional-write behavior.