Nexez Agentic Commerce

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

The description implies a read-only browse operation, but with no annotations provided, it lacks details on behavior such as pagination, default limits, or result structure. The transparency is basic but not comprehensive.

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 sentence that efficiently conveys the core purpose and optional filters, with no redundant 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?

The description covers the basic usage but lacks information about output format, pagination, defaults, or behavior when multiple filters are combined. Without an output schema, more context would be helpful.

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, the description merely lists filter types (category, query, etc.) without adding meaning beyond parameter names. The enum for category provides limited semantics, but no details on formats or usage.

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 'Browse' and the resource 'cross-merchant Nexez directory,' along with optional filters. However, it does not differentiate from sibling tools like nexez_search or nexez_get_page, which could have overlapping functionality.

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 provided on when to use this tool versus alternatives. The description only mentions optional filtering but lacks context for selection among siblings like nexez_search or nexez_get_page.

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 provided, so description must disclose all behavioral traits. It states 'Fetch' (read-only) but omits any side effects, authentication needs, rate limits, or response format details.

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, but includes necessary elements. Could be structured with more context (e.g., what is an 'agent manifest'), but not excessively verbose.

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?

Tool has one parameter and no output schema. Description minimally explains inputs and outputs, but lacks details on response structure or potential errors. Adequate for simple getter.

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 100%, so description adds no extra meaning beyond the schema's 'Listing slug'. Baseline score of 3 applies as description does not improve parameter understanding.

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 states the verb 'Fetch' and resource 'listing's full structured agent manifest' with details on contents (seller profile, offers, actions). It is distinct from siblings, though no explicit differentiation is provided.

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 on when to use this tool versus alternatives (e.g., directory, search) or when not to use it. Usage context is implied only.

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?

The description discloses that results are ranked and include offers and agent.json URLs, but lacks details on authentication, rate limits, error behavior, or any potential side effects. With no annotations, this is a minimal but acceptable disclosure for a search tool.

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 focused sentence that concisely conveys the tool's main action, scope, and output 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?

Given the tool has 13 parameters and no output schema, the one-sentence description is insufficient. It lacks context on how to use the filters, what ranking means, the structure of returned data, and any limitations.

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

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

Schema description coverage is only 23%, yet the description adds no parameter-specific information beyond the schema. Important parameters like lat, lng, category, industry, verified, min_trust, etc., are left unexplained, failing to compensate for the schema's gaps.

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 searches across all Nexez merchants for matching services/products and returns ranked listings with offers and agent.json URLs. It uses a specific verb ('Search') and resource ('Nexez merchants'), and is distinct from sibling tools like nexez_directory or nexez_get_page.

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 explicit guidance on when to use this tool versus alternatives. While the purpose implies it is the primary search tool, there is no mention of when not to use it or which sibling tools might be more appropriate for specific tasks.

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?

Discloses key behavioral trait: 'Never charges' (safety guarantee). With no annotations provided, this is critical but insufficient. Does not mention authorization requirements, rate limits, or side effects beyond the dry-run nature.

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?

Single sentence, front-loaded with key action and constraints. No redundant words. Efficiently conveys purpose and safety.

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 three parameters, no output schema, and no annotations, the description is insufficient for full understanding. It omits return value hints (e.g., success/failure indicators), error conditions, and details on the slug parameter. The dry-run result structure is not described.

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% (two params documented), but the description adds no parameter-level detail. The required 'slug' parameter has no description in schema or description, leaving ambiguity. The description's mention of 'validates the offer' somewhat overlaps with the offer parameter but does not clarify format or constraints.

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?

Describes a specific action ('dry-run a checkout for an offer') with clear verb and resource. States what is validated (offer, currency, payment readiness) and explicitly notes it never charges. Differentiates from sibling validate_negotiation by focusing on checkout rather than negotiation.

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?

Implies usage 'BEFORE paying', providing timing context. However, no explicit guidance on when not to use or how it compares to alternative tools like nexez_validate_negotiation. The description lacks exclusion criteria or alternative suggestions.

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 full burden. It explicitly states 'Never writes', indicating read-only behavior. It also says 'Dry-run' and 'Returns the rules evaluation', but does not disclose potential side effects like logging or rate limits. Still, safety is well communicated.

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, front-loaded with the key action and purpose. Every word adds value. No redundancy or fluff.

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 provides a high-level purpose but lacks details on parameters, output, or edge cases. With 5 parameters and no output schema, the agent needs more information to use the tool correctly. The description is insufficient for contextual completeness.

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 5 parameters with 0% description coverage. The tool description does not explain any parameter (slug, offer, query, budget, timeline). This is a critical gap, as the agent cannot determine what each parameter means without further context.

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 performs a dry-run of a negotiation proposal against seller rules, with return of evaluation. It distinguishes itself from the sibling 'validate_checkout' by specifying 'negotiation' and explicitly says it is a pre-submission validation.

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 says to use this tool 'BEFORE submitting' and 'Never writes', providing clear usage context. It lacks explicit alternatives, but the purpose strongly implies when to use versus actual submission.

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