RelayDataAI

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

No annotations are provided, so the description carries the full behavioral burden. It does not explain the return shape, whether the operation is read-only beyond the obvious 'Get' verb, error behavior for unknown categories, or what 'Missing facts must remain unknown' means operationally.

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 first sentence is efficient and front-loaded. The second sentence, 'Missing facts must remain unknown,' is cryptic and does not clearly earn its place because it does not explain how the tool behaves or how to handle missing data.

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?

This is a read-style schema lookup with no annotations and no output schema. The description should compensate by explaining the category parameter semantics and return behavior, but it does neither. It is therefore incomplete for an agent that needs to call 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?

There is one required 'category' parameter with 0% schema description coverage. The description does not clarify whether the value should be a category ID, name, slug, or path, nor does it give examples or constraints. It adds almost no meaning beyond the parameter name.

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

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

The description clearly states a specific verb and resource: get category-specific fields. It also implies the purpose is pre-publish or pre-filter validation. It does not explicitly distinguish itself from list_categories, but the field-schema framing is meaningfully different from listing categories.

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 'before publishing or filtering' gives a concrete usage context, which is useful. However, it does not name alternatives or exclusions, such as when to use list_categories instead, and the second sentence does not clarify when-not-to-use behavior.

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 and no output schema, the description carries the full burden, and it only discloses that the read targets public (not private) listings. It says nothing about behavior on an unknown ID, whether authentication is required, or what a listing record 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?

A single front-loaded sentence with the resource and scoping constraint stated immediately and no filler. Nothing could be removed without losing meaning.

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

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

For a simple one-parameter lookup this is close, but with no annotations, no output schema, and zero schema description coverage, the definition should at least state invalid-ID behavior and roughly what is returned. As written, the agent knows the intent but not the contract.

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 single 'id' parameter is undocumented in the schema, so the description's phrase "stable ID" is the only semantic clue, indicating a persistent identifier rather than a transient one. It still omits format (slug, UUID, numeric) and source of the ID, leaving a real 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?

"Read one public listing by stable ID" gives a specific verb (read) and resource (a single public listing), which separates it from search_listings and my_listings by scope. It stops short of naming the sibling tools explicitly, so the differentiation is inferred rather than stated.

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?

"By stable ID" implies the caller must already hold an identifier, hinting that search_listings is the way to obtain one, but no explicit when-to-use or when-not-to-use guidance is given. The agent must infer the retrieval-before-fetch workflow.

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 must carry the full behavioral burden. It implies a read-only listing and adds that generic sectors are publishable/discoverable, but it does not state safety, authentication, pagination, return shape, or whether the list is filtered by user or workspace.

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

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

The description is short and front-loads the action in the first sentence. The second sentence adds relevant context about generic sectors, though it is somewhat vague and not strictly necessary for invoking a parameterless list tool.

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

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

For a simple zero-parameter list tool with no output schema, the description covers the basic action but leaves gaps: it does not explain what a 'sector' or 'admitted' means, what fields are returned, or how results relate to the listing tools. It is minimally adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there are no parameter semantics to document. The baseline for a parameterless schema is 4, and nothing in the description misrepresents the absence of inputs.

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

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

The description gives a clear verb and resource: 'List all admitted sectors.' It does not distinguish this tool from the sibling get_category_schema, and the switch from tool name 'categories' to description term 'sectors' adds minor ambiguity, but the core action is understandable.

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 no explicit guidance on when to use this tool versus get_category_schema or other sibling tools. The note that 'Generic sectors are fully publishable and discoverable' hints at relevance but does not state selection criteria or exclusions.

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 must carry the behavioral load; it usefully discloses that the operation is a read and that it requires an 'owner-authorised write API key', which is non-obvious. However, it says nothing about result size, pagination, ordering, or what a withdrawn/draft entry looks like in the response, leaving real gaps for a zero-param listing call.

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

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

Two short sentences, with the resource and scope front-loaded and the auth constraint following. No filler, no restatement 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?

For a zero-argument read with no output schema, the description covers what it returns in scope terms and the one gating requirement. Return shape and volume handling are left implicit, which is a minor gap given the tool's simplicity.

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 no parameters, so there is no parameter semantics to explain beyond what the empty schema already conveys. Baseline 4 applies; no compensating text was needed and none was provided.

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 your listings') and adds scope ('including drafts and withdrawn entries'), which meaningfully separates it from get_listing (single item) and search_listings (query-based). It stops short of naming those siblings, so differentiation is implied rather than explicit.

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 possessive 'your listings' implies this is for the caller's own inventory rather than a general search, but the description never says when to prefer it over search_listings or get_listing, and gives no exclusions or prerequisites beyond the key requirement.

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 supplied, the description carries the full burden and does disclose the key traits: an authorisation requirement (owner-authorised write API key), a legal attestation gate (attestRights=true), an ordering dependency (fetch category schema first), and a cost signal (publication is free). It omits idempotency, moderation/review latency, and failure behaviour, and does not reconcile "publish" with the schema's draft/withdrawn status values.

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?

Four short sentences, front-loaded with the action, then the authorisation gate, then the prerequisite, then the cost note. Every sentence adds a distinct operational fact and none repeats the schema.

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

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

For an 11-parameter, 6-required mutation with a nested open-ended attributes object, no annotations, and no output schema, the description is thin: an agent still cannot tell how attributes must be shaped, when to set status to draft versus published, or what a successful response looks like. The auth and ordering guidance is genuinely useful, but it does not cover the complexity of the call.

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% across 11 parameters, so the description must compensate, but it only touches attestRights (already fixed to const true in the schema) and indirectly category via the schema-first instruction. The meaning and constraints of name, summary, description, website, country, languages, tags, and especially the free-form nested attributes object are left entirely undocumented.

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?

"Publish an offer on behalf of its owner" names a specific verb (publish) and resource (offer/listing), and the sibling set makes the publish-vs-update_listing split inferable. It stops short of explicitly contrasting itself with update_listing or get_listing, so it is clear but not fully sibling-differentiated.

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?

Gives concrete preconditions: an owner-authorised write API key is required, attestRights must be true, and the category schema must be obtained first via get_category_schema. It does not say when NOT to use it (e.g. to edit an existing offer, use update_listing) or what happens on republish.

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 behavioral burden and does add real value by disclosing that results include provenance and confirmation dates and that owner assertions are not independently verified — an important trust caveat. However it says nothing about ordering, pagination behavior beyond the schema, default result size, whether an empty query returns everything, or rate/visibility constraints.

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 tightly written sentences, front-loaded with the search scope and followed by the result/trust caveat. No filler, no redundancy.

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 six-parameter search tool with a nested object, no annotations, and no output schema, the definition covers purpose and data trust but leaves parameter usage and result-shaping behavior entirely unexplained. An agent could not confidently construct a filtered or paginated query from this description alone.

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% across six parameters, including a nested free-form 'filters' object, and the description explains none of them — q, limit, offset, country, filters, category are all undocumented. The only indirect hint is the enumeration of entity types (products, services, providers), which loosely maps to the category/filters facets but 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?

The description uses a specific verb ('Search') with a well-scoped resource: public owner-declared and source-attributed imported products, services and providers. It is clearly distinguishable from sibling mutation tools (publish_listing, update_listing) and single-item retrieval (get_listing), though it never names those siblings to make the distinction explicit.

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 when-to-use or when-not-to-use guidance and no mention of alternatives such as list_categories or get_category_schema for browsing. The searchable domain is implied, but the agent must infer when to search versus browse or fetch a single listing.

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. 'Replace' implies a destructive overwrite, but the description does not state what gets destroyed, whether omitted fields are cleared, what permissions are required, or what the response looks like. The extra warnings about reconfirmation and dates are too ambiguous to compensate.

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

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

The description is short and front-loads the core action, but the second and third sentences are confusing and repetitive ('Reconfirm only after checking the actual information' / 'Do not refresh dates without an actual check'). They add ambiguity rather than clarity, though the overall length is reasonable.

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 13 parameters, 8 required fields, a nested object, no output schema, and no annotations, the description is severely incomplete. An agent cannot reliably invoke this tool based on the provided text alone; critical details about required fields, replacement semantics, and error conditions are 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 13 parameters with 0% schema description coverage. The description only contextualizes one parameter ('current expectedVersion') and provides no meaning for the other 12, including required fields like attestRights, category, name, summary, description, and website. It does not compensate for the schema's lack of descriptions.

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 says 'Replace your listing using its current expectedVersion', which identifies the verb (replace) and resource (listing) and hints at concurrency control. However, 'Reconfirm only after checking the actual information' and 'Do not refresh dates without an actual check' are vague and do not clarify whether this is a full replacement or partial update. It does not differentiate itself from siblings like get_listing or publish_listing.

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 offers only cryptic cautions ('reconfirm only after checking the actual information', 'do not refresh dates without an actual check') rather than clear when-to-use guidance. It does not tell the agent when to choose this tool over get_listing or publish_listing, nor does it explain prerequisites such as obtaining the current expectedVersion via a read.

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