Yandex Delivery MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_PORT | No | Port for the MCP HTTP server | 3002 |
| YANDEX_DELIVERY_API_KEY | Yes | API key for Yandex Delivery |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
The tool set has several overlapping retrieval functions (e.g., get_claim_info, search_claims, get_bulk_info, get_claim_journal) and similar pricing tools (calculate_offers, check_price), which could confuse an agent without detailed descriptions. However, most tools are distinct actions on distinct resources.
All tool names use snake_case and follow a verb_noun pattern (get_tracking_links, create_claim, accept_claim, etc.), which is consistent and readable. The only minor inconsistency is mixing singular and plural nouns (claim vs. claims, info vs. journal).
With 21 tools, the server is slightly over the typical comfortable range but still reasonable for a comprehensive delivery management API covering claims, tracking, pricing, and delivery methods. Each tool appears to serve a distinct purpose, so the count is justified.
The tool surface covers the full claim lifecycle (create, edit, accept, cancel, return, search) and includes tracking, pricing, and delivery method operations, leaving few obvious gaps. Minor missing features like a dedicated 'delete' action are likely covered by cancel/return, so agents can achieve core workflows.