Samotpravil MCP

Server Quality Checklist

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

Latest release: v1.8.0
Disambiguation1/5
Multiple tools have overlapping or identical purposes (e.g., send_email vs send_mail_v2, stop_list_export_delete vs api_delete_v2_stop_list_export_token, api_post_v2_tickets vs api_post_v2_tickets_ip). The presence of both SDK-parity and raw API wrapper functions creates redundant paths for the same operation, making it very difficult for an agent to determine which tool to use.
Naming Consistency2/5
The naming is a mix of descriptive snake_case (get_delivery_status), versioned names (send_mail_v2), and raw API-style names with HTTP verbs and version prefixes (api_get_v2_tickets_id). There is no consistent verb_noun pattern; the api_* group breaks the otherwise somewhat consistent snake_case convention, and versioning is applied haphazardly.
Tool Count1/5
With 58 tools, this server is severely overloaded. The count includes many redundant wrappers, meta-tools for documentation (list_endpoints, get_endpoint, search_docs), and near-duplicates of the same endpoint. This far exceeds a usable tool surface for an email delivery API, overwhelming agents with unnecessary choices.
Completeness4/5
The tool set covers a wide range of the email API domain: sending (email, packages), delivery status, stop-list management, reports, tickets, domain whitelist, IP info, and email validation. While there are some potential gaps (e.g., missing update for packages, no bulk update operations), the core lifecycle is well represented and an agent can accomplish most tasks without hitting dead ends.
Average 2.5/5 across 58 of 58 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 14 community issues answered or closed in the last 6 months
- 54 commits in the last 12 weeks
- Last stable release on July 13, 2026
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral information beyond what annotations already provide. It does not explain side effects, whether the operation is destructive (though annotations say destructiveHint=true), what data is affected, or any required permissions. The phrase 'Python SDK parity' is too vague to count as meaningful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is not effective conciseness. It is under-specification: the single phrase 'POST /api/v2/blist/domains/verify (Python SDK parity)' carries no informative value. A concise description should still convey the tool's purpose, not just the endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two parameters, no output schema, annotations indicating potential destructive behavior), the description is severely incomplete. It fails to explain the operation, input requirements, expected outcomes, or any caveats. Users cannot safely invoke this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, yet the description adds nothing about either parameter (domain or dry_run). It neither explains the meaning of 'domain' nor elaborates on 'dry_run'. The schema already provides a Russian description for dry_run, but the description fails to compensate for the missing context elsewhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely the HTTP endpoint 'POST /api/v2/blist/domains/verify' with a mention of 'Python SDK parity'. It does not state what the tool actually does, such as verifying a domain or checking its status. The tool name hints at domain verification, but the description fails to articulate a clear verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description does not mention any use cases, prerequisites, or comparisons to sibling tools like domain_add or domain_remove. Users are left without any context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds no context about the destructive nature, required permissions, or side effects. It simply repeats the endpoint and 'Python SDK parity', which is not behaviorally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than conciseness. The single line provides minimal value and does not structure information effectively for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and a destructive hint, the description must explain what the tool does, when to use it, and what to expect. It only gives an endpoint and a reference to SDK parity, which is completely inadequate for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only dry_run has a description). The tool description does not explain any parameters, including required blist_id, check_ips, or allowed_ips. It fails to compensate for the sparse schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just 'POST /api/v2/authkey/create — WhiteLabel (Python SDK parity)'. It identifies an endpoint but does not state what the tool does (e.g., create an authentication key). The name hints at creation, but the description itself is cryptic and fails to specify the action or resource clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 like get_authkey or create_blist. There is no mention of prerequisites, typical use cases, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=true, but the description adds no behavioral context whatsoever. It does not mention side effects, required permissions, rate limits, or what happens during validation. With annotations present, the description still fails to add any transparency beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single under-specified line—just the endpoint. While it is short, this is under-specification rather than conciseness, as it lacks any structure or useful content. It does not front-load any meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with 2 required/optional parameters, no output schema, and destructive hints. It does not explain the validation process, return values, or any operational context. The schema partially describes parameters but cannot compensate for the missing behavioral and usage context.
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%, with descriptions for both 'email' and 'dry_run' in the schema. The tool description itself provides no parameter information, but according to the baseline for high schema coverage, a score of 3 is appropriate. The description does not add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely the API endpoint 'POST /api/v2/emails/validate/', with no explicit statement of what the tool does. It does not distinguish from sibling tools like api_post_v2_email_check or send_email. The name 'validate_email' implies purpose, but the description itself is missing and tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The context signals show many sibling tools for email-related operations, but the description gives no criteria, prerequisites, or exclusions. It is impossible to know when to choose this over similar tools.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no extra behavioral context—no mention of pagination, response format, or required input semantics. 'Python SDK parity' is vague and not actionable. The description fails to add value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise efficiency. It provides no structured information, only the endpoint and an ambiguous note. Every sentence should earn its place; here the single 'sentence' does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 4-parameter tool with no output schema and minimal annotation context. The description does nothing to explain the operation, its expected input, or its result. It is completely inadequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only dry_run has a description). The description provides no information about any parameters, including the required 'issuen'. It does not compensate for the low schema coverage, leaving three parameters entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name in URL form ('GET /api/v2/issue/report/fbl') plus a vague note about Python SDK parity. It does not state what the tool does, what an FBL report is, or how 'by issue' differs from 'by date'. This is essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus alternatives like get_fbl_report_by_date or get_non_delivery_by_issue. The description gives zero context on selection.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so agents know it is a safe read. However, the description discloses no additional behavioral traits such as pagination via cursor_next, response format, or that it reports non-delivery events for a specific issue. It adds nothing beyond the annotations and endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity is not effective here. It consists of a bare endpoint and a vague parity note; there is no structured breakdown or front-loaded key information. Every word could have been used to explain the tool's purpose, but it doesn't.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and only safety annotations, the tool needs a substantive description to be usable. The description provides no context about return values, pagination, or the meaning of 'non-delivery'. It is inadequate for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only dry_run is described, in Russian), and the description provides no explanation for any parameter. It does not mention that 'issuen' is required, what 'limit' controls, or how 'cursor_next' relates to pagination. With low schema coverage, the description must compensate, and it completely fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides only an endpoint ('GET /api/v2/issue/report/non-delivery') and a note about Python SDK parity, but never explains what the tool does in functional terms. The name 'get_non_delivery_by_issue' is suggestive, but the description adds no semantic clarification and does not differentiate from siblings like get_non_delivery_by_date.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. No mention of scenarios, prerequisites, or comparisons with sibling tools such as get_non_delivery_by_date or get_fbl_report_by_issue. The 'Python SDK parity' hint is not practical usage guidance.
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?
Annotations already disclose readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. However, the description adds no behavioral context: it does not explain what data is returned, whether pagination is involved, or any quirks such as requiring valid issue numbers. The 'Python SDK parity' note is too vague to be actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, with no wasted words, but it is under-specified rather than concise. It fails to convey essential information, so the brevity is a liability, not a feature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters and no output schema, the description is critically incomplete. It does not explain the tool's purpose, usage context, or return value. The annotations and schema only offer minimal safety hints, leaving the agent without enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description itself provides no parameter explanations. Each parameter (issuen, limit, order, dry_run, cursor_next) has no clarifying text except the Russian note on dry_run. The agent cannot infer that 'issuen' means the issue number or how pagination works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely the API endpoint path 'GET /api/v2/issue/report/unsubscribe' plus a note about Python SDK parity. It does not explicitly state that this tool retrieves unsubscribe records for a given issue. The path loosely parses to 'unsubscribe by issue', but the tool's function is implied rather than defined, making it only slightly better than a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever on when to use this tool versus alternatives. Sibling tools like get_unsubscribe_by_date, get_non_delivery_by_issue, and get_issue_stat exist for similar reporting needs, but the description provides no context for selecting among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds no extra behavioral context. 'Python SDK parity' is an obscure reference that does not explain pagination, return format, auth needs, or rate limits, offering no value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but not effectively concise—it is under-specified. A single phrase with no structured breakdown of purpose, usage, or behavior does not serve the agent, despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters, no output schema, and many siblings, but the description provides no substantive information. It fails to explain what 'issue_stat' refers to, what the response contains, or how it differs from similar tools, making it completely inadequate for safe and correct invocation.
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 descriptions cover 100% of parameters: 'ids' is described as package IDs from send_package, and 'dry_run' as showing the request without sending to API. The description itself adds no parameter information, but the schema does the heavy lifting, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only gives the HTTP endpoint and 'Python SDK parity' without stating what the tool actually does. It implies retrieving issue statistics from the name, but no verb or resource semantics are clarified, and it fails to distinguish from sibling tools like get_statistics or api_get_v1_get_smtp_issue_stat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With a large sibling list including get_statistics, get_package_status, and api_get_v1_get_smtp_issue_stat, the absence of any context or exclusions leaves the agent without direction.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, but the description itself adds no behavioral context beyond the endpoint. It does not explain side effects, idempotency, delivery behavior, or any external impact, so the agent must infer everything from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and contains no filler, but it is under-specified rather than genuinely concise. A single endpoint string does not earn its place because it provides almost no information beyond what the tool name already conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 parameters, required fields, no output schema, and no description. The response format, error behaviors, and mail-sending semantics are entirely unspecified, making the tool effectively unusable from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 9% (just dry_run has a description), and the tool description mentions no parameters at all. With 11 parameters including required email_from, email_to, and subject, the description fails completely to clarify what these fields mean or how they should be constructed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only the raw endpoint 'POST /api/v2/mail/send', which restates the tool's name and resource without explaining what the tool actually does in functional terms. It provides no plain-language purpose and does not differentiate from sibling tools like send_email or send_package.
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 send_email, send_package, or get_delivery_status. The description omits any context about prerequisites, preferred scenarios, or exclusions, leaving the agent without decision support.
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?
Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already covered. However, the description adds no behavioral context such as response format, pagination, required permissions, rate limits, or error behavior. It simply repeats the endpoint, leaving the agent without additional transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line, but it is under-specified rather than concise. It provides no substantive content beyond the endpoint path, failing to earn its place as a useful description. True conciseness would include a brief statement of functionality, which is entirely absent here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 a minimal description, so the agent must rely on the name and parameter schema alone. There is no explanation of the return value, use case, or how this fits into the broader API. This is inadequate for a tool with multiple similarly named siblings.
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%, with both 'issuen' and 'dry_run' already documented in the schema. The description adds no extra meaning to the parameters, but the high schema coverage means the baseline of 3 is appropriate even without parameter details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely the HTTP endpoint 'GET /api/v2/package/status', which restates the tool name without explaining what the tool does in plain language. The verb 'get' and resource 'package status' are implied by the name and path, but there is no explicit statement of the operation's purpose or how it differs from similar tools like get_delivery_status or get_ext_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever on when to use this tool versus alternatives. Sibling tools like get_delivery_status, get_ext_status, and get_issue_stat have overlapping names and purposes, and the description does not clarify conditions, prerequisites, or exclusions for using this tool.
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?
Annotations (readOnlyHint, destructiveHint) already convey that this is a safe read operation, but the description adds no behavioral context. It does not disclose pagination behavior via cursor_next, the effect of dry_run, result format, or any side effects. The 'Python SDK parity' phrase is unexplained and unhelpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity comes at the expense of substance. It is not a well-structured description; it is a bare URL and an unclear note. The phrase 'Python SDK parity' is cryptic and does not earn its place without further explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 5 parameters, 2 required, no output schema, and many sibling statistics tools. The description fails to explain what statistics are returned, how cursor_next pagination works, what dry_run does, or how this tool differs from get_issue_stat. The available structured data (schema/annotations) does not compensate for these missing behavioral and contextual details, making the description severely 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?
The input schema covers all 5 parameters with descriptions (limit, date_to, dry_run, date_from, cursor_next), so the schema carries the full burden. The description adds no additional parameter semantics or usage details beyond what the schema already provides, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides the endpoint path 'GET /api/v2/issue/statistics' and a vague note about Python SDK parity. It does not explain what statistics are retrieved, for what entity, or what the data represents, making it difficult for an agent to know what this tool actually does. It also fails to differentiate from sibling tools like get_issue_stat or get_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 rather than alternatives. The description does not mention any use cases, prerequisites, or situations where a different statistics tool would be more appropriate. Given the large sibling list, this omission is critical.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context beyond the fact that it is a POST request. It does not disclose side effects, irreversibility, authentication needs, or response behavior. With annotations present, the description should enrich the safety profile but adds nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (a single endpoint string), but this is under-specification rather than conciseness. For a tool with 12 parameters, the one-liner does not earn its place by conveying useful meaning; it simply restates a technical detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 12 parameters, nested objects, no output schema, and a destructive action, the description is grossly inadequate. It omits any context about return values, side effects, prerequisites, or use cases, making it nearly impossible for an agent to invoke the tool correctly without external knowledge.
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 covers 58% of parameters with descriptions, but the tool description itself contains zero parameter information. It does not help clarify undocumented params like track_open, x_track_id, track_click, track_domain, or check_local_stop_list. Given the moderate schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely 'POST /api/v1/smtp_send' – an HTTP method and endpoint – with no statement of what the tool actually does. The tool name 'send_email' hints at the purpose, but the description itself provides no verb or resource definition. This is clearer than a pure tautology but still fails to explicitly state the tool's function.
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 like send_mail_v2 or send_package. The description does not mention prerequisites, alternatives, or context for selection, leaving the agent without decision-making support.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no behavioral context beyond the raw endpoint, such as what data is returned, whether pagination is required, or how it handles limit and cursor parameters. It merely restates the endpoint, which is redundant with 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line and could be considered terse, but it is under-specified rather than concise. It omits essential semantic information and does not earn its place beyond being an endpoint reference, similar to a low-effort placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, and a description that only provides the endpoint, the tool is severely under-documented. It lacks any explanation of return values, pagination semantics, or how it relates to other stop-list tools. An agent would have to guess at the tool's function and output structure.
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?
All three parameters (limit, dry_run, cursor_next) have descriptions in the input schema, giving 100% schema coverage. The description itself adds no parameter details, but the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only gives the HTTP endpoint path and a note about Python SDK parity. It does not explain what the tool does in plain terms, leaving the agent to infer from the name that it deals with failed stop-list entries. This is nearly a restatement of the tool name and fails to distinguish it from sibling tools like search_stop_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description does not mention use cases, prerequisites, or exclude any scenarios, leaving the agent without direction on selection.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds no additional behavioral context such as what the report contains, response format scope, or any constraints. It neither contradicts nor enriches the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line with no fluff, but it is under-specified rather than concise. It fails to convey meaningful information about the tool's purpose or usage, so brevity here is not a virtue.
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 three optional parameters and no output schema, the description should explain what the FBL report is and how to use it. It only gives a cryptic Russian title, leaving the agent without enough context to select this tool over siblings.
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?
The input schema provides full descriptions for all three parameters (key, date, dry_run) with 100% coverage. The description adds no parameter-level detail, but the baseline for high schema coverage is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially the endpoint path with a vague Russian title 'Отчёт о пожаловавшихся v1' (Report on complainants v1). It does not explicitly state the tool's function in English, and it fails to distinguish itself from sibling tools like get_fbl_report_by_date or get_fbl_report_by_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. No mention of use cases, prerequisites, or exclusions exists. Given that several sibling tools target FBL reports, this omission is significant.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. However, the description adds no additional behavioral context, such as authentication requirements, response format, or what the status details include. It fails to add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It lacks substantive detail needed for the agent to understand the tool's purpose, making it more of a placeholder than a concise, informative description.
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?
No output schema and minimal description. Given multiple sibling status tools (e.g., get_package_status, get_delivery_status), the description is incomplete because it does not clarify what makes this tool unique, what the response contains, or in which contexts it should be chosen.
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% with each parameter (key, dry_run, pack_id) having a description. The tool description itself does not add parameter information, but per the baseline for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'GET /api/v1/package_status — Статус отправки v1' essentially restates the tool name in Russian, providing only that it retrieves package status. It does not clearly define what 'status' means or differentiate from sibling tools like get_package_status and get_delivery_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives. The description offers no scenarios, prerequisites, or exclusions, despite the presence of several closely related status tools among the siblings.
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?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating mutation and side effects. The description adds no further behavioral context—no mention of authentication, rate limits, what gets destroyed, or the actual sending side effects. 'Python SDK parity' is not a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is under-specification for a tool with 15 parameters and nested objects. It provides an endpoint but lacks structured information like usage examples or key constraints. This is not effective conciseness but rather a lack of needed detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, 5 required, nested objects, no output schema, and a destructive/mutating nature, the description is severely incomplete. It does not explain return values, error conditions, or operational semantics, making it impossible for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13% (users and dry_run have descriptions); the other 13 parameters are undocumented. The description does not compensate by explaining any parameter roles, required fields, or formats. This leaves the agent guessing at the meaning of parameters like track_open, is_moderate, and check_local_stop_list.
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 gives the endpoint 'POST /api/v1/add_json_package' and says 'массовая отправка' (mass sending), which clarifies that this tool sends packages in bulk. However, it does not explicitly state what a package contains (e.g., emails) or how this differs from sibling tools like send_package_xml, making the purpose somewhat vague.
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 send_email, send_mail_v2, or send_package_xml. The note 'Python SDK parity' hints at compatibility but does not provide actionable usage context or exclusions.
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?
Annotations already indicate destructiveHint=true, but the description adds no additional context about what gets updated, side effects, or prerequisites. The endpoint itself implies a mutation, but no behavioral specifics are disclosed beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It consists of an endpoint and a note about SDK parity, with no substantive content that helps an agent understand the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with 9 parameters and no output schema, this description is grossly incomplete. It doesn't cover what operation is performed, what parameters do, or what the response looks like, leaving the agent with almost no usable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11% (only dry_run has a description), and the tool description does not mention any of the 9 parameters. This creates a significant gap: neither the schema nor the description explains the meaning of parameters like name, active, webhook_url, or check_stop_list.
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 specifies 'POST /api/v2/blist/update' which indicates an update operation on a 'blist', but it doesn't explain what 'blist' means or what updating entails. The verb and resource are clear from the endpoint, yet the description reads more like a technical label than a functional explanation.
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 like create_blist or get_blist. The description only provides the endpoint and notes 'WhiteLabel (Python SDK parity)', which gives no context for selection.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. However, the description adds no behavioral context whatsoever. It does not explain what 'clean' or 'standardization' entails, what happens to the request, or what the output might be. Since it adds zero value beyond annotations, the score is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It consists solely of an endpoint path and a single ambiguous word. Every sentence does not earn its place because there is effectively no content that helps the agent understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple schema (2 params) and the presence of annotations, the description is still completely inadequate. There is no output schema to clarify return values, and the description does not explain the purpose, behavior, or usage context. With dozens of siblings, this lacks even minimal context for correct selection and invocation.
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?
The input schema has 100% description coverage for both parameters (email and dry_run), each with its own explanation. The description itself adds no parameter information, but the schema already does the heavy lifting, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially just the HTTP endpoint path ('POST /api/v2/emails/clean/') and a single word 'Стандартизация' (standardization). It does not clearly state what the tool does, nor does it differentiate it from the many sibling tools that handle email-related operations. It reads more like a label than a functional description.
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 the many alternatives. No context, prerequisites, or exclusions are provided. The description offers no help in deciding whether to invoke this tool over similar ones like api_post_v2_email_check or validate_email.
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?
The description adds no behavioral details beyond what annotations already declare. Annotations indicate destructiveHint=true and readOnlyHint=false, but the description does not explain the actual effects, side effects, or any other behavioral traits. It merely repeats the endpoint and notes Python SDK parity, which is not behavior.
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 line with no fluff, but it is under-specified rather than concise. It lacks essential information that a tool description should include, so the brevity is not a positive. It is not structured in any way, but it is short and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and potentially destructive behavior, this description is severely incomplete. It does not explain what the tool does, when to use it, what the parameters mean, or what the return value looks like. The description is wholly inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with only dry_run having a description (in Russian). The tool description provides no additional meaning for any parameter names or how they relate to the blist creation process. With schema coverage at 14%, the description does nothing to compensate, leaving most parameters unexplained.
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 provides the HTTP endpoint 'POST /api/v2/blist/create', which implies the tool creates a blist, but it never explicitly states that. The phrase 'WhiteLabel (Python SDK parity)' adds context but not clarity. It is more of a technical reference than a clear statement of purpose, though it does distinguish from siblings like get_blist and update_blist by the 'create' action.
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 alternatives. It does not mention that this is for creating a new blist, nor does it point to update_blist for modifications or get_blist for retrieval. The agent is left without any usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no behavioral context beyond repeating the HTTP method (GET), which is already implied by the annotations and tool name. It does not mention return format, authentication needs, rate limits, or any operational nuances, providing zero additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single phrase that restates the endpoint adds little value and fails to inform the agent about the tool's purpose, usage, or behavior.
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 output schema and minimal description, the tool lacks essential context about what data is returned, what 'email activity' encompasses, and how to interact with it. Given the large set of sibling tools, this sparse description is insufficient for an agent to select and invoke the tool correctly.
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% with both parameters (email, dry_run) having descriptions. The tool description itself adds nothing about parameters, but the schema already documents them adequately, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'GET /api/v2/email/activity — Активность' essentially restates the tool name and endpoint without explaining what the tool does. It does not specify what 'activity' means, what data is returned, or how it differs from siblings. This is a tautological description that fails to add clarity beyond the name.
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 like get_delivery_status, get_issue_stat, or other activity-related tools. The description gives no context about typical use cases, prerequisites, or exclusions, leaving the agent without direction.
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?
Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is known. However, the description adds no behavioral context beyond the endpoint, such as what the add operation does (e.g., adds a domain to the blocklist, whether it can overwrite, or if it requires authentication). No additional transparency is provided.
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 concise, containing only the endpoint and a parenthetical. It is front-loaded and free of fluff, but it is under-specified, lacking a human-readable explanation. While not as sparse as 'Process', it borders on being a technical reference rather than a proper description.
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?
Given the tool's simplicity (2 parameters, no output schema), a short description could suffice, but this one fails to state the operation's purpose or side effects. The lack of any natural-language explanation makes it incomplete for an agent that needs to understand when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with 'dry_run' having a Russian description and 'domain' having none. The tool description does not compensate by explaining the 'domain' parameter or its role in the API call. Thus, the description adds no semantic value for parameters beyond the sparse schema.
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 consists solely of the API endpoint 'POST /api/v2/blist/domains/add' and a parenthetical 'Python SDK parity'. This implies the tool adds a domain to a blocklist ('blist'), but relies on API jargon and does not explicitly state the action in natural language. It distinguishes from siblings like 'domain_remove' by verb and resource, but lacks clarity for an agent unfamiliar with the SDK.
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 usage guidance is provided. The description does not mention when to use this tool instead of alternatives such as 'domain_remove', 'list_allowed_domains', or 'domain_check_verification'. There is no context about prerequisites or typical scenarios.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. However, the description adds no context beyond the GET method, such as pagination behavior, response format, or any caveats. There is no behavioral disclosure beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. A single API path is not a meaningful description; it omits all semantic content. This is not effective conciseness but rather a lack of substance, similar to the 'Process' example.
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 one parameter, no output schema, and a simple list operation, a complete description should state that the tool returns allowed domains and possibly any relevant filtering. The current description is just the endpoint, leaving the agent to infer functionality from the name alone, which is insufficient.
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% for the only parameter dry_run, which has a clear description ('Показать запрос без отправки на API'). Since the schema already documents the parameter fully, the description's lack of parameter details is acceptable, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely the HTTP method and endpoint path "GET /api/v2/blist/domains", which provides no explicit statement of the tool's purpose. It is essentially a tautology of the tool name, adding no semantic content about listing allowed domains.
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 such as get_blist or domain_remove. The description does not mention any conditions, prerequisites, or scenarios where this endpoint is appropriate.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, but the description adds no further behavioral context. It does not clarify what the tool returns, whether authentication is needed, or any side effects, so the description offers no value beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single fragment of text, but it is under-specified rather than appropriately concise. It conveys only the endpoint and SDK parity, omitting key information about purpose and behavior, so it fails to earn its place as a useful description.
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 tool with no output schema and only minimal annotations, the description is far from complete. It does not explain what the tool does, when to use it, or what the response looks like, leaving the agent to infer everything from the name and endpoint.
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 all three parameters (limit, dry_run, cursor_next) already have descriptions. The tool description itself does not mention any parameters, but the baseline of 3 applies because the schema fully documents them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely 'GET /api/v2/stop-list/unsubscribe (Python SDK parity)', which is a raw endpoint reference rather than a statement of what the tool does. It does not clearly specify an action on a resource, and it fails to distinguish itself from sibling tools beyond the endpoint path.
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 usage guidance is provided. The description does not indicate when to use this tool, what scenarios it is suitable for, or how it compares to alternatives like remove_stop_list_email or search_stop_list.
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?
The description adds no behavioral context beyond the endpoint. Annotations already indicate destructiveness (destructiveHint: true), but the description doesn't explain what is removed, whether it's reversible, or that dry_run can preview the request. The 'Python SDK parity' note is about implementation, not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It lacks essential information, so it's not effective conciseness. The single phrase doesn't earn its place as a description.
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 description is inadequate for a destructive tool. With no output schema and minimal annotations, the description should provide more context about the operation's effects and usage. It doesn't explain what blist domains are or the impact of removal.
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 description does not elaborate on the parameters. The schema defines domain (minLength 1) and dry_run (boolean with a Russian description), but the description adds no meaning. The domain parameter's purpose is not clarified beyond its name.
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 'POST /api/v2/blist/domains/remove' implies removing a domain from a blacklist based on the name and path, but it doesn't explicitly state the action or resource. It's not a tautology, but it's vague and doesn't clearly distinguish from sibling tools like update_blist or domain_add beyond the name.
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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or relationships to sibling tools such as domain_add or domain_check_verification, leaving the agent without usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description carries no additional behavioral context. It doesn't mention what the returned documentation contains, any prerequisites, or limitations. Still, it doesn't contradict 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 extremely short (five words in Russian), with no wasted words, but it's also under-specified, providing minimal value beyond the name. It is concise but not effectively structured to help the agent.
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 tool with one parameter, no output schema, and minimal annotations, the description should explain what documentation is returned and in what form, but it only states 'Documentation on the API method.' This is insufficient to understand the tool's output or behavior.
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?
The schema description for name_or_path is complete (100% coverage), explaining it is a method name or URL part with an example. The tool description adds no parameter semantics, but the schema covers it, so baseline 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 'Документация по методу API.' indicates the tool provides documentation for an API method, but it is vague: it doesn't specify that it retrieves documentation for a given endpoint name/path, nor distinguish from sibling tools like list_endpoints or search_docs. It is more than a tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 get_endpoint versus alternatives such as list_endpoints or search_docs. The description contains no usage context or exclusions.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no behavioral context such as pagination behavior, response format, authentication requirements, or rate limits, leaving a significant gap beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line with only an endpoint and a note about Python SDK parity. While concise, it is under-specified and lacks the structure expected for a tool description, providing little substance beyond the name and schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and no output schema, the description fails to explain what the FBL report is, what data it returns, how pagination works, or any other essential context. The description is fundamentally incomplete for effective tool invocation.
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?
The schema description coverage is 100%, so the five parameters are fully documented in the schema. The description adds no parameter details, but the baseline of 3 applies because the schema already provides adequate semantics for each parameter.
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 gives the HTTP method and endpoint path but does not explicitly state that the tool retrieves a feedback loop (FBL) report for a date range. The resource path 'report/fbl' and required date_from/date_to parameters imply this, but the description alone lacks a clear verb and scope, making it only moderately clear.
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 get_fbl_report_by_issue or get_unsubscribe_by_date. The description merely cites an SDK parity note, which does not provide situational context or exclusions.
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?
The description adds no behavioral context beyond the annotations. It does not disclose whether the download is one-time, what the response format is, or any side effects. The annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds nothing beyond that.
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 with the endpoint, which is concise. However, it is not a proper explanatory description and lacks structure that would help an agent understand the tool's function.
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 is simple with only two parameters and complete schema/annotation coverage, but the description omits crucial context such as the need to obtain a token from stop_list_export_create first and what the returned payload represents. This makes the description incomplete for effective tool selection.
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% (both token and dry_run have descriptions), so the description does not need to add parameter details. The description text adds no extra meaning about the parameters; it simply repeats the endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely the endpoint 'GET /api/v2/stop-list/export/{token}' which essentially restates the tool name without explaining what the tool does. It lacks an explicit verb like 'downloads' or 'retrieves', and does not distinguish from siblings like api_get_v2_stop_list_export_token.
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. The description does not mention that a token must first be created via stop_list_export_create, nor does it exclude use cases. This is a clear gap for a tool with several related export operations.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the read-only nature is known. The description adds only the HTTP method and a brief phrase, but no additional behavioral context such as response format, pagination, authentication requirements, or side effects. It fails to leverage the opportunity to explain the 'openWorld' nature or any non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this under-specification is not true conciseness. It lacks a proper sentence explaining the tool's function, parameters, or return value. The structure is minimal (endpoint + dash + short phrase), which does not provide enough useful information for an agent to correctly invoke the 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?
There is no output schema, so the description should explain return values, but it doesn't. It also fails to differentiate from many sibling report tools and provides no context about what 'package_report' or 'non-deliveries' means in practice. The tool has 3 optional parameters and no required ones, yet the description gives no hint of expected behavior or examples beyond the endpoint path.
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 baseline is 3. However, the schema's parameter descriptions are minimal (e.g., 'Query-параметр (пример: 12345)'), and the tool description adds no semantic meaning for id, key, or dry_run. The description does not compensate for the weak schema explanations, but per the rubric, a score of 3 is appropriate when coverage is high.
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 'GET /api/v1/package_report — Недоставки пакетной отправки v1' indicates this tool retrieves a report about non-deliveries for package/batch sends. This is more specific than a tautology but remains vague: it does not clarify the report's content, structure, or differences from sibling tools like api_get_v1_package_report_fbl or api_get_v1_package_status.
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. The description offers no context, prerequisites, or exclusions, leaving the agent to infer usage solely from the endpoint name and vague phrase.
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?
The description discloses no behavioral traits beyond what annotations already state (readOnlyHint=true, destructiveHint=false). It doesn't mention required authentication, what data is returned, pagination, or any side effects. The 'WhiteLabel' hint is too vague to be useful for understanding runtime behavior.
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 with no fluff, so it is concise in length. However, it is under-specified; the single sentence provides an endpoint but fails to define the tool's purpose or behavior. It is not structured to front-load important details because it lacks them entirely.
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?
Given that there is no output schema and the schema has only partial descriptions, the description carries the burden of explaining what the tool returns, when to use it, and how it relates to sibling tools like create_blist/update_blist. None of that is provided, making the tool contextually incomplete for an agent.
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 only 50% (dry_run has a description, blist_id does not). The description itself adds no meaning to the parameters; it doesn't explain what blist_id is or how dry_run interacts with the request. With low coverage, the description should compensate, but it remains silent.
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 identifies the tool as 'GET /api/v2/blist' which gives a specific verb and resource, but it lacks a plain-language statement of what the tool does (e.g., retrieves a blacklist entry). The 'WhiteLabel (Python SDK parity)' note is tangential and doesn't clarify the function. It is distinguishable from siblings mainly by the endpoint name, not by described purpose.
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 like 'get_overview' or 'search_stop_list'. The description mentions 'Python SDK parity' but that doesn't help an agent decide between tools. There are no prerequisites, exclusions, or alternative suggestions.
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?
Annotations already declare readOnly and non-destructive, so the description need not repeat safety. However, it adds no behavioral detail about pagination, response structure, or rate limits, and the 'Python SDK parity' phrase is too vague to count as meaningful disclosure. Given the high schema coverage and no output schema, the description should compensate by explaining what the operation returns.
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 very concise at one sentence with no fluff, but it is under-specified. It could use a second sentence to describe the return value, but given its brevity and the fact that the endpoint path is valuable, it earns a 4.
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 tool with six parameters and no output schema, the description is too sparse. It fails to mention the purpose (reporting unsubscribed emails), the date-range filtering, or how this tool fits among siblings. Annotations cover safety but not functional context, leaving the agent to infer from the name and schema.
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 83% with parameter descriptions for date_from, date_to, limit, dry_run, and cursor_next. The description adds no additional parameter semantics, but since the schema already documents formats and pagination, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides the endpoint path 'GET /api/v2/blist/report/unsubscribe' and 'Python SDK parity', which essentially restates the tool name without explaining what the tool does. It does not distinguish this from sibling tools like get_unsubscribe_by_issue or other date-based report tools.
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 alternatives. It does not mention that this retrieves unsubscribes by date range, nor does it reference any sibling tool or exclusion criteria. The only hint is the endpoint name, which implies a resource but not usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. However, the description adds only 'Python SDK parity' and provides no behavioral context such as return format, pagination behavior, or the meaning of 'fbl'. The transparency bar is lower with annotations, but the description contributes almost nothing.
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 short sentence, front-loaded with the endpoint path. It wastes no words and is easy to scan. However, it is so terse that it sacrifices functional clarity, so it does not earn a 5.
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?
There is no output schema, so the description should explain what the endpoint returns, but it does not. It also does not clarify the semantics of 'fbl' or how this stop list differs from others. For a presumably read-only list tool, the description 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%, with all three parameters (limit, dry_run, cursor_next) having descriptions in the input schema. The description adds no parameter details beyond what the schema already provides, but the high coverage gives a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides only the HTTP method and endpoint path ('GET /api/v2/stop-list/fbl') without stating what the tool does. The name 'stop_list_fbl' hints at a list operation, but there is no explicit verb like 'list' or 'get' and no explanation of the resource. It does not distinguish from sibling tools such as stop_list_failed or search_stop_list.
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. The description does not mention conditions, prerequisites, or scenarios where this is preferred over other stop-list tools. Sibling names suggest related functionality, but the description offers no differentiation.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds no behavioral context. It does not explain what the check entails, whether it returns a pass/fail or a list of issues, or any rate limits/auth requirements. The only hint of behavior is 'check layout,' which is too vague.
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 (one sentence), which is efficient, but it is under-specified rather than genuinely concise. It lacks enough detail to be useful on its own, so it does not earn its place as a complete description.
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 a complex 'checks' parameter containing objects and no output schema, the description is far from complete. It leaves the agent guessing about the return format and how to interpret results. The schema provides some clues, but the description fails to give necessary context for a validation tool among many similar siblings.
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 all three parameters (body, checks, dry_run) already have descriptions with examples. The tool description adds no parameter-level meaning beyond that, so a baseline score of 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 the HTTP method and endpoint, plus a vague Russian phrase 'Проверить верстку' (check layout). It identifies a verb and resource, but 'верстка' is ambiguous and does not clarify that this tool validates email HTML/accessibility issues. It also does not distinguish it from sibling tools like validate_email or api_post_v2_emails_clean.
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. The description only gives the endpoint and a minimal purpose, with no mention of prerequisites, intended use cases, or exclusions.
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?
Annotations declare readOnlyHint and non-destructive behavior, which are consistent with the GET method. However, the description adds no behavioral context beyond a mention of 'Python SDK parity,' which does not disclose return format, rate limits, or any side effects. With annotations present, the description still fails to provide useful behavioral detail.
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 minimal, but its brevity comes at the cost of omitting the tool's core purpose. It is not wasteful, but it also doesn't earn its place because it simply restates the endpoint. This is under-specification rather than effective conciseness.
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?
There is no output schema, so the description should explain what the tool returns (e.g., IP address details). It does not. The one optional parameter and read-only nature are not enough to compensate for the lack of return-value documentation. The description is incomplete for an agent to invoke the tool correctly.
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?
The schema includes one optional boolean parameter, dry_run, described in Russian as 'Show request without sending to API.' Schema description coverage is 100%, so the schema fully documents the parameter; the tool description adds no parameter information. Baseline of 3 for high schema coverage 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 consists solely of the HTTP method and endpoint ('GET /api/v2/ip') and a compatibility note ('WhiteLabel (Python SDK parity)'). It does not explicitly state that this tool retrieves IP address information, leaving the agent to infer from the name. This is a vague purpose statement rather than a clear verb+resource description.
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?
The description contains no guidance about when to use this tool, what scenarios it applies to, or alternatives. It does not mention any exclusions or prerequisites, offering zero usage direction.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. However, the description adds no behavioral context such as pagination behavior, return format, default limits, or any side effects. Without additional disclosure, the tool's behavior remains opaque beyond the schema.
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 not bloated, but it is under-specified. It consists of only an endpoint path and a compatibility note, missing critical functional information. While it is concise, it does not serve as a sufficient tool description; under-specification limits its value.
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?
Given the tool has 5 parameters, no output schema, and high conceptual complexity, the description is far from complete. It does not explain what the tool returns, how to interpret date ranges, or when to prefer it over similar report tools. The annotations and schema provide some context, but the description itself is too sparse for an agent to invoke it correctly.
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 all five parameters (limit, date_to, dry_run, date_from, cursor_next) have individual descriptions. The description itself adds no parameter semantics, but the baseline is 3 because the schema carries the burden. The endpoint line does not clarify parameter usage.
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 provides the API endpoint 'GET /api/v2/blist/report/non-delivery' and notes Python SDK parity, but it does not explicitly state that the tool retrieves non-delivery report data for a date range. The tool name implies the function, and the endpoint identifies the resource, but there is no clear verb+resource statement, making the purpose vague.
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. The description does not mention use cases, prerequisites, selection criteria, or how it differs from sibling tools like get_non_delivery_by_issue. The 'Python SDK parity' note is not usage guidance.
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?
Annotations already indicate destructive behavior, but the description adds no extra context about consequences, required permissions, or side effects. It does not explain that sending an XML package likely triggers an API operation with real-world effects.
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 and front-loaded, but it includes the unhelpful 'Python SDK parity' note and is more a label than a helpful explanation. It is not bloated, but it is under-specified.
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 tool with 2 parameters and no output schema, the description leaves significant gaps: it does not clarify what the tool returns, how the XML package is used, or the semantics of the 'GET' method versus the tool's 'send' action. The overall context 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 parameters ('url' and 'dry_run') are fully described in the input schema. The description adds no additional parameter information, which is acceptable given the high schema coverage.
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 specifies the resource (XML package via URL) and the endpoint path, distinguishing it from the sibling 'send_package' by the XML/URL aspect. However, it is a terse fragment rather than a clear verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It does not mention prerequisites, exclusions, or the sibling 'send_package'. The 'Python SDK parity' note is not actionable for an agent.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'full status history' and 'Python SDK parity,' implying equivalent behavior to the SDK method. However, it does not disclose pagination, return format, or any operational details beyond the annotation baseline.
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 line, front-loaded with the endpoint and core function. It avoids fluff and gets to the point. While under-specified, it is not verbose, so conciseness is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no output schema, and a minimal description. It does not explain how to identify the issue (likely via message_id), what the response would contain, or any usage context. The description is incomplete for an agent to invoke the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only dry_run has a description). The tool description itself provides no parameter explanations. message_id and x_track_id are left undocumented, and the description does not clarify how these parameters relate to retrieving status history. The description fails to compensate for the low schema coverage.
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 identifies the resource ('issue/ext_status') and action (GET to retrieve full status history). It adds 'Python SDK parity' for context. It doesn't explicitly differentiate from sibling tools like get_delivery_status or get_package_status, but the resource name is specific enough.
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 versus alternatives. It doesn't mention prerequisites, required identifiers, or scenarios where other status tools would be more appropriate. The description merely states the endpoint and function.
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?
Annotations declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. However, the description adds no behavioral context: it neither explains what an 'overview' entails nor reveals what the return value contains. It relies entirely on annotations and the tool name, providing no extra information about expected behavior.
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 phrase, 'Обзор API СамОтправил', which is concise with no filler. However, it is little more than a restatement of the tool name and lacks any informational substance. While it is brief, the brevity sacrifices clarity, making it only partially successful in earning its place.
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?
There is no output schema, so the description carries the burden of explaining what the tool returns. It simply says 'overview' without detailing whether the agent will receive a list of endpoints, a prose summary, or metadata. Given the tool is likely simple, the description is still incomplete because it does not clarify the content or format of the result, nor its role in conjunction with the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to elaborate on parameter meanings because there are none. The input schema confirms an empty properties object, and the description adds no parameter-related semantics, which is acceptable given the absence of parameters.
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 'Обзор API СамОтправил' translates to 'Overview of the SamOtpravil API'. It names the resource (API) and a generic action (overview), but does not specify what the overview contains or how it differs from sibling tools like list_endpoints or get_endpoint. The purpose is somewhat clear but lacks the specificity needed to distinguish it from other API-related tools.
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?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, intended use cases, or exclusions. With over 60 sibling tools, the lack of usage guidance leaves the agent uncertain about when get_overview is the appropriate choice compared to list_endpoints or get_endpoint.
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?
The description adds minimal behavioral context beyond what annotations already provide. It reiterates the destructive nature via the DELETE method, which is also captured by destructiveHint=true, but does not disclose consequences such as permanent removal, authorization requirements, or the effect on related export files. No additional behavioral traits are explained.
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 line that conveys the endpoint and method efficiently. It is front-loaded with the essential information, with no filler words. However, it is somewhat terse and could benefit from a brief plain-language summary without becoming verbose.
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 no output schema, minimal parameter documentation, and a destructive operation, yet the description provides no context about return values, side effects, or when this deletion is appropriate. It is insufficient for an agent to safely infer behavior or compare with sibling tools.
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 only 50%: the token parameter has no description, and the tool description does not clarify its meaning beyond being a path parameter. The dry_run parameter is described in the schema (in Russian) but not in the tool description. The description adds no value to the parameter understanding, leaving the token's purpose ambiguous.
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 indicates a DELETE operation on the stop-list export resource identified by token, which implies deleting an export. However, it lacks a plain-language statement of the tool's function and does not distinguish it from the sibling tool api_delete_v2_stop_list_export_token, which targets the same endpoint.
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. The description only gives the HTTP endpoint and mentions Python SDK parity, but does not explain scenarios, prerequisites, or why one might choose this over sibling tools such as stop_list_export_tasks or api_delete_v2_stop_list_export_token.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds only the HTTP method and a note about Python SDK parity, which doesn't disclose meaningful behavioral details beyond the annotations. No mention of response format, status values, or filtering behavior.
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 short phrase that front-loads the key information (HTTP method and resource). No wasted words or filler. It is concise, though arguably too minimal to be fully self-sufficient.
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 output schema, the description should clarify what the tool returns, but it only states 'list of export tasks'. The status filter parameter is undocumented, and the overall behavior is under-specified. For a simple list endpoint, this may be enough for basic use, but it lacks detail needed for robust agent decision-making.
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 documents two optional parameters, but only dry_run has a description (50% coverage). The description does not explain the status enum values or the purpose of dry_run. Since the description fails to compensate for the undocumented status parameter, the parameter semantics remain incomplete.
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 identifies the tool as 'GET /api/v2/stop-list/export — список задач экспорта', which clearly indicates it lists export tasks. It distinguishes itself from sibling tools like stop_list_export_create, stop_list_export_download, and stop_list_export_delete. However, it doesn't elaborate on what an 'export task' is or how the list is structured.
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?
The description provides no guidance on when to use this tool versus the many related sibling tools. No context about typical scenarios, prerequisites, or alternatives is given, leaving the agent to infer usage solely from the endpoint name and basic list semantics.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the mutating nature is known. The description adds only the endpoint and 'Python SDK parity', which does not disclose additional behavioral traits such as side effects, reversibility, or permission requirements. No contradiction with annotations, but no added transparency.
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 no filler. It is appropriately front-loaded, conveying the endpoint and action immediately. It could include more detail, but its current size is efficient.
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 destructive tool with no output schema, the description is too sparse. It does not explain the consequences of stopping a package, whether the action is reversible, or what the response looks like. The annotations provide some safety signals, but the description itself lacks essential context for an agent to use it confidently.
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 50% (only dry_run has a description; package_id does not). The tool description says nothing about parameters, so it does not compensate for the missing package_id semantics. While the name implies its role, the description adds no meaning beyond the schema.
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 action ('остановить пакет' / 'stop package') and the target resource (package). It also provides the exact endpoint, which distinguishes it from sibling tools like get_package_status or send_package. However, it does not elaborate on what a 'package' is or the broader scope of the operation.
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, nor are any prerequisites or exclusions mentioned. The description simply states the operation without context, leaving the agent to infer usage from the tool name and endpoint.
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?
The description adds little beyond the annotations. Annotations already declare readOnlyHint=true and destructiveHint=false. The description only adds 'summary for the day', which is minimal. It does not disclose return format, pagination, authentication needs, or any other behavioral nuance.
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 line, front-loaded with the endpoint and purpose. There is no wasted text. However, it is so brief that it borders on under-specification, but for a simple read-only tool it is appropriately sized.
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 output schema and minimal description, the tool's behavior and response are unclear. The description does not explain what 'issue stat' entails, how the response is structured, or how it differs from sibling tools. Given the presence of annotations and a simple parameter set, more context is still needed.
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%, so all three parameters are documented in the input schema. The description does not add any additional semantics beyond the schema. Per the baseline rule for high coverage, a score of 3 is appropriate.
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 identifies the tool as a GET endpoint for retrieving SMTP issue statistics for a day ('Сводный отчет за сутки'). The verb+resource+scope are present. However, it doesn't explicitly differentiate from the sibling tool 'get_issue_stat', which appears to serve a similar purpose.
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 alternatives like get_issue_stat or get_statistics. The description only states what it does, with no usage context, prerequisites, or exclusion criteria.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no behavioral context beyond labeling it a report, omitting details about response format, filtering semantics, or authentication requirements.
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, compact line with no wasted words, making it concise and front-loaded. It lacks substantive content but is appropriately sized for a minimal identification of the endpoint.
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?
Given that there is no output schema and the tool is a report generator, the description is incomplete. It does not explain what the report contains, how the parameters affect the results, or when to prefer this over similar sibling tools.
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?
All three parameters have descriptions in the schema with examples, so schema coverage is 100%. The description does not add any parameter-level information beyond what the schema already provides, so the baseline score of 3 applies.
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 identifies the resource as a 'report on non-deliveries' (Отчёт о недоставках) with a GET endpoint, making the purpose reasonably clear. However, it does not specify the scope or criteria of the report, nor does it distinguish it from sibling report tools like get_non_delivery_by_date or get_fbl_report_by_date.
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?
The description provides no guidance on when to use this tool versus alternatives. It is a bare title with no mention of use cases, prerequisites, exclusions, or comparisons to related report endpoints.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral context, such as response format, pagination, or prerequisites. It simply restates the resource and method without enriching the safety profile beyond what annotations already provide.
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, short line that is front-loaded with the HTTP method and endpoint. It is concise and efficient, with no unnecessary words. However, its brevity borders on under-specification, making it more of a label than a descriptive explanation.
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?
Given no output schema and three parameters, the description does not explain what the response contains or how the parameters affect the report. The minimal prose forces the agent to infer tool behavior from the endpoint name and schema, which is insufficient for a complete understanding of the tool's semantics.
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 baseline is 3. The description does not add any extra meaning to the parameters (key, dry_run, pack_id); it only relies on the schema's brief descriptions. No additional usage hints are provided beyond what is already in the input schema.
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 names the HTTP method and endpoint, and 'Жалобы пакетной отправки v1' indicates it retrieves batch-sending complaints. It is distinguished from siblings by the 'fbl' suffix. However, it reads as a title rather than a full action statement, leaving the exact retrieval behavior implicit.
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 like api_get_v1_get_fbl_report or get_fbl_report_by_date. The description does not mention filtering by pack_id or any criteria for selecting this endpoint.
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?
Annotations already declare readOnlyHint and destructiveHint=false, so the description adds little beyond the GET method and download action. It doesn't mention error behavior or response format, but given the safe annotation coverage, a score of 3 is appropriate.
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 appropriately short and front-loaded, consisting of a single concise line with no filler. It earns its place, though a bit more context could be added without becoming verbose.
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 is simple, but the description omits the token parameter and does not explain expected responses or the overall export workflow. With no output schema and many related sibling tools, more context is needed for reliable use.
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 fully describes the dry_run parameter, but the description's path includes a :token parameter that is missing from the input schema. This leaves the primary parameter unexplained, making correct invocation ambiguous.
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 a specific action 'Скачать стоп-лист' (Download stop-list) and gives the HTTP path, making the tool's purpose evident. It doesn't explicitly distinguish from the sibling stop_list_export_download, but the name and :token path clarify the token-based download intent.
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, prerequisites (e.g., having an export token), or alternatives. The openWorldHint annotation is present but the description offers no contextual advice on proper invocation relative to sibling tools.
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?
The description adds no behavioral detail beyond the purpose. Annotations already indicate the tool is not read-only and is destructive, and the description simply confirms a write action ('Создать'). No additional context is provided about side effects, permissions, or consequences.
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 that efficiently communicates the endpoint and action. It is concise and free of redundant wording, though it may be too sparse for the tool's complexity.
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?
Given the presence of multiple sibling ticket tools and no output schema, this description is incomplete. It lacks information about return values, how this creation differs from similar endpoints, and any caveats. The 5-parameter schema is documented, but the description itself does not provide enough context for reliable tool selection.
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?
The input schema has 100% coverage with all 5 parameters described with examples. The description itself does not mention parameters, but the schema provides sufficient semantic detail, so the baseline score of 3 is appropriate.
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 a specific verb and resource: 'POST /api/v2/tickets — Создать обращение' (Create a ticket). It is unambiguous about the action and target, but it does not differentiate from sibling tools like api_post_v2_tickets_ip or api_post_v2_tickets_id, so it falls short of a 5.
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. The description only states the action without any context about prerequisites, use cases, or exclusions, leaving the agent to infer usage from the endpoint name alone.
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?
The description simply repeats the endpoint and does not disclose behavior beyond what annotations already state. It lacks details about the response format, error handling, or any prerequisites, and offers no additional context about the operation's nature.
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 short phrase and therefore concisely front-loads the core action. However, it is so brief that it omits essential explanatory content, yet this is more a completeness issue than a conciseness one.
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 output schema and three parameters, the description is insufficiently complete. It does not explain what the endpoint returns, how message_id and x_track_id relate, or how to choose between this and similar sibling tools, making it hard for an agent to use correctly.
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 each parameter described, so the baseline is 3. The description adds slight emphasis on 'x_track_id' as the key filtering parameter, but dry_run and message_id are not elaborated beyond their schema descriptions.
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 specific HTTP verb and resource ('GET /api/v2/issue/status') and mentions the key parameter 'x_track_id', which aligns with the tool name 'get_delivery_status'. However, it is a terse endpoint reference rather than a full sentence, and does not distinguish this from sibling tools like 'get_package_status' or 'get_ext_status'.
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. The description gives no context on what distinguishes this status retrieval from other status-related sibling tools, leaving the agent to guess.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds no additional behavioral context such as pagination behavior, rate limits, or output format, providing minimal value beyond the annotations.
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, short sentence that states the purpose with no unnecessary words. It is appropriately sized and front-loaded.
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 description is minimal but sufficient for a simple list tool given the annotations and schema. However, without an output schema, it would benefit from mentioning what the list contains or how results are returned, leaving some gaps.
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?
The input schema describes both parameters (limit, category) with 100% coverage, so the description doesn't need to elaborate. The description itself adds no parameter meaning, but the schema already carries the load, meeting the baseline.
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 'Список методов API' clearly states the tool lists API methods. It conveys a specific action and resource, but doesn't explicitly differentiate it from sibling tools like get_endpoint or search_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any context about use cases, prerequisites, or scenarios where this tool is preferred.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the read-only nature is clear. However, the description adds no behavioral context beyond this—it does not mention result format, search behavior, or potential nuances like language or matching rules. Thus, it adds no value beyond the structured annotations.
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, clear sentence with no wasted words. It is front-loaded and directly conveys the core function. It is appropriately concise for a simple tool, though this brevity trades off against completeness.
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 output schema and only two parameters, the description is still too minimal. It does not explain what results to expect, how the search interacts with other doc tools, or what kind of queries are effective. Given the rich set of sibling tools, the description should provide more context to help the agent choose and use it correctly.
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 'query' parameter is described as 'Search query: method, path, keyword' and 'limit' as 'Maximum results'. The tool description itself provides no additional parameter detail, so it relies fully on the schema, which is adequate. Baseline 3 is appropriate.
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 'Поиск по документации API' (Search API documentation) clearly states the tool's purpose with a specific verb (search) and resource (API documentation). It is distinct from sibling tools like search_stop_list, which search a different resource. However, it lacks detail on what aspect of the documentation is searched (e.g., endpoints, parameters, usage examples), making it slightly less specific than ideal.
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?
The description provides no guidance on when to use this tool versus alternatives such as list_endpoints or get_overview. It does not mention any prerequisites, limitations, or specific scenarios, leaving the agent without explicit usage 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?
Annotations already cover destructive/write behavior (destructiveHint=true, readOnlyHint=false), so the description's burden is lower. However, it adds no behavioral context beyond the endpoint; it doesn't explain side effects, task lifecycle, or authentication requirements.
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 no redundancy, making it efficient. However, it is somewhat under-specified, but for conciseness scoring it earns a 4.
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?
This is a creation tool with no output schema, so the description should explain what happens after the task is created or what response to expect. It lacks such context, making it incomplete for operational use.
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%, with the only parameter 'dry_run' already having a description. The tool description adds no additional parameter semantics, so the baseline 3 is appropriate.
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 action 'создать задачу экспорта' (create export task) and provides the endpoint. It distinguishes the tool as a creation operation, though it does not explicitly differentiate it from sibling export tools like stop_list_export_tasks or stop_list_export_download.
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, nor are any prerequisites or context for using it mentioned. The description simply states the action without usage instructions.
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?
The description adds no behavioral context beyond what annotations already indicate. Annotations show destructiveHint=true and readOnlyHint=false, but the description does not mention any side effects, field updates, irreversibility, or required permissions. It merely repeats the verb 'update'.
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, compact phrase with no filler words. It is front-loaded with the HTTP method and resource, making it immediately scannable.
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 mutation tool with no output schema and little contextual detail, the description is lacking. It does not describe the return value, side effects, required fields, or response format. The schema provides field names but not operational context.
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?
All parameters have descriptions in the schema (100% coverage), including example placeholders. The description itself does not add parameter meaning, so the schema carries the full burden. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Обновить обращение' (Update ticket). The HTTP method (POST) and resource path (/api/v2/tickets/:id/) are explicit. This distinguishes it from sibling tools like GET tickets or POST tickets (creation).
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. It simply says 'Update ticket' without explaining when this should be used over api_get_v2_tickets_id or api_post_v2_tickets.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the HTTP method and 'WhiteLabel' context, but does not disclose expected response format, authentication requirements, or any conditional behavior. It goes slightly beyond annotations but does not provide substantial behavioral details.
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 fragment with no redundant words. The 'WhiteLabel (Python SDK parity)' parenthetical is brief but adds useful context about the intended usage. It is appropriately sized, though it omits some semantic clarity that a full sentence might provide.
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 simple parameter set and strong annotations, the description is minimally adequate but sparse. It does not explain what an authkey is, what the response looks like, or any prerequisites. A more complete description would mention that this retrieves the current authkey and perhaps note that it is read-only.
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?
The only parameter dry_run is fully described in the input schema with a Russian-language explanation, covering 100% of schema descriptions. The tool description does not mention parameters, so it relies entirely on the schema. Since schema coverage is complete, the baseline of 3 is appropriate.
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 specifies the HTTP method and resource path (GET /api/v2/authkey), which clarifies it retrieves an authkey. The 'WhiteLabel (Python SDK parity)' hint adds context, but it does not explicitly state what the authkey is or what the response contains. It is distinguishable from sibling create_authkey due to the GET verb and resource name.
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 like create_authkey or get_overview. The 'WhiteLabel' and 'Python SDK parity' hints imply a specific audience but do not offer clear selection criteria or exclusions. The description fails to help an agent decide between this and sibling tools.
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?
Annotations already include destructiveHint=true and readOnlyHint=false, and the description's 'Удалить задачу' (delete task) is consistent with that. However, the description adds no new behavioral context beyond confirming the destructive nature, such as irreversibility, auth requirements, or side effects. It does not contradict annotations.
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, efficient line that conveys the HTTP method, resource, and action. There is no wasted text, and it is appropriately front-loaded for quick understanding.
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 delete operation with one optional parameter and no output schema, the description is adequate but minimal. It does not explain what exactly constitutes a 'task', the effect of deletion, or return behavior, leaving some gaps for an agent to infer.
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?
The only parameter, dry_run, is fully described in the schema ('Показать запрос без отправки на API'), and schema description coverage is 100%. The tool description itself adds no parameter-specific information, so the baseline of 3 applies.
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 'DELETE /api/v2/stop-list/export/:token — Удалить задачу', which clearly identifies the resource (stop-list export token) and the action (delete task). It is specific enough to understand the tool's purpose, though it does not explicitly differentiate from sibling tools like stop_list_export_delete.
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 or how it relates to alternatives. Siblings include stop_list_export_delete and other export-related tools, but the description offers no comparison or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, which the description complements by mentioning 'safety flags' and 'dry_run' capabilities. It also discloses that the tool can be disabled via an environment variable. This adds useful behavioral context beyond the annotations, though it does not detail what the safety flags are.
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, compact sentence that conveys the key points: generic HTTP, API endpoint, safety flags, dry_run, and the environment variable to disable it. It is front-loaded and waste-free, though 'safety flags' is vague and could be more explicit.
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?
This is a generic, potentially destructive HTTP tool with no output schema and 5 parameters including nested objects. The description provides no information about return format, error behavior, or how the response maps to the request. Given the tool's complexity and risk, the description is insufficiently complete.
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?
The input schema has 100% description coverage, with all five parameters already documented (method, path, query, body, dry_run). The description only mentions 'dry_run' which is already in the schema. It does not add additional meaning beyond the schema, so the baseline score of 3 applies.
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 identifies the tool as a generic HTTP client for api.samotpravil.ru, distinguishing it from the numerous specialized sibling tools. It mentions safety flags and dry_run. However, it lacks a specific verb+resource since it is intentionally generic, but the generic nature is itself the purpose.
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 generic tool versus the many specific sibling tools (e.g., send_email, get_statistics). It does not state prerequisites, when not to use it, or that dedicated tools should be preferred. The only hint is the generic label, but no explicit alternatives are mentioned.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description merely restates the action without adding any extra behavioral context such as irreversibility, permission requirements, or side effects. No useful behavioral information is added beyond the structured annotations.
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 that directly states the purpose. There is no unnecessary verbosity or repetition, making it highly efficient and front-loaded.
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 is simple, and the schema plus annotations cover the basic safety and parameter semantics. However, the description lacks any additional context about the effect of removal, return behavior, or when to use it, which would be beneficial given there is no output schema. The information is minimally sufficient 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 description coverage is 100%, as each parameter (email, domain, dry_run, mail_from) has a description. The tool description itself does not explain the parameters, but the schema already provides adequate meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Удалить email из стоп-листа' clearly specifies the action (remove) and the resource (email from stop-list). It distinguishes from sibling tools like add_stop_list_email and search_stop_list by the verb 'remove'.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or other context that would help an agent decide between this and similar tools like search_stop_list or add_stop_list_email.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond that—there is no mention of pagination, authentication, response format, or any operational details. For a list endpoint, such information is absent, providing minimal value beyond the annotations.
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 phrase, containing only the endpoint path and a short label. It is front-loaded and contains no redundant text, earning a perfect score for conciseness and structure.
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 is simple (one optional parameter, no output schema), but the description is extremely terse and lacks essential context such as what the return value represents, whether pagination is supported, or any operational notes. Given that sibling tools exist for detailed operations, this description is incomplete for an agent to understand the tool's full behavior.
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?
The only parameter (dry_run) is fully described in the schema (coverage 100%), so the description need not add parameter details. The baseline of 3 applies because the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the HTTP method (GET), the resource (/api/v2/tickets), and the operation (list requests/appeals). This distinguishes it from sibling tools like api_get_v2_tickets_id (likely fetching a single ticket) and api_post_v2_tickets (creation). The purpose is unambiguous.
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 provides no explicit guidance on when to use this tool versus alternatives. The usage is implied by the endpoint and label, but there are no exclusions or mentions of sibling tools (e.g., 'for a specific ticket, use api_get_v2_tickets_id'). This places it at the baseline for implied usage.
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?
Annotations already mark this as destructive (destructiveHint=true, readOnlyHint=false), and the description adds no additional behavioral context beyond the raw action. It does not mention idempotency, consequences for future email delivery, or any side effects, failing to provide value beyond the structured annotations.
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 without any redundant words. It front-loads the essential information and wastes no space.
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 destructive write operation, the description is minimal and lacks information about consequences, return values, or authorization requirements. However, the simple action, complete parameter schema, and annotations partially compensate for the missing details.
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?
The input schema fully describes all four parameters with 100% coverage, so the description adds no extra semantic meaning. The baseline of 3 is appropriate since the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'добавить' (add) and a clear resource 'email в стоп-лист' (email to stop list), distinguishing it from sibling tools like remove_stop_list_email and search_stop_list. The action is unambiguous and immediately understandable.
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 states the action but provides no explicit guidance on when to use this tool versus alternatives such as remove_stop_list_email or search_stop_list. The usage is implied by the name and sibling context, but there are no stated exclusions or when-not-to-use scenarios.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is known. The description adds no extra behavioral context such as which specific stop lists are searched, whether the result is a boolean or a list, or any rate limits or auth requirements. It merely restates the operation without adding nuance.
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, front-loaded sentence that captures the essence of the tool without any wasted words. It is maximally concise while still being informative.
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 is simple and the schema + annotations cover the safety profile and parameters. However, without an output schema, the description does not clarify what the response indicates (e.g., whether it returns a boolean presence or matching list names), which would be useful for an agent. This is a notable gap.
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%, with both 'email' and 'dry_run' having clear descriptions in the input schema. The tool description itself provides no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Поиск email в стоп-листах' clearly states a specific action (search) and resource (email in stop lists). It effectively distinguishes this tool from sibling operations like 'add_stop_list_email' or 'remove_stop_list_email', which mutate the lists, and other search tools like 'search_docs'.
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 the tool is for checking if an email is present in stop lists, but it does not explicitly state when to use it versus alternatives or provide any exclusion criteria. No alternative tools are mentioned, though the name is self-explanatory.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, signaling a safe read operation. The description adds the HTTP method and path but does not disclose response format, potential errors, authentication needs, or any side effects. It does not contradict the annotations, but it contributes minimal extra behavioral context.
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 line: 'GET /api/v2/tickets/:id/ — Отдельное обращение'. It contains no redundant words, every element serves a purpose, and it is immediately scannable. This is a model of brevity.
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 description is incomplete for reliable agent use. It does not explain how the ticket ID is supplied, what the response contains, or when to use this tool versus the list or POST variants. The absence of an output schema makes the missing return-value information particularly problematic. While annotations cover safety, the tool's core semantics are underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents only 'dry_run' with a complete description, giving 100% coverage for that parameter. The description adds the endpoint pattern with an ':id' placeholder, which is not present in the schema and gives a clue that a ticket ID is needed. However, it does not explain how to provide the ID, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as a GET request to /api/v2/tickets/:id/ and labels it as 'Отдельное обращение' (single ticket). The tool name and path make it distinct from the list endpoint (api_get_v2_tickets) and the POST variant (api_post_v2_tickets_id), so the purpose is specific and well-differentiated.
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?
The description provides no explicit guidance on when to use this tool or when to prefer alternatives. There is no mention of use cases, prerequisites, or situations where the list or POST endpoints would be more appropriate. The intended usage is only implied by the endpoint path and tool name.
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?
Annotations already declare readOnlyHint=false and destructiveHint=true, which communicate that this is a destructive write operation. The description adds no further behavioral context, such as side effects, required permissions, or irreversibility, so it does not go beyond what annotations already convey.
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, direct sentence that specifies the HTTP method and path, and states the purpose. There is no redundancy or unnecessary information, making it highly concise and well-structured.
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 tool with 6 parameters, no output schema, and a destructive annotation, the description is too sparse. It does not explain the response format, side effects, or any operational context, leaving the agent without essential information to invoke the tool correctly.
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%, as every parameter has a description (albeit minimal, with examples like 'Поле тела (пример: "standard")'). The tool description itself does not add any parameter semantics, so the score is at the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Создать обращение на выделенный IP' (create a ticket for a dedicated IP), using a specific verb and resource. The phrase 'выделенный IP' distinguishes it from the sibling tool api_post_v2_tickets, which is likely for general tickets.
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 for creating tickets about dedicated IPs, but it does not explicitly state when to use this tool over alternatives like api_post_v2_tickets. No exclusions or conditional guidance are provided, so the usage context is only implied.
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:

[![samotpravil-api-mcp MCP server](https://glama.ai/mcp/servers/dkanster/samotpravil-api-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dkanster/samotpravil-api-mcp)

Score Badge

Copy to your README.md:

[![samotpravil-api-mcp MCP server](https://glama.ai/mcp/servers/dkanster/samotpravil-api-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dkanster/samotpravil-api-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/dkanster/samotpravil-api-mcp'

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