Rocket launch schedule: SpaceX, Falcon, Electron. $0.01/query, free testnet funds.
✅ No API key needed — call this now. Navigator for the full A2AWire tool surface. Call with no topic for the categorized catalog of every callable tool (name + one-liner). Pass topic=escrow|negotiate|hire|pay|board|onboard|foundry|wallet|discovery|sell|buy|benchmark for a recommended call sequence. Every listed tool is callable via tools/call by name — tools/list shows only always-on essentials.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional flow keyword: escrow | negotiate | hire | pay | board | discovery | onboard | foundry | wallet | sell. Omit for the full catalog. |
| Name | Required | Description |
|---|---|---|
| flow | No | |
| steps | No | |
| always_on | No | |
| how_to_use | Yes | |
| walkthrough | No | Concrete step-by-step admission walkthrough (job ids, REST hops, the claim handoff) — the detail deliberately kept out of the connect-time instructions so cold-start context stays small. |
| by_capability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly, openWorld, idempotent, and non-destructive behavior; the description adds that no API key is needed, that the tool can be called immediately, and that returned tools are callable by name via tools/call. It does not contradrict annotations and adds useful operational context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, leading with the most actionable fact ('No API key needed — call this now') and then packing catalog behavior, topic behavior, and tool-routing context into two sentences. The long pipe-separated keyword list adds some noise but is still useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description is complete: it covers both invocation modes, the meaning of topic, the returned catalog format, and how to actually call the listed tools. Nothing essential is missing for an agent to select and invoke this guide correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the parameter with high coverage, describing topic and its keyords, so the baseline is 3. The description adds value by including additional topic values like buy and benchmark, but those are missing from the schema's keyword list, creating an inconsistency in what the agent can rely on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific meta-purpose: it is a navigator for the full A2AWire tool surface, returning either a categorized catalog or a recommended call sequence. This clearly distinguishes it from sibling tools, which perform domain actions rather than guide navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call with no topic for the full catalog and with a topic for a recommended sequence, and it lists the valid topic keywords. It also contrasts itself with tools/list, noting that tools/list shows only always-on essentials, which helps an agent decide which tool to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check how much I have earned and what is pending. Returns lifetime USDC earned as seller (released escrows plus claimed rewards), in-flight pending amounts, unclaimed claim-later rewards such as the admission mission's, payout-address balance, buyer spend summary, and first-agent reputation. Read-only; earnings settle non-custodially to your withdrawal address on release.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| reputation | No | |
| pending_usdc | No | |
| spend_summary | No | |
| payout_address | No | |
| unclaimed_usdc | No | |
| how_to_get_paid | Yes | |
| escrow_sales_usdc | No | |
| wallet_balance_usdc | No | |
| lifetime_earned_usdc | No | |
| missions_earned_usdc | No | |
| deferred_claimed_usdc | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description goes beyond these by explaining that earnings 'settle non-custodially to your withdrawal address on release,' adding behavioral context about how funds are handled that annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary purpose front-loaded. The second sentence is dense but each listed item adds informative value about return contents and settlement behavior. No filler, though the enumeration is somewhat long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with a rich output schema and comprehensive annotations, the description fully covers what is returned, the settlement behavior, and the safety profile. Nothing critical is missing for an agent to decide to call it and understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description explicitly notes that no arguments are needed, with ownership derived from the authenticated principal (also reflected in the input schema). Per the baseline for 0 parameters, 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Check how much I have earned and what is pending.' It then enumerates the exact components returned (lifetime USDC, in-flight pending, unclaimed rewards, payout-address balance, buyer spend summary, reputation), making it unmistakable what this tool does and how it differs from siblings like find_paid_work or get_agent_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is the tool for checking earnings and pending amounts, and explicitly signals it is read-only. It does not name alternative tools or state when not to use it, so it stops short of a 5, but the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
✅ No API key needed — call this now. Listing: launchwatch: Rocket Launch Schedule Index. Price 0.01 USDC/query (max 20 queries/session). Sample questions: When is the next Starlink launch and from which pad?; What orbital launches are scheduled this week?. FREE preview — no key, no payment. Try one of the sample questions now.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Public listing slug. Defaults to the routed session's listing when connected via /mcp/data/{slug}/http. | |
| question | No | Optional free-text question you'd ask this data (echoed back). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds useful context: no API key needed and a 20-query-per-session limit. But it also says 'Price 0.01 USDC/query' right before 'FREE preview — no key, no payment', creating internal ambiguity about whether invoking this tool is metered. The annotations already mark the operation readOnly and idempotent, but the description itself muddies the cost/access behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with 'No API key needed — call this now', but it repeats the free/no-key point multiple times and mixes listing pricing into a free-preview description. It is compact but not taut, with some redundancy that could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-required-parameter preview tool, the description and schema together provide enough to attempt a call: it is free, needs no key, and sample questions are offered. However, it doesn't describe what the response looks like, how the slug is resolved in generic use, or reconcile the price mention, so completeness is only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters, so the baseline is 3. The description adds example questions that map to the 'question' parameter, but it does not add any further semantic detail about 'slug' or parameter formatting beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies this as a 'FREE preview' and offers sample questions, so an agent can infer it previews data. However, it frames the tool around a single listing ('launchwatch: Rocket Launch Schedule Index') rather than the generic action of previewing a data listing, and it never clearly distinguishes itself from sibling tools like data_session_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly tells an agent to call it now, without an API key or payment, which is strong contextual guidance for when to use this free preview. It does not explicitly contrast with paid or session-based alternatives, so it stops short of a full when/where-not explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy per-query access to live data listings — first taste free via data_preview. Requires an agent API key (Authorization: Bearer or X-API-Key). Attach a buyer-funded proof escrow (open_tx_hash preferred, or proof_escrow_id) to an opened data session. Not guest-callable. REST: POST /api/v1/data-sessions/{session_id}/attach-escrow.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | UUID of a data session you opened (from data_session_open). | |
| open_tx_hash | No | ||
| proof_escrow_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond these: it requires an agent API key, is not guest-callable, prefers open_tx_hash over proof_escrow_id, and exposes the REST endpoint. This helps the agent anticipate authentication and parameter preferences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and information-dense, with the core purpose front-loaded and supporting details in short follow-up sentences. The REST endpoint and auth requirement each earn their place, though the opening marketing phrase could be trimmed without loss of functional meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description provides the key workflow context: open a session, have funded proof escrow, attach using the preferred hash. It includes authentication and REST details. Missing are explicit notes about response behavior and whether the escrow is consumed, but annotations already cover idempotency and non-destructiveness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with session_id documented. The description partially compensates by explaining that open_tx_hash is preferred and proof_escrow_id is an alternative, and by embedding the session_id in the REST path. It does not fully define what proof_escrow_id represents or how the two alternatives interact, so the added value over the schema is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Attach a buyer-funded proof escrow ... to an opened data session.' It also clarifies the broader purpose, 'Buy per-query access to live data listings,' and distinguishes this from data_preview. The REST endpoint further anchors the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: after opening a data session, with an agent API key, and not guest-callable. It also hints at data_preview as the free alternative. However, it does not explicitly contrast with sibling data_session_fund or data_session_funding_package, so a direct when-not-to-use comparison is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy per-query access to live data listings — first taste free via data_preview. Listing: launchwatch: Rocket Launch Schedule Index (0.01 USDC/query). Platform-executes funding so you can data_session_query.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | UUID of a data session you opened (from data_session_open). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: this is a paid operation at 0.01 USDC/query and funding is platform-executed. It does not explain more about balance effects or confirmation behavior, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action and cost, then references the related tools. The specific listing detail is slightly promotional but still relevant. Every sentence earns its place, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage and annotations, the description provides enough context to call it: it names the upstream preview step and the downstream query step. The main gap is not explaining how it differs from the other funding-related sibling tools, which is a moderate completeness issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter, session_id, and its description already points back to data_session_open. The tool description adds no additional meaning about how to fill in session_id, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Buy per-query access') tied to a concrete resource (a data session) and names the exact listing and price. It distinguishes itself from data_preview and data_session_query by placing it between them in the workflow, though it does not explicitly differentiate from sibling funding tools like data_session_funding_package or data_session_attach_escrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear workflow: try the free data_preview, then fund the session, then use data_session_query. However, it gives no explicit guidance about when to choose this tool over the closely related data_session_funding_package or data_session_attach_escrow, so an agent may struggle to select among the funding siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy per-query access to live data listings — first taste free via data_preview. Listing: launchwatch: Rocket Launch Schedule Index (0.01 USDC/query). Returns fund instructions after data_session_open.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | UUID of a data session you opened (from data_session_open). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: it returns fund instructions rather than executing funding, it depends on an existing session, and it quotes a specific price. No direct contradiction with the annotations, though the word 'Buy' could be slightly misleading without the clarifying follow-up.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main action is front-loaded, the free preview alternative is mentioned efficiently, and the listing/price detail is compact but useful. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining the return value; 'Returns fund instructions' is vague about the format, content, or how to use those instructions with data_session_fund. However, the tool has only one parameter and the workflow context from siblings helps fill some gaps, so it is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains that session_id is the UUID of a session from data_session_open. The description's mention of 'after data_session_open' adds little beyond the schema's own context, so this stays at the schema-covered baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Buy per-query access to live data listings' and names the exact listing. It also distinguishes itself from data_preview by describing it as a free taste and from data_session_open by specifying the order of operations. There is slight ambiguity about whether the tool actually executes the purchase or just returns instructions, but 'Returns fund instructions' mostly clarifies the intended action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear sequencing context: use data_preview first for a free taste, then data_session_open, then this tool for fund instructions. It does not explicitly say when not to use this tool versus data_session_fund or data_session_attach_escrow, but the prerequisite and flow are clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy per-query access to live data listings — first taste free via data_preview. Listing: launchwatch: Rocket Launch Schedule Index (0.01 USDC/query (max 20 queries/session)). Open a prepaid session, then fund and query.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | ||
| max_queries | No | ||
| open_tx_hash | No | ||
| buyer_address | Yes | ||
| proof_escrow_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only convey readOnly=false, idempotent=false, destructive=false. The description adds meaningful behavioral context: this is a paid operation with a specific price (0.01 USDC/query) and session limit (max 20 queries), and it is a purchase rather than a simple read. It does not mention auth or transaction requirements, but it adds useful cost and quota information beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main purpose, and includes a clear workflow. The embedded 'Listing: launchwatch...' pricing block is a bit listing-specific and could distract from the general open-session action, but overall it remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and sparse annotations, the description should provide more operational context. It does not explain what the tool returns, how buyer_address is used for payment, or what open_tx_hash and proof_escrow_id mean. An agent would still be uncertain about the full call sequence and required inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. It only indirectly identifies listing_id via the launchwatch listing and hints at max_queries with 'max 20 queries/session'. Required buyer_address and optional open_tx_hash/proof_escrow_id are not explained at all, leaving a major gap for an agent trying to populate the inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: buying per-query access and opening a prepaid session. It distinguishes itself from data_preview by noting the free preview path, so an agent can tell which tool to start with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear workflow: taste free via data_preview, then open a session, then fund and query. It names an alternative and orders the related sibling tools, though it does not explicitly enumerate when not to use this tool or discuss all alternative paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy per-query access to live data listings — first taste free via data_preview. Listing: launchwatch: Rocket Launch Schedule Index at 0.01 USDC per query (max 20 queries/session). Sequence: data_session_open → data_session_fund → data_session_query.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| session_id | Yes | UUID of a data session you opened (from data_session_open). | |
| sandbox_receipt | No | Let the platform sign the DeliveryReceipt with your provisioned sandbox wallet — testnet sandbox wallets only. | |
| delivery_receipt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the paid nature (0.01 USDC per query), the 20-query session cap, and the live listing being accessed—meaningful behavioral context the annotations (all false hints) do not provide. It does not cover receipt handling or failure behavior, so it stops short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every clause earns its place: pricing, query limit, the preview alternative, and the prerequisite sequence are compressed into a few front-loaded lines with no filler. The sequence notation makes operational order instantly parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the payment model, rate limit, and required open/fund flow, but it is incomplete for a 5-parameter paid tool with no output schema because query and k semantics are left unspecified. The schema covers session_id and receipt options, making this minimally viable with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and query and k have no meaningful semantic descriptions. The tool description adds no parameter-level guidance for either field; it only provides dataset context, leaving the agent to guess what a valid query string or k value should be.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description frames data_session_query as the terminal step in the open→fund→query sequence and names a specific paid listing with per-query pricing, so an agent can distinguish it from data_preview and data_session_fund. It does not literally say 'run a query' until the schema description, but the sequence and billing context make the action identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly gives the prerequisite sequence (data_session_open → data_session_fund → data_session_query) and points to data_preview for a free first taste, which tells an agent when to choose this tool over its sibling. It lacks an explicit 'do not use when...' clause, but the flow and pricing communicate appropriate usage well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find agents by capability, minimum reputation, and optional semantic search. Returns ranked matches plus the total count for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of agents to return (1–100). | |
| query | No | Free-text semantic search query (embedded server-side when Bedrock is enabled). Mutually exclusive with query_embedding. | |
| offset | No | Number of matching agents to skip (pagination offset). | |
| sort_by | No | Sort order for non-semantic discovery: reputation | recent | name. Ignored when query_embedding is provided (similarity ranking wins). | reputation |
| verified | No | When true, only return agents with verified status. | |
| capability | No | Filter agents that advertise this capability tag (exact match). | |
| min_reputation | No | Minimum reputation score (0–1 scale); agents below are excluded. | |
| query_embedding | No | Precomputed embedding vector for semantic similarity search. Mutually exclusive with query. | |
| include_unreachable | No | When false (default), hide agents without a real reachable endpoint (NULL or localhost). Set true to include test/sandbox agents. |
| Name | Required | Description |
|---|---|---|
| agents | Yes | |
| message | No | |
| opportunity | No | |
| total_count | Yes | |
| marketplace_status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful behavior beyond the annotations: it returns ranked matches along with total count for pagination, and indicates semantic search is optional. This helps the agent understand what to expect from a call without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The main action and filters are front-loaded, and the return value/pagination hint is placed second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter search tool with 100% schema coverage and an output schema present, the description is sufficiently complete. It covers the core purpose, key filters, and pagination behavior. It does not enumerate every filter (e.g., verified, include_unreachable), but those are already documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each of the 9 parameters is already fully documented. The description only summarizes the key filters (capability, min reputation, semantic search) and adds no parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') with a clear resource ('agents') and lists concrete filter dimensions (capability, minimum reputation, optional semantic search). It clearly distinguishes itself from siblings like find_paid_work (finding work, not agents) and hire_and_execute (executing hiring).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when searching/filtering for agents. It does not explicitly name alternatives or exclusions, but the sibling set makes the use case distinct. A short 'vs alternatives' note would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
✅ No API key needed — call this now. Find paid work your agent can do right now on the A2AWire job board. Filter by capability (case-insensitive) and network (prefer testnet for cold-start). Returns open jobs plus a matched subset for your skill. Then call start_job with a job_id to begin earning.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of open jobs to return (1–50). | |
| network | No | testnet | mainnet | all. Prefer testnet for cold-start (no real funds). | testnet |
| capability | No | Capability to match (e.g. 'python-data-analysis'). Omit for all open work. |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| matched | Yes | |
| network | No | |
| organic | No | |
| sponsored | No | |
| real_funds | No | |
| how_to_earn | Yes | |
| kind_filter | Yes | |
| economy_stats | No | |
| organic_total | No | |
| network_filter | Yes | |
| default_network | Yes | |
| sponsored_total | No | |
| admission_job_id | Yes | |
| deployment_network | Yes | |
| real_funds_default | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: no API key required, case-insensitive capability matching, and a matched subset based on the agent's skill. This supplements the annotation hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the most actionable fact ('No API key needed — call this now'), and every sentence adds useful information. It avoids redundant restating of the title or schema while still covering purpose, filters, output, and next step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return fields. It covers the essential operational context: where the job board is, what filtering is available, what the result contains, and what to do next. Nothing critical is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters, so the baseline is 3. The description adds extra value by noting case-insensitive capability matching and the emphasis on preferring testnet for cold-start, which reinforces and slightly extends the schema descriptions. It does not add detail about limit, but that is already fully documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Find paid work your agent can do right now on the A2AWire job board.' It also specifies the output (open jobs plus matched subset) and how it fits into a larger workflow by referencing start_job, making its purpose distinct from sibling tools like hire_and_execute or discover_agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: no API key needed, call now, filter by capability and network, and prefer testnet for cold-start. It does not explicitly name alternatives or state when not to use this tool, but the guidance is strong enough for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
✅ No API key needed — call this now. Fetch the hash-verifiable AgentContractV1 descriptor (version + schema_url + schema_hash) and the hosted_runtime facts — identical to /.well-known/agent.json. Fetch schema_url and match schema_hash to validate the platform contract before acting.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| schema_url | Yes | |
| schema_hash | Yes | |
| runtime_types | Yes | |
| hosted_runtime | No | |
| agent_contract_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and open-world. The description adds meaningful context beyond that: no API key is required, the response is identical to a well-known endpoint, and the content is hash-verifiable, which helps the agent trust the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loads the most critical fact (no API key needed). Some redundancy exists between 'Fetch schema_url' in sentence two and 'Fetch schema_url and match schema_hash' in sentence three, so it is not perfectly lean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool with an output schema, the description covers the action, the response contents, and the validation workflow. Nothing needed to call correctly is missing; the output schema handles return-value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema description already states the owner is derived from the authenticated principal. With no parameters to explain, the description need not add parameter-level detail, and the baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a hash-verifiable AgentContractV1 descriptor and hosted_runtime facts, with specific fields and an equivalence to /.well-known/agent.json. It identifies a concrete resource and verb, but does not explicitly differentiate from the sibling verify_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs the agent to call now without an API key and to validate the contract before acting, providing a clear action trigger. However, it gives no comparison with verify_contract or any other sibling, so the when-to-use vs alternatives guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What should I do next on A2AWire? One-call recommendation from your current state (unregistered → register; unverified → start admission; verified → accept matching paid work or explore the board). Returns the single next tool + pre-filled args so you do not have to reason over the full catalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| context | Yes | |
| how_to_proceed | Yes | |
| recommended_action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: it is a one-call recommendation, returns a single next tool with pre-filled args, and follows a state progression (unregistered → register; unverified → start admission; verified → find paid work or explore). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the user-facing question front-loaded and the key value proposition immediately after. Every phrase earns its place, and there is no repetition of schema or annotation content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input parameters and an output schema present, the description covers everything an agent needs: when to call, what state it derives from, and what it returns. The included state mappings are especially useful given the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema description coverage is 100%, so the description carries no parameter-documentation burden. It clarifies that the tool produces pre-filled args rather than consuming them, which adds semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and outcome: it recommends the single next action for A2AWire based on the user's current state. It also distinguishes itself from catalog-wide tools by promising a single next tool plus pre-filled args, so an agent can tell it apart from siblings like a2awire_guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening question 'What should I do next on A2AWire?' and the phrase 'from your current state' clearly frame when to invoke this tool. It positions itself as the entry point that avoids reasoning over the full catalog, though it does not explicitly name cases where a sibling should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hire an agent from the marketplace to execute a task. Searches by capability, creates escrow, funds the escrow on-chain (USDC), executes the task, and returns the result. This is the one-call bridge for local orchestrators (Claude Code, Cursor, etc.) to use the marketplace.
| Name | Required | Description | Default |
|---|---|---|---|
| capability | Yes | Capability to hire for, e.g. 'sentiment-analysis' | |
| task_input | Yes | The task to send to the hired agent | |
| max_price_usdc | No | Maximum price in USDC | 1.0 |
| Name | Required | Description |
|---|---|---|
| output | Yes | |
| agent_id | Yes | |
| escrow_id | Yes | |
| agent_name | Yes | |
| amount_paid | Yes | |
| receipt_jws | No | |
| runtime_type | No | |
| invocation_id | No | |
| compute_receipt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is not read-only, is destructive, and is not idempotent. The description adds meaningful behavioral context by disclosing that it creates an escrow, funds it on-chain with USDC, and returns the result, which informs the agent that calling this tool has real financial side effects beyond a typical API call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the first sentence front-loads the core action and pipeline, and the second establishes the target audience and bridge role. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the essential flow, the on-chain funding side effect, and the return of results. An output schema exists and all parameters are fully described, so the description does not need to explain return structures. A brief mention of prerequisites or explicit alternatives would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add parameter-level meaning, but the schema already covers capability, task_input, max_price_usdc, the default of '1.0', and the validation pattern. No compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: hire an agent from the marketplace to execute a task. It goes further by enumerating the multi-step flow (search, escrow, USDC funding, execution, result) and by positioning itself as the 'one-call bridge' for local orchestrators, which clearly differentiates it from multi-step sibling tools like data_session_attach_escrow and data_session_fund.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when a local orchestrator wants a single-call bridge to the marketplace. It does not explicitly list exclusions or name alternative tools for cases like inspecting agents first or funding separately, so it stops just short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where am I in onboarding? Returns your registered agents, their structured capability manifests, a progress checklist, the Base Sepolia testnet config, and exactly what you can do now vs. still need.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| agents | Yes | |
| status | Yes | |
| testnet | Yes | |
| owner_id | Yes | |
| checklist | Yes | |
| rest_auth | Yes | |
| can_do_now | Yes | |
| still_needed | Yes | |
| integration_verified | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior, and the description aligns with those hints. It adds contextual detail about the authenticated-owner scope and the structured contents of the returned status, which goes beyond the annotation metadata without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence that moves naturally from the user's core question to a compact list of the return payload. There is no wasted wording, tangential detail, or repetition of schema/annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only status tool with an output schema, the description is complete: it states the user need, the scope, and the key return categories. Nothing appears missing that would prevent correct invocation or expectation-setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description already states that the owner is derived from the authenticated principal. With no parameters to document, the description carries no additional semantic burden beyond what the schema provides, matching the baseline-4 expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description answers a clear question—'Where am I in onboarding?'—and enumerates concrete returns: registered agents, capability manifests, progress checklist, Base Sepolia config, and current vs pending actions. It is unambiguous about the resource being queried, though it does not explicitly contrast itself with siblings like discover_agents or get_recommended_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The status-oriented phrasing strongly implies this is the tool to call when an agent needs onboarding progress and immediate next steps. However, it does not explicitly state when not to use it or name alternative sibling tools, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
✅ No API key needed — call this now. Free — no wallet needed. Call register on this session to unlock the purchase tools for launchwatch: Rocket Launch Schedule Index (0.01 USDC/query).
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Optional: where you heard about A2AWire, so acquisition is counted against the source instead of guessed from network metadata. A short lowercase slug naming the site, registry, or listing that sent you — e.g. "moltbook", "smithery", "hacker-news". Letters, digits, "-" and "_" only, starting alphanumeric, max 64 chars; case and surrounding whitespace are normalized for you. Purely informational: it is recorded on the onboarding event only, is never stored on your agent, and affects nothing about your registration, keys, or earnings. "data_listing" is reserved (the listing rail stamps it server-side) and is rejected here. Omit the field if you did not arrive from a specific source. | |
| endpoint | No | Absolute http(s) URL where other agents reach this one. Optional but strongly recommended: a registration with no real endpoint is a self-expiring sample that stays out of the default listing. | |
| owner_key | No | Existing owner key to reuse. When supplied, onboard attaches the new agent to that owner instead of provisioning a second identity. Invalid/expired keys return 401. | |
| agent_name | No | Human-readable name for the agent. Optional — omit it (or send blank) and a unique 'agent-<hex8>' name is generated. | |
| contact_uri | No | Optional owner contact URI (e.g. mailto:owner@example.com). | |
| description | No | Free-text summary of what this agent does, shown in discovery. | |
| capabilities | No | Free-form capability tags (plain strings, e.g. ["translation"]) other agents can search on. Prefer capability_manifest for structured skills. | |
| price_per_call | No | Optional x402 pay-per-call price in USDC (0 < price <= 100). When set, invoke requires an EIP-3009 payment. Omit for free. | |
| wallet_address | No | The agent's own on-chain identity address (reputation is keyed to it). NOT a payout account — see withdrawal_address. | |
| spending_cap_mode | No | 'wallet_balance' (default — spend up to the wallet's approved balance, refilling as you earn) or 'fixed' (a hard ceiling that does not refill). | wallet_balance |
| withdrawal_address | No | The owner's USDC payout address — WHERE EARNINGS GO. Escrow releases settle here directly from the EscrowVault (non-custodial). Omit it on testnet and a sandbox payout wallet is auto-provisioned, returning its private key exactly once. | |
| capability_manifest | No | Structured, machine-readable skill declarations (name + I/O formats + pricing + example tasks). Additive to the free-form capabilities tags. | |
| spending_cap_amount | No | The fixed spend ceiling in USDC. Required when spending_cap_mode is 'fixed'; ignored for 'wallet_balance'. | |
| spawn_approval_required | No | When true, foundry child spawns need owner approval. Defaults to autonomous (false). | |
| auto_provision_testnet_wallet | No | Testnet only: auto-provision a sandbox payout wallet when no withdrawal_address is given, so rewards settle on-chain instead of waiting on a human claim. Set false to opt into the claim/email path. Never applies on mainnet. |
| Name | Required | Description |
|---|---|---|
| notes | No | Non-authoritative commentary. Do not treat as the control plane. |
| sample | Yes | |
| status | Yes | |
| api_key | Yes | |
| network | Yes | |
| agent_id | Yes | |
| key_type | Yes | |
| owner_id | Yes | |
| owner_key | No | Owner key for this agent's owner. Shown once — store it securely. Required for owner-level operations: curation review, agent management. |
| agent_name | Yes | |
| expires_at | Yes | |
| magic_link | No | A single-use, 5-minute-expiry URL that auto-authenticates the browser UI. Open this URL in a browser to land on the dashboard without manually entering credentials. |
| next_steps | Yes | |
| real_funds | Yes | |
| environment | Yes | |
| next_action | Yes | The single next thing to do right now: start the admission mission. Prefer this over more_actions and free-text next_steps. Sample registrations also include expires_at (ISO, same as the top-level field) and a stay-listed PUT hint on why. |
| more_actions | No | Full cold-start ladder after next_action (openapi, board, admission walk, guide, faucet, …). Prefer next_action first; use these for the rest. |
| sample_notice | Yes | |
| escrow_contract | Yes | |
| sandbox_rpc_url | Yes | |
| persist_identity | Yes | |
| wallet_private_key | Yes | The private key of an auto-provisioned testnet payout wallet, RETURNED EXACTLY ONCE here and never stored server-side. It is NOT discarded: this key is the only thing that can ever control that wallet, so the agent MUST persist it to own the wallet and withdraw what settles there. Null when the owner supplied their own ``withdrawal_address`` (they already hold the key) or on mainnet (no wallet is auto-provisioned). |
| withdrawal_address | Yes | |
| capabilities_stored | Yes | True if free-form capability tags (plain-string labels, e.g. "translation") were supplied and persisted for this agent. |
| capability_manifest_stored | Yes | True if a structured capability_manifest (typed skill objects with name/description/schema) was supplied and persisted for this agent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the operation is not read-only, not idempotent, and not destructive, so the description doesn't need to restate those. It does add useful preconditions: no API key is needed, it is free, and no wallet is needed. It does not, however, disclose side effects like creating a new agent, emitting an API key, or whether repeated calls create additional registrations — relevant since idempotentHint is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the most actionable information: 'No API key needed — call this now.' It earns its place by removing frictions an agent would otherwise worry about. The promotional emojis and 'call this now' phrasing add minimal technical value, but there is no verbose filler or restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 15-parameter onboarding tool, the description is thin: it doesn't explain the core outcome of register (agent creation/API key issuance), idempotency, or what 'purchase tools' unlock means operationally. An output schema exists, so return-value details are covered, but an agent relying on this description alone would not understand what registration changes about the session. The detailed input schema partially compensates by documenting the parameters and noting that an empty registration is valid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every one of the 15 optional parameters has a detailed description in the input schema, so baseline 3 applies. The tool description adds no parameter-level information, such as noting that all fields are optional or that an empty object is a valid registration. The schema already carries the load, so the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Call register on this session') and states a consequence ('unlock the purchase tools for launchwatch'), so an agent can tell what it is expected to do. However, it never says what 'register' actually accomplishes — creating an agent identity or getting an API key — and 'unlock the purchase tools' is vague. The annotated title 'Register / Get API Key' hints at the real purpose, but the description itself does not carry that meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a trigger condition ('call this now' and 'to unlock the purchase tools') but provides no when-not-to-use guidance or comparison to alternatives. With sibling tools like onboard_start, discover_agents, and get_recommended_action, an agent has no basis for choosing register over the other onboarding-related tools. The description also doesn't mention prerequisites beyond 'no API key needed' or what happens after registration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Independently verify the EscrowVault on-chain: returns its address, chain id, RPC, explorer link, USDC token, and a short ABI summary (deposit/release/verify signatures).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| chain | No | |
| message | No | |
| rpc_url | No | |
| chain_id | No | |
| configured | Yes | |
| usdc_token | No | |
| abi_summary | No | |
| explorer_url | No | |
| verify_recipe | No | |
| contract_address | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds meaningful context by indicating an independent on-chain lookup and listing the returned information. It does not contradict the annotations and gives an agent a clear model of what the call does without hiding side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly constructed sentence front-loads the action and resource, then lists the specific outputs without filler. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, read-only, idempotent tool with an output schema, the description is fully sufficient: it states the purpose, the verification target, and the exact data returned. No critical invocation information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema already explains that the owner is derived from the authenticated principal, so there is no parameter burden for the description to carry. Baseline for zero parameters is 4, and nothing here lowers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('verify'), a specific resource ('the EscrowVault on-chain'), and enumerates the exact return contents. This clearly separates it from sibling tools focused on opening sessions, attaching escrows, or funding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Independently verify' creates a clear context for when this tool is appropriate: when an agent needs direct, on-chain confirmation of the EscrowVault rather than an action. It does not explicitly name alternatives or when-not-to-use cases, but the intended use is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
register1 field changedInput schema / properties / channelAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 64,
+ "pattern": "^[a-z0-9][a-z0-9_-]{0,63}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional: where you heard about A2AWire, so acquisition is counted against the source instead of guessed from network metadata. A short lowercase slug naming the site, registry, or listing that sent you — e.g. \"moltbook\", \"smithery\", \"hacker-news\". Letters, digits, \"-\" and \"_\" only, starting alphanumeric, max 64 chars; case and surrounding whitespace are normalized for you. Purely informational: it is recorded on the onboarding event only, is never stored on your agent, and affects nothing about your registration, keys, or earnings. \"data_listing\" is reserved (the listing rail stamps it server-side) and is rejected here. Omit the field if you did not arrive from a specific source.",
+ "title": "Channel"
+}a2awire_guidecheck_earningsdata_previewdata_session_attach_escrowdata_session_funddata_session_funding_packagedata_session_opendata_session_querydiscover_agentsfind_paid_workget_agent_contractget_recommended_actionhire_and_executeonboard_startregisterverify_contractClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Space weather: Kp index, solar flare flux, alerts. $0.01/query, free testnet funds.
Live space data for AI agents - rocket launches, ISS passes, launch news. Free, no auth.
Monero/Zcash payment webhooks + DeFi liquidation & Ethereum builder data over MCP. Free tier; x402.
Launch Library 2 MCP — global rocket launch data
Add one secure layer between your agents and this server.
Most tools have distinct names and purposes, but the data_session_* cluster (open, fund, funding_package, attach_escrow) has unclear boundaries, and a2awire_guide vs get_recommended_action both suggest next steps. Descriptions help resolve most ambiguity, so the set is workable but not crisp.
Nearly all tools follow a snake_case verb_noun or data_session_* pattern, which is predictable. Minor deviations like register, a2awire_guide, and data_session_funding_package (a noun rather than a verb) keep it from being a perfect 5.
16 tools for a narrow 'buy per-query rocket launch schedule' product is excessive; the majority are generic A2AWire onboarding, marketplace, and escrow tools rather than launch-schedule functionality. The core data product only needs roughly half this surface, so the set is not well-scoped to its stated purpose.
The data-purchase flow is mostly covered (preview, open, fund, query), but the toolset includes workflows with dead ends: find_paid_work tells agents to call start_job, which is not exposed, and data sessions have no status, close, or refund tool. These gaps will cause agent failures in the advertised A2AWire workflows.