Continua, inside your own AI client

Connect

The Continua MCP Server speaks Streamable HTTP. Point any MCP-compatible client at the server URL:

https://app.askcontinua.com/mcp

Sign in with OAuth

The easiest way to connect is OAuth. Add the server URL to your client — Claude, ChatGPT, Cursor, and other OAuth-capable MCP clients detect it and open a browser window. Sign in with Google or your email to authorize the connection. No token handling is needed: your client stores the credentials and keeps the session current automatically.

Authenticate with an API key

For clients without OAuth support, scripts, and CI, use a Continua AI API token — the same Bearer token you use for the REST API. Create one in your account settings and send it on every request:

Authorization: Bearer YOUR_CONTINUA_AI_API_TOKEN

Both methods grant the same access and run under your account. If a client supports OAuth, prefer it — an API key works anywhere but never expires on its own, so rotate it if it is ever exposed.

The endpoint is stateless, accepts POST, and returns JSON responses; GET and DELETE return HTTP 405. Clients should send Accept: application/json, text/event-stream and Content-Type: application/json, and perform the standard MCP initialization.

Tools

Start here. Call learn_how_to_use with {} before your first task to get the usage skill as Markdown text: Agent mode workflows, complete response examples, and how to reuse project prompts, rules, policies, knowledge, and memory; review past results, rationale, and user feedback; and set up scheduled tasks. This read-only tool does not create a response or consume analysis credits.

responses_create takes the public Responses API JSON in body, plus an optional idempotency_key. Responses run in the background; poll responses_get about every five seconds until terminal. Project tool parameters use the public API's snake_case names, including project_id, team_id, file_id, reader_scope, and access.allowed_user_ids.

files_upload takes { "filename": "input.pdf", "data": "<base64>" } and returns a file ID for an input_file item. project_files_upload takes { "project_id": "...", "files": [{ "filename": "input.pdf", "data": "<base64>" }] }. For text content, including Markdown, JSON, or CSV, call project_files_upload_text with project_id, filename, and text; optional meta contains title and ref_date. It returns a ready file immediately. All three upload tools accept an optional source_response_id identifying the response that produced the file; omit it when unknown. Uploading the same filename replaces the existing file once the new file is ready. Base64 must use the standard alphabet and padding, without a data URL prefix. MCP request bodies are limited to 32 MB including base64 and JSON overhead; use the multipart upload endpoints of the REST API for larger files. File type, upload size, access, and compilation rules are the same as in the REST API.

Tool failures set isError: true and return the public API error's message, type, param, and code, plus the HTTP-equivalent status and an optional retry_after. Invalid or disabled API keys fail HTTP authentication before any MCP tools run.

How a task runs

If this is your first task, call learn_how_to_use with {} first — it returns the usage skill that covers this workflow in full, at no credit cost.

Define the business question, audience, decision to support, scope, time period, constraints, and acceptance criteria. Include the actual source materials and state which sources or approved rules take precedence.

• Call account_get and billing_get when identity, active teams, or available credits affect the task. A zero balance may still have free_tasks_left; follow the service's eligibility checks instead of treating balance alone as approval or denial. A paid response may consume credits.
• For one-off documents, call files_upload with filename and standard base64 data. Use the returned ID in an input_file item. Staged file IDs expire after 24 hours and are claimed by a response; use projects for repeated use of the same sources.
• For existing knowledge, call projects_get or project_files_list to obtain file IDs; projects_list omits files. Use project_files_compiled_get to inspect definitions, current policies, and previous decisions before choosing relevant project IDs.
• A new response needs at least one input_file, at least one report.project_ids entry, a completed previous_response_id, or an enabled tool such as web search or a plugin. For a task without any of these sources, upload a brief.md containing the brief and explicit assumptions.

Call responses_create with the public API request in body. Put the task in body.input, evidence extraction requirements in report.findings_criteria, and the deliverable specification in report.composition_criteria.

{
  "idempotency_key": "supplier-review-2026-10-v1",
  "body": {
    "model": "deepseek-flash",
    "background": true,
    "input": [{
      "role": "user",
      "content": [
        { "type": "input_text", "text": "Recommend a supplier for next quarter using the attached proposals. Compare total cost, implementation time, service quality, and operational risk. Budget ceiling: 200000 USD. Separate verified facts, assumptions, and unknowns." },
        { "type": "input_file", "file_id": "<uploaded_file_id>" }
      ]
    }],
    "report": {
      "findings_criteria": "Extract comparable pricing, quantities, units, contract terms, delivery dates, and evidence of service quality. Preserve source references and quotes. Identify contradictions and missing evidence.",
      "composition_criteria": "Produce a decision memo with executive recommendation, evidence-backed comparison, cost calculation, alternatives, sensitivity analysis, risks, and an action plan with owners and review dates. Include a comparison table and cite supporting findings. Do not invent missing values."
    }
  }
}

Supply exactly one user message with exactly one input_text item and any input_file items. With project sources, input can instead be a plain task string and report.project_ids an array of accessible project IDs. Every referenced project must contain at least one ready compiled file.

Reuse the same idempotency_key for retries of the same creation request; use a new key for a changed request or a new task. Save the returned response ID and call responses_get about every five seconds while status is queued or in_progress. Stop polling at completed, failed, or cancelled.

responses_get returns the saved task question in report.user_question and the submitted criteria in report.findings_criteria and report.composition_criteria for every status, so a client can reconstruct what a task asked before reading its results. Completed responses also include results and report.files, including findings.json. Retrieve findings through response_files_get. created_at is an ISO 8601 UTC string, for example 2026-10-18T08:30:00.000Z.

responses_list recovers prior response IDs using project and status filters and its pagination cursor. Continue with next_cursor until it is null, even if a page is empty. Each entry includes previous_response_id (null for root tasks), report.user_question, and report.project_ids to identify the task, its source projects, and its place in a task chain. created_at and last_updated_at are ISO 8601 UTC strings, for example 2026-10-18T08:30:00.000Z. Project created_at and last_updated_at, and project file created_at, use the same format. Only projects_get includes files in the project object.

On completion, inspect output_text, report.files, and the billed amount in report.billing when present. Retrieve findings.json through response_files_get to read findings with source references and quotes where available; check whether the evidence actually supports the claim. Call response_files_get with response_id and an exact name from report.files — it returns either a temporary download_url or content in body with its format and contentType.

Investigations it can run

The Responses API performs the business investigation: it connects evidence across the submitted document set, reconciles claims, traces changes, identifies conflicts and missing support, and produces findings with source references. The MCP client supplies the record and business question, delegates that analysis to responses_create, and retrieves the resulting investigation.

Commercial finance underwriting

Reconcile the requested financing with its supporting record; connect concentrations and cash-flow discrepancies with contractual exposures; identify unsupported representations and missing documents. Deliverable: an underwriting evidence memo, discrepancy and exposure tables, and a prioritized list of information still needed. Use case: finance underwriting

Credit renewal and covenant review

Reconstruct current covenant definitions and thresholds, check reported compliance against the governing documents, and identify changes since the previous review. Deliverable: a renewal review, covenant comparison matrix, financial inconsistencies, and open questions with source locations. Use case: credit review

Transaction and data-room due diligence

Verify the deal narrative against underlying records, identify unsupported earnings adjustments, and connect contract restrictions or inconsistent disclosures to transaction risks. Deliverable: a cited diligence report, risk register, missing-support list, and questions for management or the counterparty. Use case: due diligence

Contract review and currently effective obligations

Follow how terms change across the agreement family; reconcile inconsistent definitions, deadlines, exceptions, cross-references, and obligations assigned to different entities. Deliverable: an effective-terms table, amendment history, conflict register, and unresolved interpretation questions. Use case: contract review

RFP analysis and proposal compliance

Assemble current mandatory requirements, reconcile changed instructions, and compare the draft with submission and eligibility rules. Deliverable: a compliance matrix containing requirement, source, mandatory status, owner, deadline, and response gap; plus a prioritized correction list. Use case: RFP analysis

Operational root-cause and failure investigation

Reconstruct the event sequence, evaluate causal explanations and contributing factors, and distinguish documentary support, correlation, and inference while retaining contradictory evidence. Deliverable: a cited timeline, cause-and-evidence assessment, alternative explanations, evidence gaps, and targeted corrective-action proposals. Solution: root-cause analysis

For an investigation follow-up, set body.previous_response_id to your own completed response ID, provide the additional question or evidence, and use a new idempotency key. An in-progress response cannot be used as the parent.

Web search

To search current public information, add { "type": "web_search" } to responses_create.body.tools. Web search is off by default and can be the only source; no placeholder upload is needed.

{
  "body": {
    "model": "deepseek-flash",
    "input": "Research recent public customer feedback. Cite sources and identify disagreements.",
    "tools": [{ "type": "web_search" }]
  }
}

Use at most one web search entry. The legacy type web_search_preview is also accepted. Search options such as domain filters, location, and context size are unsupported. tool_choice supports auto (default) or none; none disables tools. Forced tool choices are unsupported.

Tools apply to each request. Include the web_search entry again in a follow-up when search is needed. To combine search with a connected plugin, include both tool entries in the same tools array; see Plugins below for plugin selection.

Plugins

Discover and connect plugins

Call plugins_list to find the authenticated user's connected plugins, IDs, permission settings, and auth_expired flags. Plugin objects do not expose connection URLs or credentials.

To add a connection, call plugins_create with name, HTTPS url, access (read or write), and write (auto, always, or approval). The connection URL is configured here; responses_create refers to the saved connection by plugin_id.

Use plugins_update with plugin_id and the fields to change for an existing connection. Use plugins_delete with plugin_id to remove a connection. Leaving a plugin out of a response's tools array only disables it for that response.

For Agent mode, connect the Continua Agent plugin with this server's URL (https://app.askcontinua.com/mcp). This connection uses your current account; no additional API token or OAuth step is needed. Select its returned plugin_id in the response's tools array to run tasks with project context, review past results and feedback, save reviewed knowledge to projects, or set up scheduled tasks. See Agent mode below for the workflows.

Configure permissions

Read access and write mode through plugins_list and update them through plugins_update. Read access stores write as auto. These saved settings apply when the plugin is selected for a response; tool entries do not override them. Per-request MCP options such as allowed_tools, authorization, headers, and require_approval are unsupported.

Complete OAuth and reconnect

If plugins_create or plugins_update returns authorization_url, present that URL to the user to open in a browser signed in to Continua AI as the same account. OAuth must finish before the connection is saved; pending authorization expires after 10 minutes. Call plugins_list after completion to obtain the connected ID and check auth_expired. Do not treat a pending URL as a connected plugin or repeatedly create another connection while waiting for authorization.

To reconnect an expired plugin, call plugins_update with plugin_id and reconnect set to true; the previously configured server address is used. Supply url only when configuring a different server.

Enable plugins for a response

Plugins are off by default, including connections already saved on the account. Select a plugin by adding { "type": "mcp", "plugin_id": "<returned ID>" } to responses_create.body.tools. Use at most 20 unique plugin IDs owned by the authenticated user. Reference plugins by ID only; never send server_url or server_label in responses_create.

{
  "body": {
    "model": "deepseek-flash",
    "input": "Review the recent customer feedback in our internal notes and summarize the main issues.",
    "tools": [{ "type": "mcp", "plugin_id": "<ID from plugins_list>" }]
  }
}

A plugin can be the only source or be combined with files, projects, and web search. Include the relevant plugin entries again in each follow-up that needs them. Omitting tools defaults to no tools.

Approve actions through a follow-up

For approval-mode actions, inspect the completed response's proposed action and obtain the user's approval. Send that approval as the input of a new responses_create with previous_response_id pointing to the completed proposal response and the relevant plugin entries included again:

{
  "body": {
    "model": "deepseek-flash",
    "previous_response_id": "<completed proposal response ID>",
    "input": "I approve the proposed update to the customer notes. Proceed with that update.",
    "tools": [{ "type": "mcp", "plugin_id": "<ID from plugins_list>" }]
  }
}

The parent context passes the proposal and approval to the follow-up, using the current stored plugin permissions. This workflow uses normal follow-up input, not structured mcp_approval_response items. Do not change the plugin's write mode to bypass the follow-up approval flow.

Scheduled tasks

Run a saved response on a recurring schedule, such as a weekday morning briefing. Scheduled-task tools follow the same Project permissions as the REST API.

Unlike responses_create, scheduled_tasks_create takes response directly instead of body:

{
  "project_id": "P-example",
  "name": "Daily update",
  "response": {
    "model": "deepseek-flash",
    "input": "Summarize today's relevant developments.",
    "tools": [{ "type": "web_search" }]
  },
  "schedule": { "cron": "0 9 * * 1-5", "timezone": "UTC" }
}

1. Call projects_list to choose a Project, then scheduled_tasks_create.
2. Use scheduled_tasks_update or scheduled_tasks_cancel with task_id to pause, resume, or cancel.
3. After a run, call scheduled_tasks_runs_list(task_id) to get a response_id, then responses_get for the result. A schedule ID is not a response ID.

Schedules use a five-field cron expression and an IANA timezone (default UTC). Each schedule must draw on Project files, web search, or MCP plugins; temporary uploaded files are not supported. Each run uses credits like a normal response, and a schedule pauses automatically if it repeatedly can't run for lack of credits or an expired team plan.

Deliverables

Describe the artifact explicitly in input and composition_criteria: intended audience, format and filename, required sections or schema, source references, and acceptance checks. Office and HTML files are requested as generated artifacts, then retrieved from the actual report.files list.

Verify the files actually produced, then check content, numbers, layout, formulas, schema, or browser behavior as appropriate to the deliverable. If an artifact is missing or incorrect, request a focused revision from the completed response rather than renaming text to an Office extension. Requesting format=docx, pptx, or xlsx does not convert arbitrary content into an Office file — ask for the artifact itself in the task. Generating an HTML file creates a downloadable artifact; publishing or hosting it is a separate action.

Projects as reusable knowledge

Create a personal project with projects_create(name). For a team project, use an active team ID from account_get or billing_get as team_id. Inspect existing projects first so related work can reuse an appropriate knowledge base.

Store durable, reviewed files rather than relying on chat history or a previous response to become project knowledge automatically. A useful document structure:

• Knowledge: glossary, business context, metric definitions, primary sources, customer/market facts, and source freshness dates.
• Decisions: question, decision date, owner, options considered, evidence, assumptions, chosen option, rationale, expected outcome, and review triggers.
• Rules: scope, owner, version, effective date, status (draft/approved/superseded), required conditions, exceptions, precedence, examples, and review date.
• Reusable work patterns: approved report outlines, Office templates, extraction schemas, comparison criteria, and examples of an acceptable result.

Use descriptive versioned filenames such as pricing-rules-v2.md and supplier-decision-2026-10.md. For text content, including Markdown, JSON, or CSV, call project_files_upload_text with project_id, filename, and text; optional meta contains title and ref_date, and the file is ready immediately. For PDF, Office, and other files requiring conversion, use project_files_upload with project_id and a files array of filename/base64 data pairs. Upload starts compilation. Inspect compile_error and poll project_files_list or project_files_get until the required files are ready. Retry failed compilation with project_files_retry; do not repeat uploads to check status. Use project_files_compiled_get to confirm what the analysis will read.

To preserve a result, inspect the relevant response artifact or prepare a reviewed Markdown summary, then upload it with project_files_upload_text — results are not saved to projects automatically. Include source references so the saved file can be understood on its own. Document the source response ID, evidence references, approval status, version, and review date in the file. Keep proposed decisions and draft rules clearly separate from approved ones, preserve prior versions, and mark supersession explicitly instead of deleting old files as routine cleanup.

Agent mode

The Continua Agent plugin, also called Agent mode, runs complex workflows using your account's accessible projects and connected tools. Call learn_how_to_use with {} before starting to load the full usage guidance.

Run tasks, reuse feedback, and schedule recurring work

1. Project context → analysis task: read prompts, rules, policies, knowledge, and memory stored as project files with project_files_list and project_files_compiled_get, apply them when constructing responses_create.body.input, and attach the source projects through report.project_ids. Use a new idempotency_key per task and poll responses_get until completion.
2. Past tasks and feedback → reviewed project knowledge: use responses_list with project_id and responses_get to review prior tasks. Read report.user_question, report.findings_criteria, and report.composition_criteria to understand the question and requirements. Follow previous_response_id to review the task chain and user feedback in follow-up questions. For completed tasks, inspect output_text, the rationale in the output message text, and relevant output files. Retrieve findings.json through response_files_get to review the evidence. Distill what should be reused into reviewed knowledge or memory, then upload a versioned Markdown file with project_files_upload_text. Follow the provenance guidance in Projects as reusable knowledge before reusing it.
3. Recurring workflows → scheduled tasks: use scheduled_tasks_create to run analyses with project context, plugins, or web search. Include the Continua Agent plugin ID in response.tools when a scheduled run needs Agent mode. Use scheduled_tasks_runs_list to retrieve each run's response ID, then responses_get to check completion and read results. See Scheduled tasks above for scheduling and run history.

Read one file as AI-friendly content

Use project_files_list to find a file, then call project_files_compiled_get with project_id and file_id. It returns the file's compiled content in a markdown field, suitable for the calling AI to read directly when applying a specific policy, definition, decision record, or template.

When the analysis spans many files, pass the project IDs in responses_create.body.report.project_ids and describe the investigation in input. The API includes all ready compiled files in the referenced projects as sources for the investigation, enabling cross-file reconciliation of knowledge, rules, and prior decisions. Multiple project IDs can be analyzed together.

{
  "idempotency_key": "supplier-renewal-v2",
  "body": {
    "model": "deepseek-flash",
    "input": "Evaluate the supplier renewal using the project's approved procurement rules, metric definitions, and previous supplier decision. Identify changes since that decision, rule exceptions, evidence gaps, and conditions that would change the recommendation. Produce a decision memo and a versioned draft decision-record.md for review.",
    "report": {
      "project_ids": ["<project_id>"],
      "findings_criteria": "Extract applicable approved rules, prior decision assumptions, source dates, and evidence relevant to renewal. Identify superseded rules and contradictory evidence.",
      "composition_criteria": "Give a recommendation, rule compliance table, comparison with the previous decision, scenario analysis, source references, and action owners. Label proposed changes as drafts."
    }
  }
}

Review the new result, then add reviewed knowledge or a versioned decision record back to the project. Update rules only when their approval and scope are clear. This closes the cycle: sources → analysis → decision → reviewed project knowledge → subsequent analysis.