Skip to main content
Glama

search_shop_policies_and_faqs

Used to get facts about the stores policies, products, or services. Some examples of questions you can ask are:

  • What is your return policy?

  • What is your shipping policy?

  • What is your phone number?

  • What are your hours of operation?" Set policy_types to also get the store's written policies (full text and URL).

Input Schema

NameRequiredDescriptionDefault
queryYesA natural language query.
contextNoAdditional information about the request such as user demographics, mood, location, or other relevant details that could help in tailoring the response appropriately.
policy_typesNoPolicy kinds to fetch, chosen from the user's question — e.g. ["refund"] for returns/exchanges/damaged items, ["contact"] for phone/hours/address. Include every kind the question touches. Omit it to get only FAQ answers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / policy_types
      Added value: +{
      +  "description": "Policy kinds to fetch, chosen from the user's question — e.g. [\"refund\"] for returns/exchanges/damaged items, [\"contact\"] for phone/hours/address. Include every kind the question touches. Omit it to get only FAQ answers.",
      +  "items": {
      +    "enum": [
      +      "refund",
      +      "shipping",
      +      "privacy",
      +      "terms_of_service",
      +      "terms_of_sale",
      +      "subscription",
      +      "legal_notice",
      +      "contact"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed1 schema field changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observed

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose a useful behavior — setting policy_types returns the store's written policies as full text plus URL, versus FAQ-only answers when omitted — which tells the agent how the response shape changes. It says nothing about permissions, rate limits, or result volume, leaving gaps for a tool with zero annotation coverage.

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?

The purpose is front-loaded in the first sentence, and the example list is compact enough to be genuinely useful rather than padding. The closing line about policy_types is a slightly abrupt pivot but earns its place by flagging a non-obvious behavior.

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

Completeness4/5

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

For a three-parameter search tool with no output schema and no annotations, the description covers what the tool does, what can be asked, and how policy_types alters the return. Nothing critical to correct invocation is missing, though guidance on combined policy_types usage or empty-result behavior would round it out.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already documents all three parameters and the baseline would be 3. The description adds meaning beyond that by explaining the behavioral effect of policy_types (retrieving full written policy text and a URL) rather than merely restating the enum, which is genuine added value.

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 specific action (get facts) against a specific resource (store policies, products, services), backed by four concrete example questions that make the scope unmistakable. No siblings exist to differentiate from, so the only thing keeping it from a 5 is the slight vagueness of 'facts' as the operative verb.

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

Usage Guidelines3/5

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

The example questions implicitly show the kind of request this tool serves (return policy, shipping, phone, hours), which is real guidance for a natural-language search tool. However, there is no explicit statement of when NOT to use it or which inputs select an alternative path, so usage is only implied.

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.