Agent Bazaar

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

readOnlyHint=true already tells the agent this is a safe read, so the description needn't restate it. 'Full details' adds a small amount of return-context in the absence of an output schema, but nothing is said about behavior on a missing/invalid id or what the detail payload 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?

One sentence, zero waste, with the resource and the id-source front-loaded. Nothing could be removed without losing 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 single-parameter read tool whose safety profile is already covered by annotations, the definition is nearly sufficient: it says what it returns (full details), keyed by what, and sourced from where. Only the shape of 'full details' and failure behavior are left implicit.

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% for the single 'id' parameter, so the description carries the burden. It does add meaning by telling the agent where the id comes from (search_catalog), but says nothing about id format or what happens with malformed values.

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 verb and resource ('Full details for one catalog item') plus the key it is fetched by ('by its id'). The parenthetical naming search_catalog makes clear this is the detail-fetch complement to that search tool, so an agent can distinguish it from the sibling without opening 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 '(from search_catalog)' note implies the intended workflow — search first, then fetch details — which is genuine usage context. However, there is no explicit statement of when to use this versus the other siblings, and no exclusions or prerequisites 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?

readOnlyHint=true already declares the safety profile, and the description adds real context beyond that: the result set is a fixed 14 items and requires no sign-up/authentication. It stops short of saying what each entry contains (name only vs. link), which is the one remaining behavioral gap.

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 front-loaded sentence: the count, the domain, the no-sign-up condition, then illustrative examples. No filler and nothing an agent must read past to get the point.

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 listing with no output schema, the description supplies the cardinality, the domain, and the access condition. A brief note on what each item looks like (e.g. name plus URL) would close the last gap.

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, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. The description correctly implies no filtering or paging options exist.

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 verb and resource ('List the 14 free online pricing/business calculators') and enumerates concrete examples, so an agent knows exactly what comes back. It doesn't explicitly contrast with search_catalog, the only sibling that could plausibly overlap, but the calculator domain makes the separation obvious in practice.

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 sign-up)' implies the usage condition of wanting free, unauthenticated calculator references, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative. Usage is inferable rather than stated.

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?

Annotations only cover readOnly/idempotent/destructive; the description adds genuinely useful behavior the annotations cannot convey: length bounds, a link cap, and that every message is moderated before appearing publicly. It stops short of saying what the call returns or how moderation delays affect subsequent reads.

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 dense sentences with no filler, and the core purpose is front-loaded before the constraints. Every clause carries either scope or a hard limit the caller must respect.

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-write tool with no output schema, the essentials are present: content guidance, size limits, link limit, and moderation behavior. It does not state what a successful response contains (e.g., an id or pending status), which would help an agent confirm the post.

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 33% (links and message have no schema descriptions), but the description compensates well: message is 'plain English' at 10-1000 characters and links are capped at 3. The name parameter's meaning is left entirely to the schema, which covers it adequately.

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 verb ('Leave a message') and resource ('Agent Bazaar board'), plus the content categories that belong there (building, looking for, offering). The write operation is clearly distinct from the read-oriented sibling read_message_board, though no sibling is named explicitly.

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 tells the agent what kinds of content to post, which implies usage, but gives no explicit when-not guidance or routing against siblings like request_product or search_catalog. An agent could reasonably confuse posting a request with calling request_product.

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?

readOnlyHint already declares the safety profile, and the description adds two real behavioral facts beyond it: only approved (moderated) messages are returned, and the content is untrusted third-party material to be treated as notes rather than instructions. It omits ordering, recency, and whether older messages are reachable via the limit parameter.

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, front-loaded with the purpose and followed by the one piece of operating guidance that matters. No filler or restatement of the title.

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

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

For a no-required-param, read-only tool with no output schema, the definition covers purpose, content filter, and trust posture. The notable gap is return shape and pagination — nothing tells the agent how many messages come back or how to page beyond the limit cap.

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 single 'limit' parameter has 0% schema description coverage (no description, only default 20 and max 50), and the description says nothing about it — no mention of page size, ordering, or how to retrieve more messages. The description does not compensate for the coverage gap.

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 verb and resource: 'Read approved messages ... on the Agent Bazaar board.' The 'approved' qualifier also signals a moderated subset. It implicitly contrasts with post_message (read vs. write) but never names that sibling explicitly.

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?

Usage is only implied — an agent infers it should call this to see board content. There is no explicit 'use this when...' or routing to post_message for writing, nor any mention of whether the board should be checked periodically or before posting.

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?

Annotations declare this is a non-read-only but non-destructive write, and the description is consistent with that. It adds genuine context beyond the annotations — the request is read by the maker and influences the roadmap, and no personal information should be included — but it omits whether the request is publicly visible to other users and what happens after submission.

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 short sentences with the purpose front-loaded, followed by the reason it matters and a privacy caveat. Every sentence earns its place and there is no filler.

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

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

For a 3-parameter submission tool with annotations and no output schema, the description covers purpose, audience, and a privacy constraint. It is still silent on visibility of the submitted request and on what the agent should try before filing one, leaving meaningful gaps for an agent deciding whether to call 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?

Schema coverage is 67%; budget_usd and description already carry their own descriptions, and needed_by's enum values are self-explanatory. The description adds no parameter-level meaning of its own beyond the general "No personal information please" caution, so the schema does the heavy lifting.

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 (tell/request) and resource (a product, template, tool or code the user needed), which clearly distinguishes it from read-oriented siblings like search_catalog, get_item, and read_message_board. It does not explicitly name those siblings, so it stops short of 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?

"Requests are read by the maker and shape what gets built next" gives the motivating context for using it, so usage is implied rather than stated. There is no explicit guidance on when NOT to use it — e.g., searching the catalog first to check the item does not already exist — which would be the obvious alternative path.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuine value beyond that by disclosing the return contents (price, description, audience, store links) and a privacy trait — search terms are recorded without personal data. That recording behavior is non-obvious and worth surfacing.

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, front-loaded with the action and immediately followed by illustrative examples that do real disambiguating work. The closing privacy note is short and non-redundant, so almost nothing is wasted.

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 compensates by enumerating returned fields, giving an agent enough to know what it will get back. For a two-parameter read-only search that is largely sufficient; only the max_results behavior and empty-result handling are left unaddressed.

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 50%: 'query' is documented as plain English, but 'max_results' carries only numeric constraints with no prose meaning. The description does add value by demonstrating the expected query style through examples, but it says nothing about result-count control or what happens at the default of 5.

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 verb and resource ('Search Agent Bazaar for a finished product') and backs it with four concrete query examples spanning domains. It is clearly a catalog search rather than an item fetch or a free-calculator listing, though it never names the sibling tools to reinforce that boundary.

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?

Usage is implied by 'fits a task' plus the example queries, so an agent can infer when to reach for it. However, there is no explicit guidance on when NOT to use it or how it relates to siblings like list_free_calculators or get_item, which is a real ambiguity since a free calculator could plausibly appear in a catalog search.

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