Skip to main content
Glama

catalogapi

by com.catalogapi

how_it_works

Answer questions about CatalogAPI itself: what it is, how rewards are delivered to recipients, how currencies and billing work, whether the catalog can be customized or extended with your own products, how the API integration works, and how to get started. Call this for any question about the service, the company, or the product model rather than about specific catalog items.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicYesWhich question to answer. overview: What CatalogAPI is and the two ways to use it. coverage: Which countries are covered and what a catalog contains. custom_catalogs: Sourcing items on request, and putting your own products in your catalog as a supplier. fulfillment: How each kind of reward reaches a recipient, and who supports it. pricing_and_billing: What catalog prices mean, what you charge your own users, how tax and shipping are handled (which depends on whether the program is points-based or a store where people spend their own money), and how billing and currency conversion work. integration: What integrating looks like, including the fulfillment-only path. getting_started: How to get sandbox access and what production involves.

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are present, so the description carries the burden. It makes clear this is an informational Q&A tool with no side effects. It does not explicitly state 'read-only' or describe return format, but these are implied by the nature of the tool and the topics listed.

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

Conciseness5/5

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

Two sentences: first states what the tool does, second gives usage guidance. No wasted words and the structure is front-loaded with purpose.

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

Completeness5/5

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

The tool is simple (one parameter) with a comprehensive schema. The description covers the tool's scope and contrasts with siblings. No output schema is needed since the return is a textual answer implied by 'answer questions.' The description is complete for the tool's complexity.

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

Parameters3/5

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

Schema coverage is 100% with highly detailed enum descriptions for the 'topic' parameter. The tool description summarizes some topics in natural language but does not add significant new meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states the tool answers questions about CatalogAPI itself, listing specific topics (rewards delivery, currencies/billing, customization, integration, getting started). It explicitly contrasts with siblings by saying 'rather than about specific catalog items.'

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

Usage Guidelines5/5

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

Explicit usage guidance is provided: 'Call this for any question about the service, the company, or the product model rather than about specific catalog items.' This directly tells when to use this tool versus siblings like check_coverage, get_reward_details, and search_rewards.

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

All catalogapi toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool addresses a distinct question: check_coverage for country availability, search_rewards for finding examples, get_reward_details for specific item info, and how_it_works for API/service details. The descriptions clearly delineate boundaries and cross-reference each other, so an agent would not confuse them.

Naming Consistency4/5

Three tools follow a clear verb_noun pattern (check_coverage, get_reward_details, search_rewards), but how_it_works is a phrase that breaks the pattern. This is a minor deviation that does not cause confusion.

Tool Count5/5

With 4 tools, the set is tightly scoped for a catalog API: search, details, coverage check, and service info. Each tool earns its place, and the count is ideal for the apparent purpose.

Completeness5/5

The tool set covers the full user journey: check if a country is supported, browse example rewards, request specific reward details, and learn how the service works. For a read-only demonstration catalog, there are no obvious gaps.

Resources