Skip to main content
Glama
Sign In
x5-mcp

x5-mcp

by DashinIN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

x5_get_receipt

Read-onlyIdempotent

Retrieve a single purchase receipt by ID, including up to 500 line items and the total item count. Use it to fetch receipt details for spending and product analysis.

Instructions

Один чек и до 500 его позиций; itemsCount показывает полное число позиций.

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": {
      "id": "<id>"
    },
    "name": "x5_get_receipt"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3.4/5.0
Behavior4/5

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

Beyond the readOnly and idempotent annotations, the description discloses a critical behavioral detail: at most 500 items are returned, while itemsCount carries the true total. This adds meaningful context that annotations do not provide.

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?

A single, front-loaded sentence with zero filler. Every word earns its place, and the key constraint (500-item limit) is presented immediately.

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 simple single-parameter read tool with strong annotations, the description is nearly sufficient: it conveys the return scope and pagination semantics. It omits error behavior or receipt-not-found handling, but these are not critical for such a straightforward retrieval.

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?

The schema has one required id with no description, and schema coverage is 0%. The description does not explain that id is the receipt identifier or any expected format, so it adds no parameter-level meaning; the tool name partially compensates but the description itself fails.

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 the tool returns one receipt with up to 500 line items, which clearly identifies the resource and distinguishes it from list-type siblings like recent receipts or search. However, it lacks an explicit verb and does not name sibling alternatives, so it stops short of a top score.

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 guidance is given on when to use this tool versus siblings such as x5_search_purchases or x5_get_recent_receipts. The intended use case (having a receipt ID) is only implied by the name and schema, not stated.

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

Deploy Server

Other Tools