Hand-picked gift ideas for home offices that assistants turn into shareable wishlists fast. SE + US.
Scored across 8 tools
Most tools target a distinct resource+action, but three pairs overlap: create_and_fill vs create_desk_board+add_desk_item, get_catalog vs search_desk_gear, and resolve_product vs search_desk_gear. Descriptions explicitly steer agents ("Prefer create_and_fill for one-shot", "Prefer search_desk_gear for discovery"), so misselection is unlikely though not impossible.
All eight tools follow a strict verb_noun snake_case pattern (add_desk_item, create_desk_board, get_catalog, search_desk_gear, resolve_product, get_health). No mixed conventions or casing deviations.
Eight tools is well within the ideal 3-15 range and each maps to a real step in the wishlist workflow (create, populate, retrieve, discover, resolve, health). No obviously redundant or filler tool beyond the intentional create_and_fill shortcut.
Creation, population, retrieval, discovery, and resolution are covered, but there is no remove/delete item, no update or delete board, and no list-boards-for-owner operation. These lifecycle gaps will block agents that need to correct a board or clean up after themselves.
Add an item to a desk board. Requires editToken from create. Body: name/title plus asin, url (pasted /dp), searchKeywords, or catalogId. Token storage may return a new id — update bookmarks. OpenAPI: addWishlistItem.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Desk board id | |
| url | No | ||
| asin | No | ||
| name | No | ||
| emoji | No | ||
| title | No | ||
| catalogId | No | ||
| editToken | Yes | X-Edit-Token from create/mutate response | |
| searchKeywords | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and openWorldHint=true; the description adds real value on top by disclosing the editToken authorization requirement and the non-obvious side effect that token storage may return a new id, forcing bookmark updates. It stops short of describing failure modes (e.g., stale token, duplicate item) or the response shape.
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 dense sentences, front-loaded with the action and the prerequisite, with no filler. The telegraphic 'name/title plus ...' phrasing is compressed to the edge of ambiguity, and the OpenAPI mapping is minor but useful cross-reference.
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 9-parameter mutating tool with no output schema and sparse schema descriptions, the definition covers the essentials but leaves gaps: one parameter is undocumented, there is no indication of what a successful call returns beyond a possible new id, and no error behavior. Adequate to invoke, not 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?
Schema coverage is only 22%, so the description must compensate, and it does: it names the body fields (name/title, asin, url, searchKeywords, catalogId), gives a format hint for url ('pasted /dp'), and explains where editToken comes from. Gaps remain — 'emoji' is never mentioned and the semantics of searchKeywords (fallback resolution?) are unstated.
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 ('Add an item to a desk board') and enumerates the identification fields that make up the body, so an agent knows this appends a single item to an existing board. It is distinguishable from read-side siblings like get_desk_board or resolve_product, though it never clarifies its boundary against create_and_fill, which plausibly also adds items.
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?
'Requires editToken from create' gives a hard prerequisite and 'asin, url (pasted /dp), searchKeywords, or catalogId' implies the agent should supply one identifying field. However, there is no explicit statement of when to pick this over create_and_fill, nor whether the identifier fields are mutually exclusive or prioritized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One call: create a curated home office setup gift wishlist and return shopUrl (share link) + ownerUrl. Preferred agent path: create a desk board and add ASINs / keywords / search queries in one call. Pass marketplace + locale + role + budgetBand. Returns id, editToken, ownerUrl, shopUrl. OpenAPI: agentCreateAndFill.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| locale | No | User locale, e.g. en, sv, de, fr, es, en-US | |
| deskName | No | ||
| itemAsins | No | ||
| budgetBand | No | ||
| personName | No | ||
| itemQueries | No | Each query is searched and added as a desk item | |
| marketplace | No | Amazon storefront domain or id for the end user, e.g. amazon.se, amazon.com, se, de. REQUIRED — pass the user's storefront; curated ASINs only produce /dp links when trusted for that marketplace. | |
| itemKeywords | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint=false and openWorldHint=true, so mutation and external reach are covered. The description adds useful return shape (id, editToken, ownerUrl, shopUrl) and the share-link nature of shopUrl, but says nothing about auth/permission requirements, whether the link is publicly accessible, or what happens on an untrusted marketplace.
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?
Short and front-loaded, with the one-call value proposition first. Minor waste from restating the return values twice ('shopUrl (share link) + ownerUrl' then 'id, editToken, ownerUrl, shopUrl') and from the bare 'OpenAPI: agentCreateAndFill' tag.
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 usefully enumerates return fields, which is appropriate. But for a zero-required-parameter, nine-param write tool with open-world reach, it omits what an empty call produces, minimum viable input, and error handling for marketplace/ASIN mismatches.
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 33% schema description coverage the description does carry real weight: it names marketplace, locale, role, budgetBand and the three item-input families (ASINs / keywords / search queries), covering roughly seven of nine parameters. It never explains deskName, personName, or how itemAsins vs itemKeywords vs itemQueries interact (precedence, mixing, or whether any is required), so it only partly compensates.
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 composite resource ('one call: create ... and return shopUrl + ownerUrl') and explicitly positions itself as the 'preferred agent path' that fuses create_desk_board with add_desk_item. The one flaw is terminological drift: the same artifact is called a 'gift wishlist' and a 'desk board' in adjacent sentences, leaving a small ambiguity about what is actually created.
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?
'Preferred agent path: create a desk board and add ASINs / keywords / search queries in one call' tells the agent clearly when to use this instead of the multi-call route, without naming create_desk_board or add_desk_item explicitly. No when-not-to-use condition or prerequisite (auth, marketplace trust) is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a home-office desk board (wishlist). Returns id, editToken, ownerUrl, shopUrl, wishlist, storage. Save editToken for add_desk_item. Prefer create_and_fill for one-shot. OpenAPI: createWishlist.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| items | No | ||
| locale | No | User locale, e.g. en, sv, de, fr, es, en-US | |
| deskName | No | ||
| budgetBand | No | ||
| personName | No | ||
| marketplace | No | Amazon storefront domain or id for the end user, e.g. amazon.se, amazon.com, se, de. REQUIRED — pass the user's storefront; curated ASINs only produce /dp links when trusted for that marketplace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and openWorldHint=true, so the description adds real value: it enumerates the return fields (id, editToken, ownerUrl, shopUrl, wishlist, storage) and warns that editToken must be retained for add_desk_item. It does not state whether an empty board is valid, or what auth/limits apply, so it is not complete.
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 what the tool does, then return values, then the routing hint. Telegraphic phrasing ('OpenAPI: createWishlist') is slightly cryptic but costs no space.
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, listing the return fields is the right compensatory move and it does so. However, for a seven-parameter create tool with 29% schema coverage and no annotations covering behavior beyond mutation, the description leaves too much of the input contract unexplained to be considered 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?
Schema description coverage is only 29%, so the description needs to compensate — instead it mentions no parameters at all beyond the passing notion of a board. The seven inputs (role, items, locale, deskName, budgetBand, personName, marketplace) are undocumented here, and the schema leaves six of them unexplained. This is a clear gap given the low coverage.
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 — 'Create a home-office desk board (wishlist)' — and even reconciles the internal naming by equating desk board with wishlist. It names the sibling create_and_fill so the agent can distinguish this from the one-shot variant without opening another 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?
'Prefer create_and_fill for one-shot' gives an explicit alternative and the condition that selects it, and 'Save editToken for add_desk_item' implies the multi-step workflow this tool is for. It stops short of saying when you would create a board with no follow-up, but the usage signal is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paginated curated desk starters (~51). Prefer search_desk_gear for discovery. ALWAYS pass marketplace + locale. Filter by role + budgetBand. OpenAPI: getCatalog.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Full-text filter | |
| role | No | ||
| limit | No | ||
| locale | Yes | User locale, e.g. en, sv, de, fr, es, en-US | |
| offset | No | ||
| category | No | ||
| budgetBand | No | ||
| marketplace | Yes | Amazon storefront domain or id for the end user, e.g. amazon.se, amazon.com, se, de. REQUIRED — pass the user's storefront; curated ASINs only produce /dp links when trusted for that marketplace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the approximate catalog size (~51) and pagination, but says nothing about empty results, ordering, or why the marketplace must be trusted. Also, 'OpenAPI: getCatalog' is an internal reference rather than behavioral context.
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 with the what, the alternative, the required params and the filters, all front-loaded. The trailing OpenAPI reference is the only low-value element.
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 and low parameter coverage, the description should explain what a returned 'desk starter' actually looks like (products? ASINs? bundles?) or list which fields the filters apply to. It covers routing and required params but leaves the return shape and pagination behaviour 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 only 38% across 8 parameters, so the description should carry more weight. It mentions role, budgetBand, marketplace and locale, but leaves 'category', 'limit' and 'offset' semantics to the schema (offset/limit are only hinted by 'Paginated'), and adds no meaning beyond the enum values already present.
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 names a concrete resource ('curated desk starters (~51)') and its paginated shape, which tells an agent what it gets back. It lacks a clear verb (list/get) and the term 'desk starters' is domain jargon, but the size hint makes the scope unambiguous enough to act on.
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?
'Prefer search_desk_gear for discovery' explicitly names the sibling alternative and the condition that selects it, and 'ALWAYS pass marketplace + locale' is a hard usage rule. It stops short of saying when the curated catalog itself is the right choice over search, but the routing signal is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a desk board by id. Returns items with buy links when available, plus ownerUrl and shopUrl. OpenAPI: getWishlist.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Board id (short Redis id or t.* token) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful return context: items with buy links when available, plus ownerUrl and shopUrl, which matters because there is no output schema.
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 compact sentences with the purpose front-loaded and no filler. The 'OpenAPI: getWishlist' note is minor provenance rather than agent-critical guidance, but it does not harm readability.
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 read-only tool with full schema coverage and annotations, the definition is largely complete and summarizes the return shape. It could mention pagination or error behavior, but those are minor omissions for this tool.
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 only parameter is id, and the schema describes it fully as a board id using either a short Redis id or t.* token. The description only repeats 'by id' and adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
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 and resource: fetch a desk board by id. It clearly distinguishes this from creation siblings like create_desk_board and add_desk_item, though it does not explicitly contrast with search_desk_gear.
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 by 'by id'; there is no explicit guidance on when to use this versus search_desk_gear or other retrieval tools. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check for Home Office Builder. Returns ok, storage, paapi, trackingTag, tagConfigured, domain, catalogCount. tagConfigured is false until real Associates IDs are set (links omit tag=). OpenAPI: getHealth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavior beyond annotations by listing return fields and explaining that tagConfigured is false until real Associates IDs are set, causing links to omit tag=. It does not contradict the 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 short and front-loaded with the primary purpose. The return-field list and tagConfigured caveat both earn their place, and the final OpenAPI reference is compact. There is no unnecessary repetition.
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 parameters, no output schema, and read-only/open-world annotations, the description is nearly complete for calling the tool. It lists the returned fields and explains the most important caveat, though it does not define the meaning or possible values of fields like ok, storage, or paapi.
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 is no parameter semantics to clarify and the baseline is 4. The description correctly focuses on return values rather than inventing parameter details.
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 purpose: a health check for Home Office Builder. It is clearly distinguishable from all listed siblings, which are catalog, board, desk, product, and search operations. It also names the exact status fields returned, making the tool's role concrete.
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 the tool is used for diagnostics/status checks, but it does not explicitly say when to call it, when not to call it, or which alternatives to use. The usage is inferable from 'health check' and the returned status fields, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an ASIN, pasted Amazon /dp/ URL, or keywords to an buyUrl (product /dp or desk search). ALWAYS pass marketplace + locale. Does not invent tracking tags — when unset, URLs omit tag= and tagConfigured is false. OpenAPI: resolveProduct.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Pasted Amazon product URL | |
| asin | No | 10-char Amazon ASIN | |
| role | No | ||
| locale | Yes | User locale, e.g. en, sv, de, fr, es, en-US | |
| keywords | No | Search keywords if no ASIN | |
| budgetBand | No | ||
| marketplace | Yes | Amazon storefront domain or id for the end user, e.g. amazon.se, amazon.com, se, de. REQUIRED — pass the user's storefront; curated ASINs only produce /dp links when trusted for that marketplace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and openWorld, so the safety profile is covered. The description adds genuine behavioral context beyond that: it will not fabricate tracking tags, unset tags yield URLs without tag= and tagConfigured=false. It doesn't say what happens on failed resolution, which keeps it at 4.
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 tight sentences, front-loaded with the capability and the critical constraint, followed by the tracking-tag caveat and the OpenAPI alias. Minor typo ('an buyUrl') and the OpenAPI pointer is filler, but nothing bloats it.
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 responsibly names the return fields (buyUrl, tagConfigured) and the two output modes. It leaves unspecified what desk-search results look like and what failure/empty resolution returns, which is the main remaining gap for a 7-parameter tool.
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 71%, and the description reinforces the two required parameters with an emphasis the schema lacks ('ALWAYS pass'), plus explains that marketplace gates whether curated ASINs produce /dp links. role and budgetBand are left to their self-describing enums.
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 ('Resolve') and enumerates the three accepted input forms (ASIN, pasted /dp/ URL, keywords) plus the output shape (buyUrl as /dp link or desk search). It does not explicitly contrast with siblings like get_catalog or search_desk_gear, so an agent must infer the 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?
It gives a hard usage rule — 'ALWAYS pass marketplace + locale' — and implicitly scopes usage to cases where the agent has an ASIN, URL, or keywords. There is no explicit 'use X instead' routing against sibling tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Amazon for home-office desk gear on the user's marketplace. Filter by role + budgetBand. Returns PA-API products when configured, otherwise desk-setup search deep-link cards + catalogMatches. ALWAYS pass marketplace + locale. Amazon URLs omit tag= until tagConfigured is true. OpenAPI: searchAmazon.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query, e.g. monitor arm | |
| role | No | developer | designer | student | general | |
| limit | No | ||
| locale | Yes | User locale, e.g. en, sv, de, fr, es, en-US | |
| budgetBand | No | under-500 | 500-1500 | 1500-4000 | 4000-plus | |
| marketplace | Yes | Amazon storefront domain or id for the end user, e.g. amazon.se, amazon.com, se, de. REQUIRED — pass the user's storefront; curated ASINs only produce /dp links when trusted for that marketplace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely non-obvious behavior — a PA-API path with a fallback to deep-link cards plus catalogMatches, and the quirk that Amazon URLs omit tag= until tagConfigured is true. It stops short of covering failures, rate limits, or empty-result handling.
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, purpose front-loaded, zero filler. The trailing 'OpenAPI: searchAmazon' and internal jargon (PA-API, catalogMatches, tagConfigured) are dense but each carries information an agent needs.
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 six parameters and no output schema, the description carries the return-shape burden and does so by naming both result modes (products vs. deep-link cards + catalogMatches). Only failure behavior and result-count/pagination expectations 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 coverage is 83% so the baseline is 3, but the description adds real meaning on top: role and budgetBand are framed as a paired filter, and marketplace/locale are flagged as mandatory for correct output. It doesn't clarify limit semantics or how role changes ranking.
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 ('Search Amazon'), a concrete resource ('home-office desk gear'), and the scope (the user's marketplace). It is trivially distinguishable from siblings like resolve_product, get_catalog, and add_desk_item, and it even maps itself to the underlying OpenAPI operation.
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?
Offers directive guidance ('ALWAYS pass marketplace + locale', 'Filter by role + budgetBand') but never states when to prefer this over resolve_product or get_catalog, nor any exclusion conditions. Usage must be inferred from the purpose sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_desk_itemcreate_and_fillcreate_desk_boardget_catalogget_desk_boardget_healthresolve_productsearch_desk_gearHand-picked gift ideas for birthdays that assistants turn into shareable wishlists fast. SE + US.
Hand-picked gift ideas for dinner hosts that assistants turn into shareable wishlists fast. SE + US.
Hand-picked gift ideas for weddings that assistants turn into shareable wishlists fast. SE + US.
Hand-picked gift ideas for gamers that assistants turn into shareable wishlists fast. SE + US.
Add one secure layer between your agents and this server.