alopeyk-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Tools are clearly separated by prefix (alopeyk_ vs alonomic_) and each has a distinct purpose. Even within groups, tools like alopeyk_get_price and alopeyk_get_batch_price are well-differentiated. Overlap is minimal.
Naming Consistency4/5
The majority follow a verb_noun pattern with consistent prefixes. However, a few tools (healthcheck, list_instances, alopeyk_payment_route, alopeyk_print_invoice_url) break the pattern, causing minor inconsistency.
Tool Count4/5
34 tools is on the higher side but reasonable for a server covering two distinct service APIs with full CRUD and utility operations. Each tool earns its place without unnecessary duplication.
Completeness3/5
The tool set covers core operations for both Alopeyk and Alonomic services, but lacks listing tools for orders and parcels. Agents cannot retrieve a list of existing orders or parcels, which is a notable gap.
Average 4.1/5 across 34 of 34 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool is read-only and lists sizes, but does not disclose authentication needs, rate limits, error behaviors, or what happens if the instance parameter is omitted. Minimal disclosure beyond the obvious.
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?
Description is concise: 6 lines covering purpose, Persian translation, API mapping, and parameter explanation. No unnecessary words, but the structure could be improved by grouping related information. Still, it is well within acceptable length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, read-only list), the description is mostly complete. It specifies the number of items (12) and dimensions. The existence of an output schema reduces the need to detail return values. Brief but adequate for basic usage.
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 0%, so description must add meaning. It explains the 'instance' parameter as a configured instance to use, with a default when omitted. This provides some context beyond the schema, but is brief and does not elaborate on how the instance is used or what constitutes a valid instance.
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?
Clearly states it lists standard parcel box sizes and is read-only. Specifies the API endpoint and mentions it returns 12 box sizes with dimensions. Distinguishes from sibling tools like create/update/cancel by being read-only.
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 explicit guidance on when to use this tool vs alternatives. Only mentions it is read-only, but does not state when to choose it over other parcel-related tools. Lacks when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It notes 'read-only' but does not disclose authorization needs, rate limits, or behavior when no addresses exist.
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 short and includes only necessary info, with a clear args list. However, the Persian line may be redundant for an English-speaking agent.
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 output schema exists and the tool is simple, the description is adequate for listing addresses but lacks completeness on behavioral context (e.g., pagination, error states).
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 0%, so description must add meaning. It explains the 'instance' parameter as 'Configured instance to use (default when omitted)', providing context beyond the schema but not specifying types or allowed values.
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 'List saved pickup addresses (read-only)', which is a specific verb+resource. It distinguishes from sibling tools like add or delete saved addresses.
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 listing addresses but lacks explicit when-to-use or when-not-to-use guidance. No mention of alternatives or exclusions.
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?
Without annotations, the description carries the burden. It states read-only and maps to a GET endpoint, but does not disclose permissions, rate limits, or what happens if the parcel does not exist.
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 extremely concise, with a clear purpose in the first sentence and a single additional sentence for parameters. No wasted words.
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 presence of an output schema reduces the need to describe return values. However, the description lacks context about when this tool is appropriate relative to many sibling tools and does not address error conditions or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add value. It describes parcel_id as 'numeric id' and instance as 'configured instance'—these are slightly informative but still vague, especially for instance, which defaults to null.
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 retrieves one business parcel by ID and is read-only. It effectively distinguishes from sibling tools like create, cancel, and update, which involve mutations.
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 use for fetching parcel details but provides no explicit guidance on when to use this tool versus alternatives (e.g., alopeyk_get_order). No exclusions or prerequisites are mentioned.
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?
With no annotations, the description carries the full burden. It clearly states 'no network call' (safe read operation) and that it returns a URL. No side effects mentioned, but for a simple URL builder, this is sufficient.
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 concise with an Args section, but includes a redundant Persian phrase. Still, every sentence serves a purpose and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and minimal schema, the description covers the tool's core behavior (URL building, no network call) and parameters. Output schema exists, so return value explanation is not needed. Adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does so minimally: 'order_id: Numeric id' and 'instance: base URL'. Adds meaning beyond the schema's titles but could be more detailed (e.g., token source).
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 verb ('Build') and resource ('printable invoice URL'), and distinguishes it from siblings like 'alopeyk_tracking_url' by specifying it's for invoices. The Persian purpose adds clarity.
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 explicit guidance on when to use this tool versus alternatives or when not to use it. The description only mentions 'no network call', but does not compare to other URL-building or order-related tools.
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?
The description explicitly states the tool is 'read-only' and 'Requires an access_token', which are key behavioral traits. With no annotations provided, the description carries the transparency burden and does so reasonably well. However, it does not mention response format or error conditions, which would enhance trust.
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 concise and front-loaded with the main purpose. It includes a Persian translation for localization but remains efficient. The structure is logical: purpose, requirements, API mapping, then parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description need not detail return values, but it omits information like whether the coupon is valid or expired, or error handling. While adequate for a simple validation tool, it lacks completeness regarding what the agent can expect from the response.
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 input schema has 0% description coverage, so the description must compensate. For 'code', it merely restates the parameter name ('The coupon code to validate'), adding no meaningful detail. For 'instance', it adds context ('Configured instance to use (default when omitted)') but fails to fully clarify the parameter's purpose or allowed values.
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 'Validate a discount coupon code (read-only)' and includes a Persian translation for context. It specifies the verb 'validate' and the resource 'coupon code', and distinguishes itself from sibling tools like alopeyk_create_order or alopeyk_get_price, which have different purposes.
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 validating coupon codes but does not explicitly state when to use it versus alternatives or when not to use it. It provides no exclusions or guidance on scenarios, leaving the agent to infer usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'no network call' and returns a URL, but fails to disclose authentication needs, rate limits, failure modes, or whether the URL has expiration. This is insufficient for safe invocation.
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 front-loaded with a clear one-line summary, but the Persian line adds redundancy without value for an English-speaking agent. The Args block is well-structured, but overall it could be trimmed.
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 presence of an output schema, return values need not be explained. However, the description does not mention prerequisites like authentication or that the instance must be fetched from 'list_instances', which is a sibling. The 'instance' parameter is ambiguous without that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds detailed explanations for each parameter: user_id (numeric id), amount (in account currency), gateway (with two options), and instance (configured instance). It also specifies defaults. This greatly enhances understanding beyond the schema.
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 it builds a wallet top-up payment route URL and is not a network call. The verb 'build' and resource 'payment route URL' are specific, and the tool is distinct from siblings like order-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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it returns a URL for a selected gateway without sending a request. However, it does not explicitly exclude alternatives or state when not to use it, though siblings do not overlap significantly.
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?
With no annotations, the description notes the tool is read-only and maps to a GET endpoint, providing basic behavioral context. However, it omits details about rate limits, error handling, or any constraints on the data returned.
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 concise and front-loaded with the main purpose. The inclusion of a Persian translation is extra but not harmful. The structure is clear and efficient, though the Persian line is redundant for English agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and an output schema, the description covers the essential information: purpose, param, and read-only nature. It does not describe the output format, but the output schema compensates. Overall adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'instance' is briefly explained as 'Configured instance to use (default when omitted)', which adds some meaning beyond the schema's type definition. However, with 0% schema description coverage and only one parameter, a more detailed explanation of 'instance' values or defaults would improve clarity.
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 it gets working pickup days for today/tomorrow and specifies it is read-only. It also provides the API endpoint, distinguishing it from siblings like 'alonomic_get_days_index' which likely serves a different purpose.
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 retrieving current and next day's pickup slots but does not explicitly state when to use this tool versus alternatives like 'alonomic_get_days_index' or other scheduling tools. No exclusions or context are provided.
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?
No annotations exist, so the description carries full burden. It explicitly labels the tool as 'read-only', maps to a GET endpoint, and indicates data structure. This is sufficient for basic transparency, though rate limits or auth aren't mentioned.
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?
Compact and well-organized: main English purpose, Persian translation for locale, endpoint reference, data shape, and argument docs. No wasted words, but could be slightly more structured with separate sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need no description. The description covers purpose, data shape, endpoint, and parameters. It is largely complete for a simple read tool, though clarity on sibling differentiation is missing.
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?
With 0% schema description coverage, the description adds value by explaining the 'instance' parameter as 'Configured instance to use (default when omitted).' However, it remains brief and does not elaborate on instance selection or behavior beyond defaults.
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?
Clearly states it retrieves the next 7 days with same/next-day availability, provides the API endpoint, and describes the shape of each day object as {same: bool, next: bool}. This goes beyond a simple verb+resource to include scope and data structure.
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?
No explicit guidance on when to use this tool versus siblings like alonomic_get_days. The 'read-only' hint implies it should be used for non-mutative queries, but lacks direct comparisons or exclusions.
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?
With no annotations, the description carries full burden. It discloses that no network request is sent and the tool is static. It also explains the instance parameter is ignored. This is transparent for a simple static tool, though it could note if there are any limits.
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 concise at two lines plus an args section, but includes a redundant Persian phrase. Still, it is front-loaded with the core action and efficiently communicates key behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, static data), the description covers purpose, parameter semantics, and return type. An output schema exists, so not explaining return values is acceptable. It is adequately complete.
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?
Schema description coverage is 0%, but the description adds meaning to the only parameter: 'instance' is explained as 'Accepted for symmetry; ignored (static data)'. This goes beyond the schema's bare typing and default value.
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 verb 'List' and the resource 'cities served by Alopeyk On-Demand'. It differentiates from siblings by emphasizing 'static, no network', which distinguishes it from tools that make network requests. The return type (list of city slugs) is explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While it states 'static, no network' implying safety, it does not mention when not to use it or compare to sibling tools like alopeyk_get_address or alopeyk_location_suggestion.
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?
With no annotations, the description adds some behavioral context (e.g., not gated by enable_ordering, HTTP 204 on success). It does not cover error conditions, idempotency, or side effects beyond deletion.
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 concise and well-structured, with key information upfront. The Persian line may be extraneous for an English-speaking agent but does not detract significantly.
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 covers core functionality but omits details like error handling, authorization requirements, and output expectations (though output schema exists). Given the tool's simplicity, it is adequate but not thorough.
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?
Despite 0% schema coverage, the description adds meaningful context for both parameters: 'Numeric id of the saved address to delete' and 'Configured instance to use.' This goes beyond the schema's type and default information.
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 action ('Delete a saved pickup address') and resource, includes a Persian translation, and maps to the HTTP DELETE endpoint. It distinguishes from sibling tools like add or get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that the tool is not gated by enable_ordering, helping the agent understand when it applies. However, it does not explicitly state when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It discloses the GET mapping and token requirement, suggesting idempotent read behavior. However, it lacks explicit statements about side effects, rate limits, or idempotence.
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 efficient: two sentences plus a bulleted Args list. The main purpose is front-loaded, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not detail return values. It covers all three parameters, the API method, and authentication. Minor gaps: no example usage or formatting guide, but overall sufficient for a simple reverse geocoding tool.
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?
Schema description coverage is 0%, but the description adds meaning via the Args section: 'lat: Latitude (-90..90), lng: Longitude (-180..180), instance: Configured instance to use.' This provides range and purpose beyond the schema's titles and types.
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 'Reverse-geocode a coordinate to a human-readable address,' which is a specific verb and resource. The Persian purpose and API endpoint further clarify. It distinguishes from siblings like alopeyk_location_suggestion.
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 mentions 'On-Demand, requires an access_token' and maps to a GET endpoint, implying usage context. However, it does not explicitly state when to use this tool versus alternatives like alopeyk_location_suggestion or alonomic_get_addresses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly labels the operation as read-only and notes the API endpoint, but does not disclose error states, rate limits, or authentication failure behavior.
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 very concise, front-loading the purpose and including relevant details like the Persian translation and API mapping without unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description adequately covers the operation. It mentions the endpoint, required authentication, and what data is retrieved, missing only potential edge cases or usage constraints.
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?
With 0% schema coverage, the description must compensate. It explains the single 'instance' parameter briefly ('Configured instance to use'), which adds value but lacks detail on what instance represents or allowed values.
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 it retrieves the authenticated user's profile and wallet credit, with a read-only nature. It maps to a specific API endpoint, distinguishing it from other tools that fetch orders or addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that an access_token is required, but does not explicitly state when to use this tool over alternatives. However, the context of being a simple profile fetch makes usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates a POST mapping and 'Save a new pickup address,' implying creation. It does not disclose error conditions, idempotency, side effects, or permissions beyond the absence of the enable_ordering gate.
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?
Purpose stated first, then endpoint, then parameter list. The Persian sentence is redundant for English agents but does not harm clarity. The parameter list is well-organized but slightly long. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, 0% schema coverage, no annotations, and an output schema (context indicates it exists), the description adequately covers the tool's function and parameter semantics. It does not explain output, but output schema presumably handles that. No major gaps.
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?
Schema description coverage is 0%, so the description carries full burden. It lists all 10 parameters with brief but helpful explanations (e.g., lat: 'Latitude (-90..90)' adds constraint, address: 'Free-text street address'). While not exhaustive, it adds meaningful context beyond the schema's names and types.
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 'Save a new pickup address,' specifies the endpoint, and distinguishes this address-book operation from delivery tools. It explicitly mentions it is not gated by enable_ordering, separating it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use (address book, not delivery) and explicitly says 'NOT gated by enable_ordering,' giving context on prerequisites. However, it does not explicitly compare to sibling tools like alonomic_delete_saved_address or alonomic_get_saved_addresses, nor provide 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Warns about destructive nature upfront, explains API endpoint, specifies that only passed fields are sent, and describes error behavior. With no annotations, the description effectively discloses key behaviors.
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?
Well-structured with warning, purpose, and Args section. Persian translation is slightly extraneous but not detrimental. Generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers mutation behavior, prerequisites, error handling, and parameter roles. Output schema exists, so return values need not be detailed. Complete enough 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?
Lists all parameters with brief descriptions (e.g., 'Numeric id', 'Optional updated drop-off object'). Schema coverage is 0%, so description adds some meaning but lacks details about object structures.
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?
Clearly states 'Update a parcel before final send' with a warning that it changes a real parcel. Maps to PUT endpoint. Distinguishes from siblings like create_parcel and cancel_parcel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites (Alonomic credentials, enable_ordering=true, read_only=false) and notes error condition if disabled. Does not explicitly name alternative tools but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description states it returns offline documentation without network calls, but does not mention idempotence, caching, or data freshness. More explicit safety guarantees would improve 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 well-structured with a purpose line, explanation, and args/returns. It is concise but includes all necessary details, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple documentation tool with one optional parameter and an output schema, the description covers usage well. It mentions the return format as a dict with service metadata and tool documentation, which combined with the output schema is sufficient.
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 only parameter 'topic' is clearly explained: it is an optional tool name to fetch docs for a single tool, and omitting returns the full overview. Schema has 0% description coverage, so the description adds necessary meaning.
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 returns offline documentation about Alopeyk services and tools. It includes a Persian purpose line and explains usage, distinguishing it from sibling API tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this to learn about Alopeyk without network calls and explains when to provide a topic vs. omit. While it doesn't explicitly say when not to use or compare alternatives, the context makes it clear.
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?
With no annotations, description must disclose behavior. It correctly states read-only and no order creation, but does not cover potential rate limits, error handling, or side effects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with key info front-loaded. Two short paragraphs plus bullet. Could be more structured but no excess words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch pricing tool with an output schema, it covers the limit, order shape, read-only nature, and auth requirement. Lacks mention of error scenarios but is largely complete.
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?
Schema coverage is 0%, but description adds meaning: orders must be max 15 objects shaped like alopeyk_get_price body (transport_type + addresses + flags). Instance parameter is explained as 'Configured instance to use (default when omitted).'
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 it calculates prices for up to 15 orders in one call and is read-only. It distinguishes itself from alopeyk_get_price (single order) and alopeyk_create_order (creates orders) by saying 'This does NOT create orders.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions read-only, requires access_token, and max 15 orders. It implicitly compares to alopeyk_get_price for batch vs single, but does not explicitly state when not to use or list alternatives beyond that.
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?
With no annotations, the description fully bears the burden. It declares the tool as 'read-only', requires an access_token, and outlines the return type (service-wide settings). No contradictions. Missing details on rate limits or error behavior, but adequate for a simple getter.
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 concise with a clear structure: purpose, Persian line, endpoint, return summary, and args. The Persian line adds minor bloat but does not harm. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not detail return values, but it already summarizes them well. It covers auth, parameters, and endpoint. Slightly missing error scenarios, but overall sufficient for the tool's simplicity.
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 schema has 0% description coverage, so the description must compensate. It explains the single optional parameter 'instance' as 'Configured instance to use (default when omitted)', clarifying its role and default behavior beyond the schema's type anyOf.
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 'Get the On-Demand service configuration (read-only)' and provides the endpoint, distinguishing it from sibling tools that handle orders, profiles, cities, etc.
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 mentions the prerequisite of an access_token and implies it is for reading configuration, but does not explicitly specify when to use this over alternatives or provide when-not scenarios. Sibling tools are not compared.
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?
With no annotations, the description must carry the burden. It states read-only and non-creating behavior, and lists response fields, but does not disclose auth needs, rate limits, or other side effects. Adequate but not rich.
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?
Efficiently conveys purpose, endpoint, and parameter details in a short paragraph. Front-loaded with main purpose. Could be slightly more concise, but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description only needs to highlight key return fields, which it does. Covers all parameters with adequate detail for a nested-object tool. Leaves little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates fully by explaining each parameter's content (drop address structure, parcel fields, optional pickup details, instance). Adds meaning beyond vague schema types.
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?
Description states specific verb 'Estimate' and resource 'parcel's price and dimensions', and explicitly says 'read-only' and 'Does NOT create a parcel', clearly distinguishing from sibling 'alonomic_create_parcel'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the tool is read-only and does not create a parcel, providing clear context for when to use (estimation) vs. alternative creation tools. However, lacks explicit when-not or other alternative names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it caches the token in memory, never returns the token, calls POST /business-service/api/v1/login, and handles a pre-issued token scenario. The return structure is detailed.
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 reasonably concise, with key information front-loaded. The Persian repetition adds a minor redundancy but does not significantly detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (mentioned) and the description covers input, endpoint, caching, return keys, and error behavior, it is complete for the tool's complexity.
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 0%, so the description must compensate. It adds a brief explanation for the 'instance' parameter ('Configured instance to log in (default when omitted)'), but this provides only basic context and no further 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 states 'Log in to Alonomic and cache the token (no token leaked).' It specifies the verb (login) and resource (Alonomic), and this tool is the only login tool among siblings, distinguishing it effectively.
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 before other Alonomic calls but does not explicitly state when to use or not use this tool. No alternatives are mentioned, so guidance is minimal.
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?
With no annotations, the description must disclose behavior. It states the HTTP method (GET) and mentions it's on-demand with token requirement. However, it does not explicitly say it is read-only or describe any side effects. The description is adequate but could be more explicit about safety (e.g., non-destructive).
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 concise, with three short sentences plus an Args section. It front-loads the main purpose and includes a Persian translation and HTTP mapping. Every sentence adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signals indicate 'Has output schema: true'), the description does not need to detail return values. It covers the input parameters, endpoint, and authentication requirement. It is complete for an autocomplete tool, though it could mention that results are suggestions to match user input.
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?
Schema coverage is 0%, so the description must compensate. It explains all three parameters: input (partial address/place name), latlng (optional bias), and instance (default). This adds meaning beyond the schema's type definitions. The explanations are clear and sufficient for an agent to use the parameters correctly.
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 provides autocomplete address suggestions for a free-text query. It specifies the verb (autocomplete) and resource (addresses). The Persian text and HTTP endpoint further clarify the purpose, and it is easily distinguished from siblings like alopeyk_get_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it requires an access_token and is on-demand, which guides when to use it. It does not explicitly state when not to use it, but the autocomplete nature and optional latlng bias provide sufficient context. No explicit alternatives are given, but the sibling list is available.
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?
No annotations are provided, so description carries the full burden. It appropriately declares read-only behavior, authentication requirement, and the rich columns set returned. However, it does not disclose error handling or rate limits.
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?
Description is concise, starting with a clear purpose, followed by useful auxiliary information (Persian, endpoint mapping), and structured with an 'Args:' section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, full return value details are not needed. The description covers purpose, parameters, authentication, and the rich columns set. It is adequate but could mention when to fetch instead of list or search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explicitly listing both parameters (order_id and instance) with clear explanations, including data type and default value for instance.
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?
Description clearly states 'Get one order with rich columns' and includes Persian purpose and endpoint mapping, making the tool's action and scope unambiguous. It effectively distinguishes from sibling tools like alopeyk_cancel_order or alopeyk_create_order.
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?
Description mentions read-only and requires access_token, but does not explicitly state when to use this tool versus alternatives like aget_address. Usage context is implied but not fully detailed with exclusions.
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?
With no annotations, the description fully discloses the behavior: requires access_token, calls a specific endpoint, returns success indicator or structured error. It lacks mention of rate limits or side effects, which are minimal for a health check.
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 concise, front-loaded with the primary purpose, includes a secondary language line, then details on endpoint, auth, and return value. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check tool with one optional parameter and an output schema, the description covers all essential aspects: purpose, endpoint, auth, return value, and parameter meaning. It is complete given the tool's simplicity.
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 provides only type and default for 'instance'. The description adds semantic meaning: it names the Alopeyk instance and explains the default behavior. This compensates for the 0% schema description 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 that the tool checks if Alopeyk is reachable via a lightweight call, specifies the endpoint, and explains the return value. This distinguishes it from siblings like 'alopeyk_get_config' which likely returns more detailed data.
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 clear context on when to use (health check) and mentions authentication requirement, but does not explicitly state when not to use or suggest alternatives among siblings. Adequate but not complete guidance.
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?
With no annotations, the description reveals key behavioral traits: it changes a real parcel (destructive), maps to a DELETE operation returning HTTP 204, and requires specific conditions. It does not mention idempotency or rate limits, but provides sufficient insight for safe use.
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 compact, starting with purpose and warning, then prerequisites, HTTP mapping, and parameter docs. Every sentence adds value, and the Persian translation is a nice touch without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existence of an output schema, the description covers purpose, prerequisites, error cases, and parameters. It does not discuss idempotency or retry behavior, but overall it is sufficiently complete for a cancel operation.
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?
Schema coverage is 0%, so the description adds meaning by explaining parcel_id as numeric id and instance as configured instance with default. While brief, it provides necessary context beyond the schema types.
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 cancels a parcel before pickup, using specific verbs and resource. It distinguishes from sibling tools like alonomic_create_parcel or alonomic_get_parcel by explicitly focusing on cancellation before pickup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear prerequisites (credentials, enable_ordering=true, read_only=false) and explains the error response when prerequisites are not met. However, it does not explicitly state when not to use this tool compared to alternatives (e.g., after pickup or using other cancel tools).
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?
With no annotations, the description carries full burden. It discloses destructive nature, disabled state return, and underlying HTTP method. Could mention reversibility or side effects, but covers essential behavioral traits.
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?
Front-loaded with warning and purpose. Args section is clear. Slightly lengthy but every sentence adds value. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, parameter details, and API mapping. Missing description of return value, but output schema exists. Adequate for a cancellation tool with given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains each parameter: order_id as numeric, comment as required reason, instance as optional with default. Adds meaning beyond schema types.
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 'Cancel an order' with a warning about real delivery. It distinguishes itself from sibling tools like 'alonomic_cancel_parcel' by specifying it's for Alopeyk orders. Includes Persian purpose and API endpoint mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns about destructive action and states prerequisites (access_token, enable_ordering, read_only). Tells agent when the tool will fail. However, no direct comparison to siblings like 'alopeyk_finish_order' for alternative usage.
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?
Without annotations, the description warns 'WARNING: real delivery', implies the action is terminal, and details the HTTP mapping and error conditions. This sufficiently discloses the tool's impact.
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 moderately long but well-structured: purpose, warning, prerequisites, HTTP mapping, and arg list. Each sentence adds value, though the Persian repetition slightly lengthens it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 4 parameters, the description covers purpose, prerequisites, HTTP details, and parameter semantics. It is complete enough for an ordering tool, though output schema is not described (but exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains each parameter: order_id is numeric and required, comment is optional free-text, rate is optional 1-5, instance defaults when omitted. This adds significant meaning beyond the schema.
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 'finishes/closes an order, optionally rating it' and provides the Persian purpose. It explicitly maps to a POST endpoint, distinguishing it from sibling tools like 'alopeyk_cancel_order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites: requires access_token, enable_ordering=true, and read_only=false, and warns that otherwise an error is returned. It does not explicitly contrast with siblings, but the purpose alone makes it clear when to use this tool.
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?
With no annotations, the description declares it as read-only, mentions the endpoint, and lists response fields. It does not discuss rate limits or detailed auth, but adequately conveys safety for a price calculator.
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 well-structured with a lead sentence, clarification, endpoint, response, and parameter args. While slightly long, every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (response fields listed), the description covers return values and refers to a sibling tool for transport types. It lacks some address format detail but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates excellently by explaining each parameter: transport_type with examples, addresses with structure, and defaults for others.
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 'Calculate the price for a delivery between stops (read-only)' and explicitly states it does NOT create an order, distinguishing it from alopeyk_create_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes that it does not create an order and requires an access_token, but does not directly compare to alternatives like alopeyk_get_batch_price. The sibling context helps infer usage.
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?
Since no annotations are provided, the description carries full burden. It warns of billing and explains the error response when ordering is disabled. It does not mention side effects like irreversibility, but the warning about 'real business parcel' implies a permanent mutation. Overall transparent enough.
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 well-organized with a bold warning, Persian text, endpoint mapping, and structured Args. It is informative but slightly verbose; could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 6 parameters, nested objects, and no schema descriptions, the description is comprehensive. It covers all necessary information: purpose, preconditions, error handling, parameter structures, and endpoint. The presence of an output schema further reduces burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully explains each parameter. The Args section provides detailed structure for drop, parcel, pickup, delivery_proofs, parcel_extra_params, and instance, including nested objects and optional fields. This exceeds what the schema alone offers.
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 verb ('Create') and resource ('REAL business parcel'), and includes a warning about billing. It distinguishes from siblings such as alonomic_calc_parcel (calculation vs. creation) and alonomic_update_parcel (update vs. create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites: Alonomic credentials, enable_ordering=true, read_only=false. It also warns about billable nature. Although it doesn't explicitly state when not to use it, the precondition effectively guides usage. Could mention alternatives like alonomic_calc_parcel for non-billable estimates.
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?
No annotations provided, so description takes full burden. Declares read-only, implicit login, endpoint mapping, and return fields. Lacks error handling or rate limits but sufficient for a simple retrieval.
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?
Very concise: two lines of English, Persian translation, endpoint, return fields, and parameter explanation. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers all needed: purpose, usage, parameter, return values. Complete for a simple read-only tool.
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?
Schema has one parameter 'instance' with no description. The description adds 'Configured instance to use (default when omitted)', clarifying its purpose and optionality. Schema coverage 0% makes this addition valuable.
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?
Description clearly states 'Get the Alonomic business account profile and credit (read-only)'. Provides Persian translation and endpoint mapping, leaving no ambiguity. Distinct from sibling tools like alonomic_login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'Logs in implicitly if needed', giving context on when to call. However, no explicit when-not-to-use or comparison to alternatives beyond the read-only nature.
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?
With no annotations, description discloses key traits: billable, dispatches courier, charges account, error if ordering_disabled. Missing details on idempotency or cancellation, but adequate for a creation tool.
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?
Well-structured with warning, purpose, prerequisites, then parameter details. Front-loaded with critical info. Slightly verbose in repeating defaults that schema already provides, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisites, parameters, error conditions, and usage guidance. Output schema exists, so return values need not be described. Complete for a billable ordering tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are described with meaning, constraints, and examples (e.g., addresses format, transport_type values). Compensates fully for 0% 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?
Description clearly states it creates a real delivery order (billable), maps to POST /api/v2/orders, and distinguishes from siblings like alopeyk_get_price and alopeyk_cancel_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: requires access_token, enable_ordering=true, and advises to confirm addresses/price via alopeyk_get_price before calling. Does not explicitly state when not to use, but context is sufficient.
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?
No annotations are provided, so the description carries the full burden. It discloses that the operation is local (no network call), returns a formatted URL, and uses environment-specific base. It also includes a Persian note. This provides adequate behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single main sentence, a Persian note, a format line, and two bullet-point args. Every sentence adds value, and it is front-loaded with the key purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (marked true), the description does not need to detail return values. It covers purpose, behavior, parameters, and special notes (no network call, Persian purpose). For a simple URL-building tool, this is complete and sufficient.
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?
Schema description coverage is 0%, but the description compensates by explaining each parameter: order_token is the tracking token from a created order, instance is the configured instance to derive the base URL. This adds meaningful context beyond the bare schema types.
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 specifies the verb 'build', the resource 'public tracking URL', and the input 'order token'. It distinguishes from network calls by stating 'no network call'. Compared to siblings, this tool uniquely constructs a URL without a remote request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use (to build a tracking URL from an order token) and that it makes no network call, implying it's low-cost. However, it does not explicitly mention when not to use or provide direct alternatives among siblings.
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?
With no annotations, the description carries the full burden. It discloses that no network request is sent ('static, no network') and that the parameter 'instance' is ignored. However, it does not mention authentication requirements or potential side effects, though these are minimal for a static list.
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 extremely concise: two short sentences plus a Persian translation and a brief parameter note. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose, static nature, and parameter meaning. Since an output schema exists (not shown), it does not need to detail return values. It is complete for an agent to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'instance' is minimally described in the schema (type only). The description adds critical context: it is 'Accepted for symmetry; ignored (static data)', which clarifies its irrelevance and prevents misuse.
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 'List the available transport (vehicle) types' and explicitly notes it is 'static, no network', distinguishing it from sibling list tools that may fetch dynamic data. It also mentions its role in pricing/order tools, providing precise context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool returns transport types used by pricing/order tools, implying when to use it. While it does not explicitly exclude alternatives, the 'static, no network' flag helps differentiate from network-dependent sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it never returns credential values, only booleans indicating configuration. It lists the exact fields returned in the output, providing complete 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 concise with a few sentences, includes a Persian purpose that may not be necessary but doesn't harm clarity. It is well-structured with a clear return format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and the output schema is described, the description is fully complete for an agent to understand what the tool does and what to expect.
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 schema provides full coverage. The description adds no extra parameter information, which is acceptable at baseline 4.
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 lists configured Alopeyk instances and specifies it returns no secrets. It differentiates itself by noting it is useful for discovering which instance values other tools accept, which distinguishes it from siblings like alopeyk_get_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the tool is 'useful for discovering which instance values the other tools accept', giving a clear usage context. It does not explicitly mention when not to use it or alternatives, but the use case is straightforward and no sibling directly overlaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses behavior: it is static, no request is sent, and the instance parameter is ignored. This gives the agent complete transparency about the tool's side effects (none) and behavior.
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 concise with no wasted words. The first sentence provides the core purpose, followed by a Persian translation and clear parameter explanation. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers all necessary aspects: purpose, behavior, parameter semantics, and return type. No gaps are apparent.
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 description adds meaning to the single parameter 'instance' by explaining it is accepted for symmetry and ignored, which goes beyond the schema's type/default info. With 0% schema description coverage, this is valuable semantic context.
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 lists Alonomic parcel status codes and Persian labels, returning a static map. It distinguishes well from siblings which handle parcel creation, calculation, cancellation, etc., by specifying it's a static mapping with no request sent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (if you need status codes/labels) and indicates it's static and safe, but does not explicitly mention when not to use or provide alternatives. The context of sibling tools suggests alternatives for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: listing is GET, buying is POST, buying spends loyalty points/credit, requires enable_ordering and read_only=false, and returns error if gated. Also mentions access_token requirement.
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 well-structured with a summary, Persian purpose, technical mapping, and args. However, it is slightly verbose (e.g., Persian purpose may be redundant for an English AI agent).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description covers input behavior comprehensively: listing, buying, gating, and error cases. It is complete enough 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explains each parameter: product_id is optional but required when buy=true, buy is a boolean defaulting to false, instance is default when omitted. This adds significant meaning beyond the schema.
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 lists or buys loyalty products, using specific verbs like 'list' and 'buy'. It distinguishes itself from siblings (e.g., alopeyk_create_order) by focusing exclusively on loyalty products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to list (buy=false) vs buy (buy=true), including the gating condition enable_ordering=true for buying. It does not explicitly compare with alternatives, but the domain loyalty products is well-defined.
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:

[![alopeyk-mcp MCP server](https://glama.ai/mcp/servers/dwin-gharibi/alopeyk-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dwin-gharibi/alopeyk-mcp)

Score Badge

Copy to your README.md:

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

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