Skip to main content
Glama

New Mum Gifts – hand-picked gift ideas

Search new mum gifts

search_gifts
Read-only

Search Amazon for new mum / postpartum gifts on the user's marketplace. ALWAYS pass marketplace + locale. OpenAPI: searchAmazon.

Input Schema

NameRequiredDescriptionDefault
qYesSearch query, e.g. cheese board
limitNo
localeYesUser locale, e.g. en, sv, de, fr, es
occasionNo
marketplaceYesAmazon storefront domain or id for the end user, e.g. amazon.se, amazon.com, se, de. REQUIRED.
dietaryNotesNoComma-separated dietary notes
giftCategoryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network scope are covered. The description usefully adds that results come from the user's specific marketplace, but says nothing about result shape, pagination via limit, or how heterogeneous Amazon results are filtered to the gift domain.

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

Conciseness4/5

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

Two sentences, purpose front-loaded, no filler. The trailing "OpenAPI: searchAmazon" is an implementation routing artifact that doesn't help an agent decide or invoke, but it costs little.

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

Completeness3/5

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

Seven parameters, two enums, and no output schema, yet the description never indicates what a result contains (product ids? prices?) or that results are meant to feed resolve_product or add_wishlist_item. Adequate to call the tool, thin for using the output downstream.

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

Parameters2/5

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

The marketplace/locale emphasis merely restates what the schema already documents (including "REQUIRED") at 57% coverage. Nothing is said about how occasion or giftCategory enums interact with q, what dietaryNotes expects from the agent, or how limit caps results, leaving several parameters explained only by bare enum values.

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

Purpose4/5

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

States a concrete verb and resource scoped to a category: "Search Amazon for new mum / postpartum gifts on the user's marketplace." No sibling in the list performs a query-style search (get_catalog and resolve_product are lookups), so the tool is distinguishable, but the description never names those siblings to make the boundary explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"ALWAYS pass marketplace + locale" is a parameter requirement, not usage guidance. There is no statement of when to choose this over get_catalog or resolve_product, nor any when-not condition or prerequisite context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources