Skip to main content
Glama

Доставка: ID посылки по orderID [sandbox v1]

delivery_v1_get_registered_parcel_id
Read-onlyIdempotent

Fetch the registered test parcel ID linked to an order ID in the Avito delivery sandbox.

Instructions

[SANDBOX v1] ID зарегистрированной тестовой посылки по orderID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orderIDYes
Behavior4/5

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

Annotations declare readOnlyHint, destructiveHint, idempotentHint, providing safety profile. The description adds key context that it's a sandbox/test tool, which is critical behavioral information not in annotations.

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

Conciseness3/5

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

The description is very short and front-loaded, but overly minimal. It conveys the core purpose but lacks helpful detail like parameter hints or usage notes. A slightly expanded description would be more useful without being verbose.

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?

Given the tool's simplicity (1 param, read-only, idempotent), the description covers the basic purpose and sandbox context. However, the absence of an output schema and any return format description limits completeness; the agent doesn't know the response structure beyond 'ID'.

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 0%, so description must explain parameter 'orderID'. It only implies its role via the purpose, but provides no format, source, or examples. This is insufficient for a parameter with no schema description.

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 clearly states it retrieves a test parcel ID based on an order ID in the sandbox. It's specific and distinguishable from sibling tools like delivery_v1_get_parcel_info, but doesn't explicitly contrast them.

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 on when to use this tool versus alternatives like delivery_v1_get_parcel_info. No context on prerequisites or environment (sandbox) beyond the title and description.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/elchin92/avito-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server