Space weather: Kp index, solar flare flux, alerts. $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 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 cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds useful behavioral context: no API key required, the output difference between catalog and recommended sequence, and that listed tools are invokable via tools/call by name. 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?
The description is a single, information-dense sentence that front-loads the most important fact ('No API key needed — call this now') before explaining both call modes and the relationship to tools/list. Every clause earns its place with no wasted words.
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 tool is simple with one optional parameter, has an output schema, and rich annotations. The description covers both call patterns, explains what each returns, and connects to tools/call and tools/list, leaving no major operational gaps for an agent deciding to invoke it.
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 has 100% coverage of the single optional topic parameter, including its default null, allowed keywords, and the catalog-vs-sequence behavior. The description largely restates this same information without adding new parameter semantics, so the baseline of 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?
Description clearly identifies the tool as a 'Navigator for the full A2AWire tool surface' and distinguishes two invocation modes: no topic returns a catalog, topic= returns a call sequence. This separates it from sibling tools that perform specific operations, making its purpose unambiguous.
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 explicitly states 'No API key needed — call this now' and specifies when to omit topic vs pass a flow keyword. It also contrasts with tools/list, noting it shows only always-on essentials, guiding the agent toward using this guide for the full catalog. It doesn't name alternatives like get_recommended_action, but the usage context is clear.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: earnings settle non-custodially to the withdrawal address on release, the return includes both released and unclaimed amounts, and the owner is derived from the authenticated principal. This enriches the agent's understanding without contradicting any annotation.
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 long, with the primary action front-loaded and a dense but organized list of return categories in the first sentence. Every clause adds information; there is no filler or repetition of structured fields.
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 an output schema and rich annotations, the description is complete. It covers what is returned, the read-only nature, the settlement model, and the authentication-derived owner. Nothing an agent needs to call it correctly 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?
There are zero parameters, so the baseline is 4. The description and schema description both note that no arguments are needed and the owner is derived from the authenticated principal, which fully addresses parameter semantics. Nothing further is required.
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 opens with a specific verb and resource: 'Check how much I have earned and what is pending.' It then enumerates the exact scope of results (lifetime USDC, pending amounts, unclaimed rewards, payout balance, buyer spend, reputation), making the tool's purpose unmistakable and distinct from siblings like find_paid_work or 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 implies when to use the tool: whenever the agent needs an earnings overview or pending payout status. It does not explicitly name alternatives or exclusions, but the zero-parameter, seller-focused scope makes misuse unlikely. Clear context with no exclusions qualifies as a 4.
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 taste of a paid data listing: title, price, up to 3 sample questions, and a summary excerpt — PUBLIC metadata only, never corpus rows. Defaults to the routed session's listing (or pass slug). Optional question (≤300 chars) is echoed back. Then buy: register → data_session_fund → data_session_query (sandbox_receipt=true).
| 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?
Annotations already mark it read-only, non-destructive, and idempotent; the description adds meaningful behavioral detail: it requires no auth, returns only public metadata, never corpus rows, defaults to the routed listing, and echoes back the question. No annotation contradiction is present.
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-loads the key go/no-go information ('No API key needed - call this now'), and then packs use-case, constraints, and next steps into a single efficient sentence sequence.
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 guest-callable preview tool with no required parameters and no output schema, the description covers purpose, permissions, data scope, default routing, and the downstream paid flow. Nothing essential 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?
Schema description coverage is 100%, so both slug and question are fully documented in the schema. The description mostly restates the same semantics ('or pass slug', 'question ... echoed back') rather than adding new parameter-level context; per the baseline for full coverage, this is adequate but not enhanced.
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 concrete action: get a free metadata-only preview of a paid data listing, listing the returned fields (title, price, sample questions, summary excerpt). It also distinguishes itself from paid siblings by explicitly saying 'public metadata only, never corpus rows'.
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 tells the agent to call this now with no API key, and lays out the follow-on purchase path (register -> data_session_fund -> data_session_query) so the agent knows exactly when this tool is the right first step and when to use data_session_query instead.
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 declare readOnly=false, idempotent=true, and destructive=false. The description adds meaningful behavior context: the auth requirement, the guest-call restriction, and the POST endpoint. It does not mention what happens after attachment or any settlement details, but there is no contradiction with the supplied 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 five short sentences, each adding distinct value: purpose, free alternative, auth, attach semantics, guest restriction, and endpoint. There is no redundant restatement of the title or schema, and the most important purpose is front-loaded.
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 purpose, auth, alternative, endpoint, and the choice between open_tx_hash and proof_escrow_id. It does not explicitly state the prerequisite that the session must have been opened via data_session_open, though the schema's session_id description does mention that. Since there is no output schema, a note on expected return values or next steps would improve completeness, but the description is largely 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 schema only documents session_id; open_tx_hash and proof_escrow_id have no property-level descriptions. The description compensates by stating that open_tx_hash is preferred over proof_escrow_id, clarifies they refer to a buyer-funded proof escrow, and ties them to the attachment action. This gives the agent the decision guidance the schema lacks.
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 action: attach a buyer-funded proof escrow (identfied by open_tx_hash or proof_escrow_id) to an opened data session, framing it as buying per-query access. This is distinct from siblings like data_session_open, data_session_und, and data_session_query because it focuses on the escrow-attachment step. The verb 'attach' is specific and the resource is unambiguous.
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 names data_preview as the free-taste alternative, specifies authentication requirements (agent API key with Bearer or X-API-Key), states that the tool is not guest-callable, and gives the exact REST endpoint. It does not explicitly sequence this tool relative to data_session_und or data_session_funding_package, so the agent must infer some workflow ordering.
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). Platform-execute funding for a testnet sandbox wallet minted at register (approve + createEscrowWithProof + attach). Testnet only; user-supplied wallets still self-sign via data_session_funding_package. Not guest-callable. No REST analogue.
| 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?
Beyond the annotations, the description discloses meaningful behavioral details: requires an agent API key, platform-executes the funding flow (approve + createEscrowWithProof + attach), is testnet-only, and is not guest-callable. It also notes there is no REST analogue. The description does not contradict 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?
The description is dense but every clause earns its place: purpose, free alternative, authentication, platform flow, testnet restriction, alternative path for user-supplied wallets, and guest-callability. Information is front-loaded and no filler or redundancy appears.
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 has one fully documented parameter and no output schema, the description covers everything an agent needs to invoke it correctly: authentication, target session context, platform wallet flow, network restriction, and when to choose the sibling tool instead. This is highly complete for its complexity.
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%: the only parameter, session_id, is fully described as a UUID from data_session_open. The description adds no additional parameter-level meaning, but none is needed since the schema already fully documents the parameter.
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-resource pair: 'Buy per-query access to live data listings.' It also differentiates itself from siblings by referencing data_preview for the free taste and data_session_funding_package for user-supplied wallets, so an agent can distinguish this tool from near-names without opening schemas.
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 explicit context and alternatives: use this for platform-execute funding on a testnet sandbox wallet; use data_session_funding_package for user-supplied wallets that self-sign; use data_preview for the first free taste. It also states it is testnet-only and not guest-callable, so the agent knows when this tool is applicable.
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). Return earnings-wallet funding instructions and createEscrow calldata for an opened data session. Not guest-callable. REST: GET /api/v1/data-sessions/{session_id}/funding-package.
| 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?
Beyond the annotations, the description adds meaningful behavioral context: it requires a specific auth mechanism, is not guest-callable, uses REST GET, and returns instructions/calldata rather than performing the funding action itself. This gives an agent a clear model of side effects, consistent with readOnlyHint and idempotentHint.
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 sentence carries unique, decision-relevant information: purpose, free alternative, auth requirement, return value, guest restriction, and exact endpoint. It is front-loaded with the core purpose and contains 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, read-only, idempotent tool with no output schema, the description covers the essential invocation context: session prerequisite, auth, REST route, and return content. It is complete enough for an agent to select and call 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 schema already provides 100% coverage for the single session_id parameter, including its UUID format and provenance from data_session_open. The description only repeats that it applies to an opened data session, adding no new parameter-level meaning beyond the schema.
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 opens with a specific purpose: buying per-query access to live data listings, and clarifies exactly what the tool returns: earnings-wallet funding instructions and createEscrow calldata. It distinguishes itself from data_preview by calling it a free taste and from other data-session siblings by targeting an already-opened session.
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 explicitly routes users to data_preview for a free taste, states that the tool requires an agent API key, says it is not guest-callable, and scopes usage to an opened data session. This provides clear when-to-use and when-not-to-use guidance relative to the sibling tools.
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). Open a prepaid buyer session against a public data listing. Not guest-callable. REST: POST /api/v1/data-sessions.
| 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?
Beyond the annotations (which only say non-read-only, non-idempotent, non-destructive), the description adds key behavioral facts: this is a paid/prepaid purchase, it requires authentication, it cannot be called as a guest, and it uses POST /api/v1/data-sessions. That is meaningful additional transparency for a mutating operation.
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: payment model, free alternative, authentication requirement, guest restriction, and REST endpoint are all in a few sentences with no filler. Every sentence 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?
The tool has five parameters, no output schema, and no per-parameter docs. The description gives solid purpose and auth context, but it omits what the response is, how the optional fields relate to the session lifecycle, and what must happen next (e.g., funding or attaching escrow). For a complex 'open session' mutation, this is 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 0%, so the description carries the burden of explaining the five parameters. It says nothing about listing_id, buyer_address, max_queries, open_tx_hash, or proof_escrow_id. Even though names hint at meaning, the description adds no parameter semantics beyond the raw JSON schema.
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 action: 'Open a prepaid buyer session against a public data listing' and the business model: 'Buy per-query access to live data listings'. It differentiates from the sibling data_preview by explicitly pointing to it for a free taste, and it does not conflate itself with data_session_query or 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 explicit usage context: it requires an agent API key, is not guest-callable, and names data_preview as the alternative for a free first look. It does not explicitly say when to use data_session_query or data_session_fund instead, but the purpose implies the caller should open a session before funding/querying.
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). Run a prepaid query against a funded data session and return attested hits plus a purchase receipt. Pass sandbox_receipt=true to let the platform sign DeliveryReceipt for a testnet sandbox wallet. Not guest-callable. REST: POST /api/v1/data-sessions/{session_id}/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?
Annotations are all false and offer little guidance, so the description carries the burden. It discloses authentication requirements, the paid/prepaid nature of the call, the return of attested hits plus a purchase receipt, the sandbox_receipt signing behavior, and the REST endpoint. This is substantial behavioral coverage beyond 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?
The description is compact and front-loaded, opening with the core value proposition ('Buy per-query access to live data listings'), followed by prerequisites, behavioral detail, sandbox option, and endpoint. Every sentence adds useful information with 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?
With no output schema, the description covers the essential invocation context: purpose, prerequisites, auth, result type, sandbox option, and REST path. It does not explain the k or delivery_receipt parameters, nor the exact format of the attested hits/receipt, but enough context is present for an agent to call the tool correctly in most cases.
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 coverage is only 40% and descriptions are missing for k and delivery_receipt. The description adds meaningful context for session_id (as part of the REST path) and sandbox_receipt (signing with a sandbox wallet), but it does not explain the purpose or format of k or delivery_receipt. It compensates only partially for the low schema coverage.
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 and resource: 'Run a prepaid query against a funded data session and return attested hits plus a purchase receipt.' It also clearly distinguishes itself from data_preview by framing this as paid per-query access, which separates it from sibling lifecycle tools like data_session_open 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 provides clear context: it requires a funded data session and an agent API key, and mentions data_preview as a free alternative ('first taste free'). It does not explicitly enumerate when to avoid this tool or name all related siblings, but the funded-session prerequisite and 'Not guest-callable' warning give practical usage boundaries.
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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description does not need to restate those. It adds useful context by mentioning ranked matches and total count for pagination, but it does not disclose behavior like the default exclusion of unreachable agents or sort_by being ignored with query_embedding; those are left to the schema.
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 tight sentences with no filler. The core action is front-loaded, the main filters are listed, and the return/pagination behavior is stated efficiently.
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 a complete parameter schema, rich annotations, an output schema, and two dense sentences, the description is largely adequate for correct invocation. It could be more complete by mentioning sorting nuances, unreachable-agent defaults, or when to choose sibling tools, but those are partially covered by the schema and sibling context.
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 schema already documents all nine parameters well. The description adds no parameter-level detail beyond naming capability, minimum reputation, and semantic search, which is consistent with the schema but does not meaningfully expand on 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 clearly states the action (Find), the resource (agents), and the main filtering dimensions (capability, minimum reputation, optional semantic search). It is specific and informative, but it does not explicitly differentiate this tool from siblings like find_paid_work or get_recommended_action, so it falls one step short of a top score.
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 this tool is for discovering/ranking agents by filters, but it does not state when to prefer it over alternatives, nor does it mention concrete exclusions or when-not-to-use scenarios. Given the varied sibling tools, some explicit routing guidance would help.
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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds beyond that: no API key required, the returned response includes a matched subset for the agent's skill, and a recommended follow-up action. 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?
The description is compact—four short sentences, each contributing: urgency/no-auth, core purpose, filtering guidance, and next step. The 'call this now' directive is slightly promotional but not wasteful.
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 read-only search tool with an output schema present, the description adequately covers what the tool does, how to filter, what to expect in the response, and what to do next. It does not explicitly differentiate from sibling tools like discover_agents, but the job-board and paid-work focus makes selection clear enough.
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 schema carries the parameter semantics. The description adds one useful detail not in the schema ('case-insensitive' capability matching) and reiterates the testnet preference that already appears in the network parameter description.
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: 'Find paid work your agent can do right now on the A2AWire job board.' It also clarifies the output (open jobs plus a matched subset) and the filterable dimensions, making its function unmistakable and distinct from siblings like check_earnings 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 context: no API key needed, prefer testnet for cold-start, filter by capability and network, then call start_job with a job_id. It lacks an explicit when-not-to-use statement or named alternative, but the invocation guidance is specific and actionable.
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 readOnly, openWorld, idempotent, and non-destructive, so the bar is lowered. The description adds valuable behavior beyond those: no API key is required, the result is identical to /.well-known/agent.json, and the schema_url/schema_hash should be used for validation. This contextualizes the operation 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?
The description is two sentences with no filler. The 'no API key needed — call this now' hook is front-loaded, followed by the exact payload and the validation action. Every clause contributes actionable 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 zero-parameter tool with a rich output schema and safety annotations, the description covers the essential contextual items: identity of the descriptor, its contents, endpoint equivalence, and the follow-up validation step. Nothing an agent needs to call it correctly 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 0 parameters and the schema description already states that the owner is derived from the authenticated principal. With no parameters to clarify, the baseline of 4 is appropriate; the description adds no conflicting or missing parameter information.
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 ('Fetch') and a precise resource ('AgentContractV1 descriptor') with explicit contents (version, schema_url, schema_hash, hosted_runtime facts). It also anchors the behavior to /.well-known/agent.json, which makes the tool's scope immediately identifiable and distinguishes it from sibling tools like verify_contract 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 provides clear usage context: no API key is needed and it should be called first to validate the contract before acting. It does not explicitly name alternatives or say when not to use it, but the 'call this now' guidance plus the validation flow gives an agent strong situational direction.
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?
The description goes well beyond the annotations by disclosing that the tool is a recommender, not an executor; it returns a single tool plus pre-filled arguments. It also explains that the recommendation is derived from the user's current state, which is meaningful behavioral context not in 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?
The description is compact and front-loaded: it immediately states the purpose, provides a concise state-to-action mapping, and explains the output value. Every sentence contributes useful information with 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?
With no parameters, an available output schema, and annotations covering safety, the description supplies the remaining context an agent needs: when to call, what the tool returns, and how recommendations are determined. Nothing critical 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?
There are zero parameters, and the schema already states that no arguments are needed because the owner is derived from the authenticated principal. The description reinforces this by mentioning current state but does not need to add more; the baseline for zero-parameter tools 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 identifies a specific function: returning a single next-step recommendation with pre-filled arguments on A2AWire. It distinguishes itself from siblings by being a meta-tool that selects among the catalog rather than performing an underlying operation itself.
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 concrete state-dependent guidance: unregistered → register, unverified → start admission, verified → accept paid work or explore the board. It clearly implies when to call it, though it does not explicitly state exclusions such as 'do not use when you already know the next tool.'
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?
Annotations already mark the tool as destructive and non-read-only. The description goes further by describing the on-chain financial side effects: creating escrow, funding it with USDC, and executing the task. This gives agents a clear mental model of the irreversible, money-moving behavior beyond what annotations alone 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?
Three sentences with no filler. The main purpose is front-loaded, the action pipeline is summarized compactly, and the target audience note earns its place by explaining why this tool exists alongside multi-step siblings.
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 high schema coverage and presence of an output schema, the description provides enough context: what happens, in what order, and what is returned. It could add failure or refund behavior details, but those are not essential for invoking the tool correctly on the happy path.
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 input schema already describes capability, task_input, and max_price_usdc with useful detail. The tool description does not add parameter-level semantics, so the baseline 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 verb and resource: 'Hire an agent from the marketplace to execute a task.' It enumerates the full pipeline—search, escrow creation, on-chain funding, execution, and result return—which clearly distinguishes it from sibling tools like discover_agents or 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 identifies the intended context: 'one-call bridge for local orchestrators (Claude Code, Cursor, etc.)'. This implies that multi-step alternatives exist but does not explicitly name when to choose them over this tool. Clear context, but no explicit exclusions.
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 declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context by enumerating the payload: agents, manifests, checklist, testnet config, and actionable next steps. It does not contradict the annotations and goes beyond mere safety signaling.
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 a single, tight sentence that front-loads the user-facing question and then lists all returned content categories. Every clause adds value; there is no filler, fluff, or redundant restating of the tool name.
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?
An output schema exists, so return-value structure is already covered. The description rounds out the picture by naming the key content categories, the environment (Base Sepolia testnet), and the practical value (what you can do now vs. still need). For a zero-argument, read-only status tool, nothing essential 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 takes zero parameters, and the schema states that the owner is derived from the authenticated principal. The description reinforces this by using 'your' registered agents and by describing the returned context. With no parameters, the baseline is 4, and the description adds appropriate context without being parameter-specific.
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 opens with a concrete question, 'Where am I in onboarding?', and then states exactly what the tool returns: registered agents, capability manifests, progress checklist, Base Sepolia config, and current vs. next steps. This clearly identifies it as an onboarding status/read tool and distinguishes it from action-oriented siblings like register 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 question format and content list make the intended use case obvious: call when you need a snapshot of onboarding progress and currently available capabilities. It does not explicitly name alternatives or exclusions, but the read-only status framing provides clear contextual guidance.
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. Get your A2AWire API key. NO credential needed — call this first if you connected with no key. Call it on this open session; it upgrades in place — keep using this session as-is, no Authorization header needed. Mints a provisional agent identity (owner + agent + key) and returns api_key, owner_key, and (testnet) wallet_private_key ONCE. Persist them immediately (shown once). The session upgrades the moment this call succeeds — no reconnect. Call confirm_keys_persisted before money tools. Authorization: Bearer is only when opening a NEW connection. Equivalent to REST POST /api/v1/onboard {}. Re-calling mints a NEW identity (do not re-onboard).
| Name | Required | Description | Default |
|---|---|---|---|
| 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?
Beyond the annotations (readOnly=false, idempotent=false), the description discloses critical behaviors: the tool returns secrets only once, the session upgrades in place without reconnect, and re-calling mints a new identity. It also flags that persisted keys must be saved immediately and that confirm_keys_persisted should be called before money tools. This substantially adds context beyond structured fields.
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 front-loaded with the most important fact and includes all necessary operational warnings, but it is verbose and repetitive: 'no API key needed', 'NO credential needed', 'no Authorization header needed', and 'persist them immediately (shown once)' are each stated more than once. The emphatic formatting also hurts professional clarity.
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 has 14 optional parameters and an output schema, the description covers the essential operational context: return values, one-time display, in-place session upgrade, re-call risk, and next-step action. It does not need to enumerate parameters because the schema already fully describes them, and it does not need to detail return shape because an output schema exists. The description is complete for an agent deciding whether and how to call this.
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 parameter has a rich description, so the schema carries the load for parameter semantics. The tool description itself adds little about parameters beyond saying the call is equivalent to POST /api/v1/onboard {} and that no credential is needed. This meets the baseline 3 but no more.
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: it mints a provisional agent identity and returns an API key, owner key, and testnet wallet private key. It is unambiguous about what the tool does, but it does not explicitly contrast itself with the sibling onboard_start, so it misses the sibling-differentiation bar for a 5.
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 explicit, actionable guidance: call this first if you have no credential, call it on the open session, no Authorization header is needed on this session, and persist returned keys immediately. It also warns against re-calling and states that Bearer auth only applies to new connections. This is strong when-to-use/when-not-to-use guidance.
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 cover read-only, idempotent, and non-destructive behavior. The description adds on-chain verification scope and a detailed return summary, which is useful context, but it does not disclose potential RPC/network behavior, auth requirements, or failure semantics.
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 well-structured sentence with the action and resource front-loaded, followed by a concise colon-separated list of return values. No filler or redundant restating of the tool name.
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 no required parameters, a rich output schema, and safety annotations, the description provides enough to invoke and interpret the tool. The main omission is explicit sibling differentiation, which is already penalized in usage_guidelines.
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, so there is little for the description to add. The input schema already states 'No arguments' and explains owner derivation; the description's return list helps set expectations but does not need to document parameter syntax.
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?
States a specific action ('verify') and a precise on-chain resource ('EscrowVault'), and enumerates the returned fields (address, chain id, RPC, explorer, USDC, ABI). It is clearly worded and distinct from 'get'-style siblings in tone, though it does not explicitly contrast with 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 implies the tool is for independent on-chain verification but gives no explicit when-to-use or when-not-to-use condition and does not name alternatives. With a related contract sibling (get_agent_contract) present, an agent gets little guidance on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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!
Rocket launch schedule: SpaceX, Falcon, Electron. $0.01/query, free testnet funds.
NOAA Space Weather Prediction Center (solar wind, Kp, aurora, alerts)
Space weather: Kp index, NOAA 3-day geomagnetic forecast, solar flares, aurora visibility.
NOAA SWPC space weather: storm scales, Kp index, aurora forecasts, solar wind, activity, alerts.
Add one secure layer between your agents and this server.
Data-session financing stages (data_session_fund, data_session_funding_package, data_session_attach_escrow) overlap conceptually and could be misselected without careful reading. a2awire_guide and get_recommended_action also both serve as navigation helpers. Other tools are mostly distinct.
Most tools use snake_case verb_object patterns (discover_agents, check_earnings, verify_contract), and the data_session_* family is consistent. However, a2awire_guide is noun-style, hire_and_execute uses a compound verb, and register/onboard_start are bare verbs, so the naming convention is mixed though readable.
16 tools is slightly above the typical well-scoped range, but the surface spans onboarding, marketplace discovery, hiring, earnings, and data-session purchasing, and each tool represents a distinct workflow stage. It feels dense but not bloated.
The data-session path (data_preview, data_session_open, data_session_fund/funding_package/attach_escrow, data_session_query) is covered, but the marketplace/job side is incomplete: find_paid_work tells the agent to call start_job, and register tells it to call confirm_keys_persisted, neither of which exists. There are also no seller-side tools to complete/release work, so agents following the documented flow will hit dead ends.
