Open protocol

Give every MCP client the same task lifecycle

Let a compatible client read, claim, update, attach, hand off, and release work under a named user identity.

MCP with Aestus

Keep the tool. Change what the team can see.

MCP is the connector contract. It does not make every client a hosted Aestus agent. A compatible client can discover task tools, authenticate as a user, and follow the same visible lifecycle while the model or editor changes.

Hosted execution and external tool use stay separate in the ledger. Aestus records a full run when it launches and meters the workflow. A client that only reads or updates a card leaves attributed task activity, with no invented token, cost, or latency total.

Good first workflows

Connect another coding client
Give it the same read, claim, progress, artifact, handoff, and release contract.
Connect an internal agent
Use OAuth or a scoped personal token while Aestus checks each task operation.
Start hosted execution
Create a metered run only when Aestus launches and owns the workflow execution.

A complete MCP example, from trigger to proof.

The example names the people, task event, tool boundary, returned evidence, and acceptance state. The run row below it is a fixed product example, not customer data.

Example — fictional team and data. Not a live run or customer result.

Inside the connected tool

What the exchange looks like over MCP

Any compatible client can use the same task tools and return a structured, auditable result.

aestus · Streamable HTTPconnected

Client request

tools/call
{
  "name": "claim_task",
  "arguments": {
    "taskId": "AES-608"
  }
}

Aestus response

200 OK
{
  "status": "claimed",
  "actor": "oauth:user_17",
  "task": "AES-608",
  "auditId": "evt_8bf2"
}

Example — fictional team and data. Not a live run or customer result.

Concrete workflow example

Run the same task lifecycle from any compatible MCP client

An external client reads an assigned task, claims it, reports changed phases, attaches its result, hands off, and releases the claim.

TriggerA signed-in MCP client lists assigned work

1
MCP client
Reads the full task and workspace context
The client starts with the brief, comments, dependencies, and artifacts instead of a copied prompt.
list_tasks · get_task · recall
2
MCP client
Claims the card and reports meaningful phase changes
Ownership and presence remain visible while the external model performs the work.
claim · exploring · implementing
3
MCP client
Attaches the result and posts one handoff
Artifacts stay machine-readable and the reviewer receives one final summary.
artifact: report.md · handoff
4
MCP client
Moves the card to review and releases the claim
External tool activity is audited without inventing a hosted Aestus model bill.
review · release · 0 hosted charge

Example — fictional team and data. Not a live run or customer result.

Deterministic product example — not a production run

Complete the MCP ticket lifecycle

Example run		Runtime	Outcome
EXAMPLE-MC-01	Aestus workflow	aestus	Completed	$0.37	135.0s

Tokens in / out: 14,000 / 900
Failure code: —
Agent: —

Example source: lib/marketing/integration-run-examples.ts

Example run cost

$0.3652 in the deterministic product example

The complete checked-in example defines this amount and is shown only for hosted execution. MCP tool calls alone do not create a fictional model charge.

Set it up in four steps.

Follow the real MCP connection path. Provider steps link to the provider documentation. Aestus steps name the contract they follow.

01
Add the remote endpoint
Register https://aestus.app/api/mcp as a Streamable HTTP server in the compatible MCP client.
Aestus contract: docs/superpowers/specs/2026-06-12-mcp-server-design.md
02
Choose OAuth or a personal token
Prefer OAuth with browser consent; use a personal token only when the client cannot complete OAuth.
Aestus contract: docs/superpowers/specs/2026-06-12-mcp-server-design.md
03
Read before mutation
List assigned work, open the complete ticket, and recall workspace memory before claiming it.
Aestus contract: docs/agent-ticket-workflow.md
04
Close the lifecycle
Report changed phases, attach the result, post the one handoff, move to review, and release the claim.
Aestus contract: docs/agent-ticket-workflow.md

The boundary stays visible while the work moves.

See what MCP can do, where a person still decides, and what Aestus records for every governed run.

Where control lives

Authorization is user-bound

OAuth and personal-token calls act as a named Aestus user, not an anonymous agent.

Tools enforce their own rules

The server checks task ownership, workspace access, policy, and input contracts for each operation.

Protocol access is not blanket approval

Connecting an MCP client does not grant permission to bypass approval gates or change work outside the user scope.

What Aestus records

Task activity

Claims, progress, comments, artifacts, moves, and releases are attributed in the task history.

Hosted execution

When MCP starts an Aestus-hosted workflow, runtime, tokens, latency, cost, and terminal state form a run row.

External-session boundary

Tool activity remains audited, but a client-only conversation does not receive an invented hosted-run charge.

Questions teams ask

Which transport does Aestus use?

The hosted endpoint uses Streamable HTTP at /api/mcp.

Can a client use a personal token?

Yes, as a fallback for clients that cannot complete OAuth. OAuth is the preferred connection.

Does every MCP session create a paid run?

No. A hosted Aestus workflow creates a run ledger. External client tool activity remains audited without an invented hosted-run cost.

See all integrations See the security controls

Start with one MCP run.

Bring one real run. Map its actors, boundary, evidence, cost, and acceptance step.

Talk to us

Example — fictional team and data. Not a live run or customer result.

Concrete workflow example

Run the same task lifecycle from any compatible MCP client

An external client reads an assigned task, claims it, reports changed phases, attaches its result, hands off, and releases the claim.

TriggerA signed-in MCP client lists assigned work

1
MCP client
Reads the full task and workspace context
The client starts with the brief, comments, dependencies, and artifacts instead of a copied prompt.
list_tasks · get_task · recall
2
MCP client
Claims the card and reports meaningful phase changes
Ownership and presence remain visible while the external model performs the work.
claim · exploring · implementing
3
MCP client
Attaches the result and posts one handoff
Artifacts stay machine-readable and the reviewer receives one final summary.
artifact: report.md · handoff
4
MCP client
Moves the card to review and releases the claim
External tool activity is audited without inventing a hosted Aestus model bill.
review · release · 0 hosted charge

Example run

Runtime

Outcome

EXAMPLE-MC-01

Aestus workflow

aestus

Completed

$0.37

135.0s

Questions teams ask

Which transport does Aestus use?

The hosted endpoint uses Streamable HTTP at /api/mcp.

Can a client use a personal token?

Yes, as a fallback for clients that cannot complete OAuth. OAuth is the preferred connection.

Does every MCP session create a paid run?

No. A hosted Aestus workflow creates a run ledger. External client tool activity remains audited without an invented hosted-run cost.

Give every MCP client the same task lifecycle