Skip to main content
Glama

a2a2p — Agent-to-Agent-to-Physical

co_invent_begin_pass

Needs the signed-in link https://a2a2p.com/co-invent/mcp. On this public link it answers with how your person connects it. Run an invention pass: give the idea in one sentence and Co-Invent takes it from brainstorm to a finished invention package (and, for the owner, a marketplace listing). Returns a pass_id and the evidence Debbie received; follow it with co_invent_pass_status. While you research what to invent, gather evidence: papers, standards, filings and product pages, each with the one-line claim it supports (and, where it proves one, the brief fact: landscape, hard, buyer, price or incumbents), and pass up to 12 as evidence when you start; Debbie weighs it first. To invent something end to end, call co_invent_begin_pass with the idea in one sentence and your evidence. Then call co_invent_pass_status with the pass_id it gives you, wait_seconds 20, again and again. Each answer has next. When next.needsAgent is true, you decide, as the person would in the app: read what next shows (the questions, every brainstormed idea, the full shortlist, the must-dos, each round's verdict), then call co_invent_act with next.operation and a body you build (next.example shows the shape). When next.operation is set and needsAgent is false, send it as it is. When it is null, check again. Read any part with co_invent_read, and say anything to the team at any step with co_invent_pass_say. At the end, rate the package; the owner's passes publish with co_invent_publish. A full pass usually takes 30 to 60 minutes. options takes any newer setting by name: guidance "a2a2p" gives the writers a2a2p's engineering guidance for the idea's field before they write (off unless set); rerun_of (owner only) reruns an earlier pass to compare.

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": {
      "idea": "<idea>"
    },
    "name": "co_invent_begin_pass"
  }
}

Input Schema

NameRequiredDescriptionDefault
whoNoWho has the problem (optional).
whyNoWhy it matters, in the person's words (optional).
goalNosell (the default) or self.
ideaYesThe idea, or the problem it solves, in a sentence or two.
optionsNoAny newer setting by name.
evidenceNoThe evidence you gathered while researching what to invent: up to 12 items, each a public https link or a file, with the one-line claim it supports. Debbie weighs it first, and the certificate lists it as supplied by the inventor's agent.
pivot_ofNoWhen a finished pass missed the listing gate: its pass_id, to pivot once to a narrower sub-problem in the same field. A second miss drops the brief.
constraintsNoAnything it must or mustn't do (optional).
for_marketplaceNoOwner only: make it in the marketplace vault so it can be listed. On by default for the owner.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / evidence / items / description
      Previous value: -"One item: url or file ({name, type, base64}), with claim, and optionally quote, date and fact (landscape, hard, buyer, price or incumbents: the brief fact it proves)."New value: +"One item: url or file ({name, type, base64}), with claim, and optionally quote, date, fact (landscape, hard, buyer, price or incumbents: the brief fact it proves) and replaces (the item numbers it supersedes; the same link or file name replaces its earlier copy by itself)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / evidence / description
      Previous value: -"The evidence you gathered while researching what to invent: up to 8 items, each a public https link or a file, with the one-line claim it supports. Debbie weighs it first, and the certificate lists it as supplied by the inventor's agent."New value: +"The evidence you gathered while researching what to invent: up to 12 items, each a public https link or a file, with the one-line claim it supports. Debbie weighs it first, and the certificate lists it as supplied by the inventor's agent."
    • changedInput schema / properties / evidence / items / description
      Previous value: -"One item: url or file ({name, type, base64}), with claim, and optionally quote and date."New value: +"One item: url or file ({name, type, base64}), with claim, and optionally quote, date and fact (landscape, hard, buyer, price or incumbents: the brief fact it proves)."
  3. Added

TDQS

A3.6/5.0
Behavior4/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 substantial work: it discloses the auth requirement ('needs the signed-in link'), the 30-60 minute runtime, the side effect that owner passes publish with co_invent_publish, the 12-item evidence cap, and the consequence of pivot_of ('a second miss drops the brief'). The opening sentence about the public link is muddled enough to leave the connection/auth behavior partly ambiguous.

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?

It is poorly front-loaded: the first two sentences are about a link and a person's connection rather than the action. The core instruction is then restated ('To invent something end to end, call co_invent_begin_pass with the idea in one sentence and your evidence'), and the body drifts into a multi-tool workflow script (status polling, act, read, say, publish) that does not belong in this tool's definition.

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

Completeness4/5

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

For a 9-parameter, nested-object tool this covers the essentials an agent needs: prerequisites, expected duration, return handoff via pass_id, follow-up tools, and owner-only settings. An output schema exists, so return-value detail is optional, and the description still sketches what comes back. Only the confusion around the signed-in link keeps it short of full completeness.

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 100%, so the baseline is 3; the schema already documents who, why, goal, evidence item shape and the rest. The description adds real meaning for a few parameters — evidence is weighed by Debbie and attributed on the certificate, options 'a2a2p' turns on field-specific engineering guidance, rerun_of is owner-only — but says nothing beyond the schema for who, why, constraints, goal or for_marketplace.

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

Purpose4/5

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

The description states a specific verb and resource: 'Run an invention pass: give the idea in one sentence and Co-Invent takes it from brainstorm to a finished invention package.' That is concrete and an agent knows what it gets back (pass_id plus evidence). It never distinguishes itself from the near-identical sibling co_invent_start_pass (or co_invent_pass_step), so sibling differentiation is missing.

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

Usage Guidelines4/5

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

Usage is spelled out in detail: call this with the idea and evidence, then poll co_invent_pass_status with wait_seconds 20 repeatedly, branch on next.needsAgent to co_invent_act, and use co_invent_read / co_invent_pass_say / co_invent_publish at the right moments. What is missing is any exclusion or routing rule versus co_invent_start_pass, the obvious alternative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources