a2a2p — Agent-to-Agent-to-Physical

co_invent_publish_pass

Needs the signed-in link https://a2a2p.com/co-invent/mcp. On this public link it answers with how your person connects it. Older name for co_invent_publish, kept so a connector with a saved tool list keeps working. Owner only: list a finished, rated marketplace pass in the Co-Invent marketplace as a preview (shown, not yet for sale). It lists only a package at commercial potential 80 or more with real evidence, cited prior-art separation and a named buyer and price; below that it says why and offers one pivot to a narrower sub-problem (co_invent_start_pass with pivot_of), and a second miss drops the brief.

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>"
    },
    "name": "co_invent_publish_pass"
  }
}

Input Schema

Name	Required	Description
`tags`	No
`teaser`	No	What it does, one line (optional; taken from the package).
`pass_id`	Yes
`sub_code`	No	The NAICS subsector code, e.g. 335 (optional; defaults to the classification proposed at finalise).
`use_case`	No	One of the use cases listed for its subsector, or "Other (Debbie reviews)" (optional; defaults to the classification proposed at finalise).
`price_usd`	No	The listing's price in US dollars, set by the owner (optional; publish again to change it). It shows once sales open.
`innovative`	No	What's new about it, one line (optional; taken from the package).
`technologies`	No
`industry_code`	No	NAICS sector code, e.g. 31-33 (optional).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026

addedInput schema / properties / sub_code

Added value: +{
+  "description": "The NAICS subsector code, e.g. 335 (optional; defaults to the classification proposed at finalise).",
+  "type": "string"
+}

addedInput schema / properties / use_case / description

Added value: +"One of the use cases listed for its subsector, or \"Other (Debbie reviews)\" (optional; defaults to the classification proposed at finalise)."

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / price_usd

Added value: +{
+  "description": "The listing's price in US dollars, set by the owner (optional; publish again to change it). It shows once sales open.",
+  "minimum": 1,
+  "type": "number"
+}

AddedNov 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden well: it discloses the owner-only authorization constraint, that the result is a preview rather than a live sale, the numeric qualification threshold, and the escalating failure path (explains why, offers one pivot, then drops the brief on a second miss). The opening two sentences about the signed-in link and 'how your person connects it' are muddled and do not clarify runtime behavior, which keeps this below a 5.

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

Conciseness3/5

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

The actual purpose is buried behind two preamble sentences about the signed-in link that an agent cannot act on. The remaining content is dense but earns its place; reordering to lead with 'Owner only: list a finished, rated pass as a preview' would fix the front-loading problem.

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 nine-parameter, no-annotation mutation with an output schema, the description covers the essentials: authorization, precondition state (finished and rated), threshold gate, and failure consequences. It does not need to explain return values because an output schema exists, and only minor gaps remain around what happens to an already-listed pass.

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 description coverage is 67%, so most parameters already carry their own meaning (price_usd, sub_code, use_case, teaser, innovative). The description only indirectly touches parameters via the buyer/price gate and adds no syntax, defaults, or precedence detail beyond the schema, so baseline 3 is right.

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

Purpose5/5

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

States a specific verb and resource: it lists a finished, rated marketplace pass in the Co-Invent marketplace as a preview (shown, not yet for sale). It also explicitly positions itself against the sibling co_invent_publish by declaring itself the older name kept for stale connector tool lists, so an agent can pick correctly without inspecting schemas.

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

Usage Guidelines5/5

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

Gives the caller condition up front ('Owner only'), the qualification gate (commercial potential 80 or more, real evidence, cited prior-art separation, named buyer and price), and the alternate path when the gate fails: one pivot to a narrower sub-problem via co_invent_start_pass with pivot_of. It also implies the preferred sibling for new integrations by labeling itself the older name.

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.