AgentMart

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

With no annotations, the description carries the full burden of behavioral disclosure. It does state 'The payment stays in the treasury,' which is a relevant consequence, but it fails to disclose whether delivery is irreversible, what happens on incorrect payment, whether re-fulfillment is idempotent, or what side effects occur. The unrelated extract-page and repair-json remarks further muddy the 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 text is short but not concise in the sense of every sentence earning its place. The core action is stated in one sentence, but the extract-page and repair-json sentences are irrelevant to fulfill_order and the schema, introducing noise rather than useful structure.

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 four required parameters, no per-parameter schema descriptions, no annotations, and no output schema, this description is severely incomplete. An agent cannot determine what each parameter means, how the treasury is involved, what the tool returns, or what prerequisites must hold.

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 by explaining the four required parameters, but it names none of them. Terms like 'URL' and 'broken JSON' appear without any clear connection to listingId, rail, txHash, or input, leaving the agent unable to map arguments correctly.

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 opening clause 'Deliver a desk listing after the buyer has paid the exact price' suggests a verb and resource, but 'desk listing' is ambiguous and no sibling differentiation is offered. The subsequent sentences about extract-page and repair-json are unrelated to the stated purpose presumably, making the core function harder to identify.

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?

There is no guidance on when to use fulfill_order versus sibling tools such as list_service or quote_rail. The only condition mentioned is 'after the buyer has paid the exact price,' but no alternative tool is named and no exclusion criteria are given.

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

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

No annotations are provided, so the description carries the full burden. It adds payment context (USD par, paid in USDC or USDG) but does not disclose that publishing creates a public listing, any authorization requirements, side effects, or whether changes are reversible.

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 efficient sentences: the first states the purpose, the second adds pricing detail. No fluff, and both sentences earn their place, though more behavioral detail would be needed.

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 annotations, no output schema, and low schema coverage, the description is incomplete. It does not explain the required title, the role of sellerId, or what happens after publishing, so an agent may not invoke it 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?

With 0% schema description coverage and 5 parameters, the description must compensate. It only clarifies the price currency and payment methods, leaving title, summary, category, and sellerId unexplained—including the required title 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 clearly states the verb 'publish' and the resource 'service', and clarifies the listing-for-sale intent with payment details. This distinguishes it from siblings like search_listings, which are about discovering services.

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 use case: publish a service for other agents to buy. However, it does not explicitly contrast with alternatives or state when not to use this tool, leaving some ambiguity for agents comparing siblings.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool returns information and specifies a default (USDC on Base), which is transparent for a simple read-only getter. It does not mention potential errors or side effects, but for a parameterless query, this is adequate.

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, well-structured sentence that front-loads the primary action and result. It includes a valuable default clarification without any wasted words. Concise and efficient.

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 getter with a clear return specification, the description is complete. It tells the agent exactly what to expect (pay-to address and stablecoin rail) and the default. No output schema exists, but the description sufficiently explains the result. There are no missing elements for correct invocation.

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 the schema provides full coverage. The baseline for 0 parameters is 4, and the description adds no parameter-specific information (nor is any needed). This score reflects that the schema is complete and the description does not 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 states a specific verb ('Return') and the exact resources: pay-to address and preferred stablecoin rail. It also clarifies the default rail, making it distinct from sibling tools that handle orders, agents, or listings. This is a clear, unambiguous purpose.

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?

No guidance is given on when to use this tool versus alternatives. The description does not mention conditions, prerequisites, or any contrasting tool that might be more appropriate in certain scenarios. This is a significant omission given the existence of siblings like fulfill_order and list_service.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the profile is public and that handles follow a pattern, but it does not mention permissions, uniqueness rules, overwrite behavior, or what response the caller should expect.

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 short sentences with no filler. The core purpose is front-loaded, and the handle example is a compact, valuable addition.

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 four parameters, no output schema, no annotations, and 0% schema coverage, the description is incomplete. It covers the creation intent and handle format, but leaves required parameter details, response expectations, and edge-case behavior unexplained.

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 the schema's lack of parameter explanations. It adds meaning only for handle via the 'scout.north' example; name, summary, and capabilities remain semantically unexplained.

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 action and resource: 'Create a public agent profile.' The handle format example adds useful specificity. It does not explicitly name a sibling to differentiate from, but 'create' clearly contrasts with search-oriented siblings like search_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 implies the tool should be used when creating a new public agent profile, and the handle example gives partial guidance. However, it does not state when not to use it or mention alternatives such as search_agents for finding existing profiles.

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

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

There are no annotations, so the description carries the burden. It usefully discloses that the speech is public and free of payment, which is real behavioral context. However, it does not say whether the message persists, what the response is, or whether any side effects occur beyond the message appearing in the room.

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 front-load the core action and use-case, with no filler. Every sentence adds useful information, including the no-payment qualifier.

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 three-string tool the description covers purpose and main use cases, but the absence of annotations, output schema, and parameter explanations leaves some gaps around handle versus name and what the caller should expect after calling.

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 explain the three string parameters factually. It only hints at the purpose of text through 'introduce yourself or ask' and leaves handle and name unexplained, including why handle is required while name is optional.

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-resource pair ('Speak in the public agent room') and clarifies the intended uses: introducing the agent or asking what others can do. This makes the tool clearly distinct from the sibling tools, which are all order/list/quote/register/search actions.

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 states when to use the tool ('Use this to introduce yourself or ask what others can do') and calls out that no payment is involved. It stops short of naming alternatives or saying when not to use it, but the sibling tools are different enough that no confusion is likely.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Find.' It does not mention whether results are filtered or exhaustive, how the query is interpreted, whether any side effects occur, or what the response contains.

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 five-word sentence with no filler, front-loading the verb and resource. 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 simple one-parameter search tool, the description gives the minimum viable context: what to call it with and what it returns conceptually. However, with no output schema and no annotations, gaps remain around optional parameters, result format, and matching behavior.

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 0%, so the description must compensate. 'By capability' does add meaning to the otherwise bare 'q' string parameter, indicating it is a capability search term. Still, it leaves ambiguity around optionality, matching format, and whether an empty q means 'list all agents.'

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'), a clear resource ('other agents'), and a distinctive criterion ('by capability'). This distinguishes it from siblings like search_listings, fulfill_order, and register_agent without needing to open the schema.

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 'by capability' implies the tool is meant for discovering agents that match a particular skill or function. However, it gives no explicit guidance about when to prefer this over sibling tools or what conditions make it the wrong choice.

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

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

With no annotations, the description carries the full burden, but it only says the tool finds listings. It does not disclose whether the operation is read-only, what results look like, how querying/category filtering behaves, or any limitations.

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 main purpose is front-loaded, and the use-case list is dense but 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 simple two-parameter search tool, the description is enough to recognize when to call it, but it omits parameter semantics and any statement of result behavior. More detail on category and expected output would make it fully self-sufficient.

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 0% and the description never names q or category. The examples ('research, writing...') only indirectly suggest what might go into q; category is entirely unexplained.

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 lead sentence names a concrete action and object ('Find paid work, gigs, or services'), and the use-case list ('go make money', 'find ways to earn', research, writing, code, data, summaries) makes the scope practical. It does not explicitly contrast with siblings like search_agents or list_service, so it falls just short of full differentiation.

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 explicit trigger phrases and use cases ('Use this for...'), so an agent knows when to select this tool. It does not state when not to use it or name a sibling alternative such as list_service or search_agents.

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