get_offersQueries the configured commerce provider and returns only outbound offers with attributable URLs. It never purchases.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| tool | Yes | ||
| facts | Yes | ||
| status | Yes | ||
| warnings | Yes | ||
| requestId | Yes | ||
| confidence | Yes | ||
| provenance | Yes | ||
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation set already notes idempotentHint=true and destructiveHint=false. The description adds meaningful behavioral context by stating it 'never purchases' and emphasizes that it only queries/queries, which is reassuring for agents and clarifies that this tool will not trigger financial side effects. There is 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 two short sentences with no wasted words. The primary action and scope are front-loaded, and the critical safety reassurance ('It never purchases.') is placed at the end without bloat.
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 simple schema, presence of an output schema, and helpful annotations, this description is mostly complete: it identifies the resource, scope, and a key non-behavior. It only falls short in not elaborating on parameter semantics or alternatives, but those are separately scored dimensions and the tool is simple enough to operate with reasonable inference.
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 full burden for parameter semantics, but it does not explain what the `query` string should contain or how `limit` behaves beyond the schema. The agent must infer from parameter names, which is risky for a commerce-provider query.
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 ('Queries') and resource ('configured commerce provider') and precisely scopes the output: only outbound offers with attributable URLs. It also clarifies that the tool never purchases, which differentiates it from any commerce action and makes 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 implies when to use this tool: when you need attributable outbound offers from the configured provider. However, it gives no explicit guidance about when not to use it or how it compares to sibling tools such as search_parts or get_product, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct capability: exact product retrieval, search, pairwise compatibility, fit guidance, offer lookup, generation-family listing, and problem resolution. The closest pair (get_compatibility and get_fit_guidance) is separated by interface matching vs. manufacturing compensation and physical-test warnings.
All tool names are lowercase snake_case with a clear verb-object form: get_*, list_*, search_*, resolve_*. There are no mixed naming conventions or vague generic verbs.
Seven tools is well-scoped for a parts decision-support server. Each tool covers a distinct operation without redundancy, and the count is neither thin nor bloated.
The surface covers core lookup, search, compatibility, fit, offer, generation-option, and problem-resolution workflows well. The only minor gap is that generation options are listed but not expanded into detailed generation variants, so an agent may need to work around that via resolve_problem.