Skip to main content
Glama

Oakferry Agents

Get product

get_product
Read-onlyIdempotent

Full facts for one product: where to get it, every price, ratings with dates, features, attributes, when not to recommend it, third-party coverage and sources.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesProduct id from search_products

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/non-openWorld, so the safety profile is covered. The description adds real behavioral value by disclosing the return content, notably 'when not to recommend it' and 'third-party coverage and sources', which tells the agent this is a decision-support payload, not just a record fetch. It doesn't cover absence/error behavior, keeping it from a 5.

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 that names the resource first and then enumerates contents; each item earns its place as a signal of what the payload contains. The colon-list is dense but not padded.

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?

With no output schema, the description must carry return-value meaning and it largely does by listing the data categories returned. Gaps remain around response format, sourcing of 'third-party coverage', and failure behavior for an unknown id.

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?

One parameter at 100% schema coverage, and the schema already documents 'Product id from search_products'. The description adds no parameter-level detail (id format, casing, validation) so the baseline 3 for fully-covered schemas applies.

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 verb+resource ('full facts for one product') and enumerates exactly what is covered: prices, ratings with dates, features, attributes, negative-recommendation signals, coverage and sources. The singular 'one product' implicitly contrasts with search_products/compare_products, but no sibling is named, so it stops short of a 5.

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?

The description never says when to use this versus list_attributes, search_products or compare_products, nor when not to use it. The only routing hint ('Product id from search_products') lives in the schema, not the description, leaving the agent to infer the search-then-fetch workflow.

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