Limitations

What the Catio MCP cannot do, and the asynchronous behaviour to expect.

The Catio MCP can read your architecture, search your workspace context, ask Archie, and create and update blueprints. See Tools for the full list. The limits below are what it cannot do.

Reads and writes

  • No deletion: blueprints can be created and updated through the MCP, but not deleted. Delete from the Catio console.
  • Inventory and context are read-only: the architecture inventory and workspace context can be searched and read, but not written. Inventory is populated by Integrations, and context is managed in the Context module.
  • AI edits are not persisted automatically: edit_blueprint_with_archie returns a draft. Review it, then call update_blueprint to save it.

Queries

  • No direct infrastructure queries: SQL and direct CatioPipe queries are not available through the MCP.
  • No detailed billing data: cost breakdowns are not exposed as a dedicated tool. Archie has some cost awareness and can be asked directly.

Session and workspace

  • No workspace switching: the workspace is fixed at login time. Re-authenticate to switch, or add Catio as a separate named server for each workspace.

Documents and payloads

  • Request bodies are capped at 1 MiB: file bytes are not sent through the MCP. Upload a document with create_upload_url, PUT the bytes to the presigned URL it returns, then call confirm_upload.
  • Three document types: PDF, plain text, and Markdown.

Asynchronous operations

Neither of these returns a result directly, so a client that expects a synchronous response will appear to hang.

  • Archie is asynchronous: ask_archie returns a processing token. Poll get_archie_response every one to two seconds until the conversation completes or fails.
  • Blueprint generation is asynchronous: generate_blueprint_list and accept_blueprint_outline return a batch id. Poll get_recommendation_list_status until it reports COMPLETED or FAILED.

Did this page help you?