Skip to main content
Glama
SamuelBalbas

tryton-stock-mcp

by SamuelBalbas

compare_products_stock_history

Compare stock movement histories across multiple product variants to identify differences and diagnose inventory issues.

Instructions

Compare movement histories for multiple product variants.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
product_idsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only states that histories are compared; it does not disclose whether the tool is read-only, what the comparison output looks like, how limit affects results, or any other behavioral traits beyond the name.

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 description is a single front-loaded sentence with no redundancy. It is concise and readable, though the brevity comes at the cost of important behavioral and parameter context.

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?

The tool has a simple flat parameter set and an output schema, so a minimal description can be adequate. Still, the description leaves gaps around output semantics and limit behavior that an agent would likely need to resolve before invoking the tool correctly.

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 description coverage is 0%, and the description does not compensate. 'Multiple product variants' loosely implies product_ids, but limit is entirely unexplained, and there is no clarification of ID format, array size expectations, or limit behavior.

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?

The description states a specific verb ('Compare') and resource ('movement histories') with a target ('multiple product variants'). It is reasonably distinguishable from single-product history siblings like audit_product_history, though it doesn't explicitly differentiate itself.

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?

There is no guidance on when to use this tool versus alternatives such as audit_product_history or get_product_detail. No exclusions, prerequisites, or selection criteria are provided, so an agent must infer usage from the name alone.

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