Local MCP interface

Configure a stdio MCP server with executable agentagon and arguments ["mcp"]. Agentagon uses the official Python SDK with a bounded major-version dependency. MCP connects to the same local service as the dashboard, starting it without a browser when necessary. It launches Agentagon-managed brain sessions; the calling agent does not execute the workflow.

Tools expose project and application-agent discovery, goals, workflows, issues, explicit trace import, task start/inspection/control, and memory groups/recall/record. list_workflows returns the built-in workflow names and requirements. import_trace accepts supported pasted/uploaded JSON or JSONL, or a provider connection and trace ID (or bounded selection).

inspect_issue returns the current issue revision, retained evidence, lifecycle facets, and user decision history. update_issue records one revision-bound triage decision: mark it not actionable with a reason, reopen it, assign it to an active application agent, or save reviewed expected behavior with a reason. If another client changes the issue first, inspect it again and decide against the new revision.

detect_agents performs bounded static detection and activates valid agent bindings in one operation. It accepts a project ID, UUID operation ID and optional already-retained snapshot IDs. Identical retries reuse the receipt; a fresh operation re-scans. Results include active agents, scan coverage and limitations. User edits and exclusions are preserved. Agent projections distinguish automatic adoption from user review, and manual, code and trace origins. Discovery dependency proposals remain advisory and never expand the approved edit scope. Use save_agent for explicit revision-bound identity edits.

inspect_evaluation_design includes attached_cases alongside the current draft. attach_evaluation_cases takes an immutable reviewed case's dataset snapshot ID, a UUID operation ID, the draft's expected_revision, and expected_cases_revision (use zero for an absent record). Repeating the same operation returns its original receipt. Native dataset cases are combined without changing existing rows. Frozen reuse becomes a new draft with the same scoring and required behaviors; all prior frozen inputs must remain in the new evaluator. The accepted version stays unchanged until an explicit accept action or a subsequent authorized Go run accepts the exact replacement revision. A goal with no design stores its cases without inventing scoring, and later design saves must retain every attached case. This operation does not run an evaluator.

save_goal accepts an optional UUID operation_id within its goal payload. Identical retries return the saved goal; reusing the operation for different content is rejected. This lets callers create a goal and attach a case without duplicating goals after a lost response.

start_goal_run is the goal's Go action. Supply project, agent, goal and UUID operation IDs, optional details, and optional profile/time/trial limits. The shared service creates one durable run that coordinates design, exact-version acceptance, evaluation, baseline and optimization. Compatible evidence is reused and accepted regression requirements remain protected. Routine execution defaults are resolved by Go. No publication, merge or deployment is authorized.

list_goal_runs and inspect_goal_run are read-only. The run exposes state, current work, the active task ID, requirements, total allowance and outcome reference. Answer a child question with control_task; the live coordinator then continues automatically. Use control_goal_run with pause, resume or cancel and a UUID for an explicit control action. Retries preserve identities. Restarted services retain interrupted runs for explicit continuation; changing settings while an active run exists is rejected rather than silently ignored.

start_workflow takes workflow, project_id, optional agent_id, typed input, optional scope, limits, options, and an operation_id. Inputs are {type: "goal"|"issue"|"trace", id: "..."}, {type: "description", text: "..."}, or {type: "agent"}. Limits bound trials, elapsed time and per-trial timeout. The response immediately includes task_id, state, and dashboard_url. Repeating the same operation ID and payload returns the same task; changing its payload is rejected.

inspect_task exposes the shared pending question, authoritative available_actions and recovery, and separate active, human waiting, queued, paused, offline and uncertain time. Only active time is reported as execution. An interrupted interval whose execution cannot be established reserves remaining allowance as unknown_seconds; it is not reported as active work. control_task accepts answer, pause, cancel, resume, or message with an operation ID and the current question ID/answer where required. Guidance is retained as a user message, marked delivered after the coding host acknowledges it, and automatically continues the same native session; a deliberate pause keeps it paused. Closing MCP leaves tasks running. Service interruption requires explicit resume, preserving existing execution and review identities, and the service rejects resume when no allowance remains.

Task active time excludes human waiting, including across concurrent coding sessions when every session is waiting. The runtime enforces the shared active allowance even if one session waits while another executes. Separately admitted evaluation, reflection and review operations retain their frozen wall-clock deadlines: waiting can still expire one of those operations while task allowance remains. Task recovery does not extend or replace these operation budgets; failed evidence remains subject to the workflow's existing recovery gates.

When recovery.continuation_allowed is true, continue_assessment takes a fresh operation ID and explicit max_elapsed_seconds (1–86400) to create a linked assessment with retained preparation and a new native session. The previous task and usage stay intact. Source and scope readiness are checked again; retrying the same operation returns the same continuation. This action is limited to stopped assessments with a retained original intent. Measured fix/optimization work uses its existing workflow recovery gates.

inspect_workflow_draft, save_workflow_draft, and clear_workflow_draft retain one private form per project and client key, without preparing or starting work. A new key reads {draft: null, revision: 0}. Save with that revision and an allowlisted draft containing workflow, operation ID/binding, and optional agent, goal, problem/expected behavior, trace snapshot reference and execution-profile fields. Missing form inputs are allowed. Changed content requires a fresh operation ID; stale updates or clears fail without replacing concurrent edits. Clear leaves a revisioned tombstone. The 16 KB limit and field allowlist exclude dedicated raw-trace and credential fields; they cannot protect secrets a user types into free text. Drafts are local application metadata, never uploaded automatically. These records reuse the existing database schema; they do not add database-version migration support.

recall_memory and record_memory enforce project/agent bindings. Inside an evaluation, recall uses its pinned snapshot and writes are rejected. See memory.

Assessment and production

clone_project and inspect_coding_backends reuse the dashboard setup operations. Provider setup uses the same two-step credential flow as the dashboard:

1. Call discover_connection with provider, its credential fields and an optional endpoint. The result contains an expiring discovery_id and provider projects with opaque selection_id values.
2. Call save_connection with that discovery_id and the chosen project_selection_id.

The local service owns temporary and durable credential references; connection results do not expose credential values. Discovery does not save a connection, import traces or enable monitoring. test_connection refreshes a saved connection's readiness, and disconnect_connection removes the connection and its stored credential references. list_connections is read-only.

configure_onboarding saves assessment scope; inspect_onboarding resumes setup. Start assess with {type: "project", id: PROJECT_ID}. Use the assess workflow for deeper analysis, or detect_agents for immediate local detection without a model. list_recommendations returns retained issue actions and regressions established by accepted production comparisons. Possible faster, more reliable and lower-cost objectives are returned separately in action_templates; they are not evidence that improvement is needed.

save_monitor creates or updates an explicit agent/environment policy with accepted measurements and bounds. Updates require the current revision. control_monitor accepts pause, enable, or discard. Start observe with {type: "monitor", id: MONITOR_ID} for Analyze now. It uses the saved policy; callers cannot supply scheduler-owned windows or widen selectors.

inspect_production returns improvements, deployments, monitors, immutable observation references and attention items. record_deployment takes an operation ID, selected improvement ID, release, environment, actual revision and deployment time. This declares deployment without performing one. See production monitoring for criteria and local service limits.