delovye-linii-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation4/5
Each tool targets a distinct operation: calculate pricing, track shipments, search terminals, create orders, view history, and search cities. There is minor overlap potential between calculate (rate/schedule) and create_order (which may imply cost negotiation), and get_order_history vs track could overlap conceptually but generally serve different query types. Overall boundaries are clear enough for an agent.
Naming Consistency4/5
Most tools follow a clean verb_noun pattern: calculate, get_terminals, create_order, get_order_history, get_cities. Only 'track' deviates as a bare verb rather than verb_noun (e.g. track_order or get_tracking). This is a minor inconsistency but otherwise the naming is predictable and readable.
Tool Count5/5
Six tools is a well-scoped set for a logistics/courier MCP server covering the major user journeys: quoting, booking, tracking, and reference lookups. Each tool clearly earns its place, and the count feels appropriate for the domain.
Completeness4/5
The surface covers core workflows well: city lookup, terminal lookup, pricing, order creation, order tracking, and order history. Obvious gaps include the ability to cancel or update an order, and there is no document/label generation for shipping, though these are secondary for a courier integration. Core lifecycle is otherwise present.
Average 2.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It does not state the tool is a write/mutation action, any pricing/quote implications, whether addresses vs terminal pickups are mutually exclusive, limits, or what happens on success/failure. It adds only the carrier context (Business Lines).
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 extremely short (one sentence). While concise, it undersells a complex 16-parameter mutation tool. This is under-specification rather than effective conciseness, though it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter mutation tool with no annotations and no output schema, the description should explain dimensions like the sender/receiver terminal-vs-address relationship (mutually exclusive?), quantity defaulting, and expected outcome. None of this is covered. The tool is more complex than the single-sentence description acknowledges.
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?
Schema description coverage is 100%, so the schema already documents all 16 parameters. The description adds no parameter-level semantics beyond what's in the schema. Per rubric, baseline is 3 when coverage is high, and the description doesn't compensate, so 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Creating a cargo transportation order in Business Lines' — a specific verb (create) plus resource (order) plus context (Business Lines). However, it does not distinguish itself from siblings like track, calculate, or get_order_history, which are clearly separate functions but no differentiation of scope or relationship is given.
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 vs alternatives. No mention that city IDs and terminal IDs must be fetched first via get_cities/get_terminals. No mention of prerequisites or workflow order, which matters since required sender/receiver city_ids suggest prior lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of behavioral disclosure. The description doesn't state whether this is a read-only operation, what pagination behavior exists, whether date filters are required or optional, or what the response format looks like. For a tool with no annotation coverage, this is a significant gap.
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 a single short sentence, which is concise. However, it's under-specified rather than appropriately concise - a one-line description that only states the basic purpose doesn't earn high marks for efficient communication since it omits essential behavioral and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must compensate but doesn't. It's a read-oriented tool (implied by 'history') but provides no pagination details, date range semantics, or expected response information. For a retrieval tool with date parameter support and no annotation coverage, this is incomplete.
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?
Schema description coverage is 100%, so the schema already documents all three parameters (page, date_to, date_from) with Russian descriptions. The description adds no parameter-level information beyond what the schema provides. The baseline of 3 applies since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Получение истории заказов Деловых Линий' (Getting order history of Business Lines), which identifies the verb (получение/getting) and resource (история заказов/order history). However, it doesn't differentiate this from siblings like track or create_order beyond the obvious history purpose, and it's quite minimal.
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 provided about when to use this tool vs alternatives. Siblings like track, calculate, and create_order exist but the description gives no context on when order history is appropriate versus tracking a single order. There's no exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of behavioral disclosure. It mentions it's a reference/directory search (implying read-only), but doesn't state whether partial matches are supported, case sensitivity, language handling, pagination, or response format. For a lookup tool it's minimally descriptive but leaves significant behavioral unknowns unaddressed.
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 concise sentence with zero waste. It's appropriately sized for a simple single-parameter lookup tool. Being front-loaded with the search verb makes the purpose immediately clear. However, given the minimal content, one could argue it under-specifies, but for a straightforward query tool this length is reasonable.
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?
For a simple single-parameter search tool with no output schema, this is moderately complete. The tool's apparent simplicity (one query param) means limited complexity to document. However, the lack of any behavioral detail (match semantics, return format, limits) leaves some gaps, and with no annotations or output schema, the description is the only documentation. It's adequate but not rich.
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?
Schema coverage is 100% — the single 'query' parameter is documented as 'Название города или его часть для поиска' (city name or part of it for searching). The description adds nothing beyond the schema's explanation of the parameter. Since coverage is fully high, baseline 3 applies; the description doesn't enhance parameter understanding but the schema already handles it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Поиск городов в справочнике Деловых Линий' clearly states the verb (поиск/search) and resource (города в справочнике Деловых Линий - cities in the Business Lines directory). It distinguishes the resource as a reference directory lookup. However, it doesn't specify the scope or return details, and the sibling list includes get_terminals which is analogous but for a different resource, so some differentiation exists by resource type.
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 provided on when to use this tool versus alternatives. With siblings like get_terminals (a related directory lookup), the description doesn't clarify when cities vs terminals are relevant, or mention any exclusions or prerequisites. The 'Деловых Линий' hint suggests it's for a specific shipping company's directory, but no explicit usage context or when-not-to-use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention whether this is a read-only query, whether it requires authentication, what delivery status information it returns, or whether multiple shipment events are returned. For a tracking tool, the absence of output-behavior details is a meaningful gap.
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?
The description is a single concise sentence with zero wasted words. It states the action, the target system, and the input identifier in minimal text. This is appropriately sized for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one string parameter, no annotations, and no output schema. For a tracking tool, the description should convey what status or result the user receives (e.g., shipment status, delivery progress, history). It does not mention return behavior or any side-effects, and with no output schema and no annotations, the agent is left guessing what the tool returns. Given the sibling get_order_history overlap, more context is warranted.
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?
Schema description coverage is 100% — the single doc_id parameter is documented as 'Номер накладной или заказа' (waybill or order number) in the schema. The description repeats the same parameter concept, adding little beyond the schema. Per the baseline for high schema coverage, a 3 is appropriate; the description does clarify the identifier type aligns with the waybill number used in tracking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's function: tracking a Деловые Линии (Business Lines) order by waybill number. It names the verb (отслеживание/tracking), the resource (заказ Деловых Линий), and the identifier (номер накладной). However, it doesn't clearly distinguish itself from sibling get_order_history, which likely serves a similar tracking/order-info purpose, reducing clarity of differentiation.
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's no guidance on when to use this tool versus alternatives. get_order_history in sibling tools likely overlaps in purpose for order-related queries, yet no exclusions or alternative guidance is given. The description only implies the use case (tracking a specific order by waybill number) without explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of behavioral disclosure. The description states this is a calculation (non-destructive read of pricing), but doesn't disclose whether this requires authentication, whether it commits to anything, how results are returned, or whether it hits a live API with rate limits. For a calculation tool that presumably performs a quote lookup, the behavioral details are thin.
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 concise sentence in Russian that efficiently conveys the tool's purpose. It's appropriately front-loaded and waste-free. Every word earns its place, though it could arguably add a bit more usage context without bloating.
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 no output schema and no annotations, yet it's a non-trivial 7-parameter tool with 3 required params. The description explains the purpose adequately but doesn't describe what the output/return value looks like (cost amount, currency, delivery days). For a quote tool that returns meaningful pricing data, the lack of return-format guidance is a notable gap. However, given good schema coverage of inputs, the description is minimally adequate.
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?
Schema coverage is 100%, with all 7 parameters described in the input schema (city IDs from get_cities, dimensions in meters, weight in kg, quantity default of 1). The description adds no parameter-level detail beyond what the schema already gives. Per the rubric, baseline 3 is appropriate when schema does the heavy lifting, and the description doesn't compensate further. However, it does implicitly convey that all inputs relate to shipment dimensions for pricing.
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 the tool calculates delivery cost and timeframes for Delovye Linii ('Расчёт стоимости и сроков доставки Деловыми Линиями' - calculation of cost and delivery terms for Business Lines). It names the specific resource (cost/timeline calculation) and the transport company, which distinguishes its purpose. However, it doesn't explicitly name sibling alternatives, and the title is null, so the description is the only identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to get delivery cost and timeframe quotes), but provides no explicit guidance on when NOT to use it or which sibling tool to use instead. Given siblings include create_order, track, get_terminals, etc., the usage context is somewhat implied but not explicitly differentiated. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. A 'поиск' (search) operation is implicitly read-only, and the description states it operates on a specified city. However, it does not disclose return format, whether results include address/phone/working hours, or if auth is required.
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?
One concise sentence that fully conveys the tool's purpose with zero waste. For a single-parameter tool with full schema coverage, this level of brevity is appropriate.
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?
For a simple lookup tool with one documented parameter, the description is mostly adequate. However, with no other useful sibling tools nearby and no output schema, it could mention what terminal information is returned to help agents decide if this is the right tool.
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?
Schema coverage is 100% and the single parameter (city_id) is documented in the schema as 'ID города для поиска терминалов (из get_cities)'. The description adds minimal extra value since it just says 'в указанном городе' which largely repeats the schema's city parameter 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 searches for DL terminals in a specified city, using a specific verb+resource+scope pattern. It distinguishes from siblings since none of them (calculate, track, create_order, get_order_history, get_cities) relate to terminal search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—search terminals by city—but does not explicitly state when to use it vs alternatives. There's no exclusion guidance or mention of related siblings, though the context (needs a city ID from get_cities) is implied by the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![delovye-linii-mcp MCP server](https://glama.ai/mcp/servers/theYahia/delovye-linii-mcp/badges/card.svg)](https://glama.ai/mcp/servers/theYahia/delovye-linii-mcp)

Score Badge

Copy to your README.md:

[![delovye-linii-mcp MCP server](https://glama.ai/mcp/servers/theYahia/delovye-linii-mcp/badges/score.svg)](https://glama.ai/mcp/servers/theYahia/delovye-linii-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/theYahia/delovye-linii-mcp'

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