Skip to main content
Glama

Cosmic Good Boy shop

Product facts

get_product
Read-onlyIdempotent

Facts about one product: price, colours, sizes, materials, description, stock, link, image.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "get_product"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoShop language for names, copy and linksen
slugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's contribution is the field enumeration, which stands in for a missing output schema, but it says nothing about behavior on unknown slug, missing language, or partially-available data.

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?

A single front-loaded sentence with zero filler, and the field list is the most useful thing to lead with given there is no output schema. It reads as a fragment rather than a framed sentence, but nothing is wasted.

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?

For a two-parameter read-only lookup with no output schema, listing the returned fields covers the main gap. Missing is any hint about how the required slug is obtained or identified, and what happens when the product isn't found.

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?

Schema coverage is 50% and the required 'slug' parameter has no schema description at all; the description never mentions slug or lang, so it does not compensate. It also fails to note that lang changes names, copy and links in the returned 'link'/'image' fields, which would have been a valuable addition.

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

Purpose3/5

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

The description names the resource ('one product') and enumerates the fields returned, so an agent knows this is a single-product lookup. However it has no verb and gives no differentiation from siblings like product_link, size_guide, or delivery_estimate, which plausibly overlap with 'link' and 'sizes'.

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?

No when-to-use guidance is present: nothing says 'use this to render a product page' or 'use product_link for just the URL'. The agent must infer from siblings alone that this is the general-purpose lookup.

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