a2a2p — Agent-to-Agent-to-Physical

co_invent_act

Needs the signed-in link https://a2a2p.com/co-invent/mcp. On this public link it answers with how your person connects it. Take a step of an invention pass: next.operation with next.body, or a body you build where next.needsAgent is true. operation is one of: answer, ideas, develop, reject, steer, add, react, brainstorm, build, mustdos, purpose, model, pass, roundsteer, finalise, claims, recheck, rate, decide, revise, evidence, retry, cancel, sibling, saveidea. Any step may carry evidence (links or files, each with its claim) before the shortlist. roundsteer takes body {"words": "…"}: what the next sharpening rounds should weigh; requirement ids it names (e.g. DET-3) get the next rounds, in order. purpose takes body {"must_hold_id": "PUR-2", "mark": "strike" | "confirm" | "restore"} for a must-hold the rounds can't keep. A step may carry body.request_id (or an Idempotency-Key header), so a resend after a timeout returns the same step. retry starts a stopped step again, with the body it was sent; cancel stops the pass.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pass_id": "<pass_id>",
      "operation": "<operation>"
    },
    "name": "co_invent_act"
  }
}

Input Schema

Name	Required	Description
`body`	No
`pass_id`	Yes
`operation`	Yes	The step: next.operation, or one of the steps listed above.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

C2.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does deliver real behavior: it requires the signed-in link, supports idempotency via body.request_id or an Idempotency-Key header, retry re-sends a stopped step's body, and cancel halts the pass. But 21 of the 24 operations are bare names with no disclosed effect, side effects, or preconditions, which is a serious gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening two sentences about the signed-in link and "how your person connects it" are confusing preamble that delays the actual purpose. The rest is a dense run-on packing a 24-item enumeration and several special-case rules into prose, with no front-loaded summary or structure to help an agent scan it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 24 operations, a free-form nested `body`, no annotations, and only an output schema to lean on, the description leaves most operations undefined (what does `mustdos`, `claims`, `react`, or `finalise` do?). Auth and idempotency are covered, but an agent still cannot safely pick an operation or construct its body for most of the surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% and the schema's own description of `operation` is circular ("the step... one of the steps listed above"), while `body` is an untyped open object. The description compensates meaningfully for three operations (roundsteer's {"words"}, purpose's must_hold_id/mark enum, evidence with claim) plus request_id, but the remaining operation names still give no parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Take a step of an invention pass" names a resource (invention pass) but the verb is vague, and the long operation enumeration is the only thing that reveals the real scope. It never distinguishes itself from close siblings like co_invent_pass_step, co_invent_pass_say, or co_invent_start_pass, so an agent cannot tell which entry point to pick from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase "next.operation with next.body" implies the intended flow: read the pass state, then execute the suggested next step, which is genuinely useful routing guidance. However, there are no explicit when-not conditions, no statement of how this differs from the sibling pass tools, and no guidance on choosing among the 24 operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All a2a2p — Agent-to-Agent-to-Physical tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.