find_offerings
Find products or services with published experiences. Identities are consumer-supplied and scoped to a merchant. Use next_cursor as after for pagination.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| after | No | ||
| merchant_id | No |
Find products or services with published experiences. Identities are consumer-supplied and scoped to a merchant. Use next_cursor as after for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| after | No | ||
| merchant_id | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context — that identities are consumer-supplied and scoped to a merchant — plus pagination behavior, but says nothing about result size, rate limits, or what an 'experience' actually is.
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, front-loaded with the purpose and with zero filler. The pagination note is placed last where it belongs, though the middle sentence about identities is dense and unexplained.
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, no annotations on returns, and 0% parameter coverage, the description should explain the return shape, what counts as a 'published experience', and how q filters. It does none of these, leaving an agent able to paginate but not to predict or constrain results.
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. It clarifies `after` (pass the returned next_cursor) and gestures at merchant_id via 'scoped to a merchant', but the `q` search parameter is never explained, leaving a third of the parameters undocumented anywhere.
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 verb 'Find' and resource 'products or services' give a workable purpose, but the qualifier 'with published experiences' is opaque domain jargon that the agent cannot decode from this description. It does not explicitly contrast itself with find_merchants or get_offering, so the boundary between the lookup siblings is left to inference.
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 guidance at all: nothing says whether this is the entry point before get_offering, or how it relates to find_merchants. The only instruction is a pagination mechanics note ('Use next_cursor as after'), which is parameter usage rather than selection guidance.
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.