coronium-proxy-mcp

Official

by coroniumio

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation4/5
Most tools have clearly distinct purposes, but a few pairs like restart_modem vs rotate_modem and list_pool_sessions vs list_pool_keys could be confused without reading descriptions. The consistent resource-oriented naming helps overall, but the large number of overlapping lifecycle actions creates minor ambiguity.
Naming Consistency5/5
All tools follow a strict coronium_<verb>_<noun> pattern, with predictable verbs like list, get, set, create, cancel, and buy. This consistency makes it easy to guess tool behavior and reduces cognitive load despite the large count.
Tool Count2/5
At 48 tools, this server is far beyond the typical well-scoped count of 3-15, and even exceeds the 25+ threshold for 'too many.' While the API serves a broad domain, the sheer number of tools imposes a heavy selection burden on agents and suggests the surface could be consolidated or split into separate servers.
Completeness5/5
The tool set covers the full lifecycle for modems, proxies, pool keys, account management, payments, webhooks, and support tickets. Operations like buy, renew, cancel, rotate, test, replace, and health checks are all present, with no obvious missing features or dead ends.
Average 3.9/5 across 48 of 48 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Open a new support ticket,' giving no information about side effects, authentication requirements, irreversibility, or what the response contains. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 6 words, making it extremely concise and front-loaded. There is no fluff or repetition. It earns its place by clearly stating the core purpose, even if other dimensions suffer from the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple create operation, but with no annotations, no output schema, and sparse parameters, the description should provide more context. It lacks any mention of required fields, priority options, response behavior, or relation to other ticket tools. The description is minimal but not enough for an agent to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters with 0% description coverage, and the description does not compensate by explaining any of them. The parameter names (subject, message, priority) are somewhat self-explanatory, but the description adds no specifics about their meaning, usage, or interplay. An agent must infer everything from names and schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open a new support ticket' clearly identifies the action (open/new) and resource (support ticket), distinguishing it from sibling tools like list_tickets, get_ticket, and reply_to_ticket. However, it doesn't explicitly mention alternatives or contrast with siblings, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or which other ticket tools might be more appropriate. The only hint is the tool name itself, which is not enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a mutation ('Add a reply') but does not disclose side effects, permissions, whether the reply is appended to the ticket, if it changes ticket status, or any other behavioral context. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it highly concise and front-loaded. However, its brevity borders on under-specification, omitting useful context that would not add much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a two-parameter mutation tool with no annotations and no output schema. The description is too sparse to be complete: it lacks parameter semantics, behavioral details, and usage guidance. The simple nature of the tool does not excuse the lack of essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention either parameter ('ticket_id' or 'message'). The description adds no meaning beyond the bare schema, leaving the agent to infer parameter purposes from their names only. This fails to compensate for the lack of property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a reply to an existing ticket' uses a specific verb ('add') and names the resource ('reply to an existing ticket'), clearly distinguishing it from siblings like 'create_ticket', 'get_ticket', and 'archive_ticket'. It is concise and unambiguous, though it could explicitly mention the ticket context.
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?
Usage is implied: the description indicates this tool is for replying to an existing ticket, which contrasts with creating or viewing tickets. However, no explicit when-to-use or when-not-to-use guidance is given, nor are alternative tools named, so it relies on the user to infer context from sibling names.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without any side effects, destruction semantics, or authorization requirements. It does not indicate whether cancellation is irreversible or what happens to associated proxies or sessions, which is a significant gap for a mutation 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?
The description is highly concise, consisting of a single, clear sentence that is easy to parse and front-loaded with the key action. It contains no filler or redundant phrasing, though it is minimal to the point of lacking contextual detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one parameter and no output schema, the description is functionally minimal but misses important contextual details like prerequisites, irreversible effects, and what a successful response looks like. Given the lack of annotations, the agent is left with insufficient information to anticipate the tool's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete coverage for the single 'id' parameter with a clear description ('Pool key id'). The tool description adds no additional semantic meaning beyond the schema, so the pre-specified baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cancel) and the specific resource (pool key), which distinguishes it from other cancel operations like cancel_modem. However, it lacks a brief explanation of what canceling a pool key entails, which could be ambiguous for users unfamiliar with the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as topup_pool_key or list_pool_keys. It does not mention prerequisites, restrictions, or scenarios where this tool should be avoided, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals one key effect (closes from customer side) but omits other important traits such as reversibility, whether the ticket is deleted or moved, permissions required, and what the API returns. This is insufficient for a mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the verb first and adds a clarifying parenthetical. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description is incomplete. It does not explain the outcome of the API call, whether archiving is permanent, or any side effects beyond the customer-facing closure. The low complexity is offset by the lack of essential context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention ticket_id at all. Although the parameter name is self-explanatory, the description adds no information about its format, source, or how to obtain it. With only one parameter, the description could have compensated but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Archive') and resource ('a ticket'), and clarifies the effect ('closes it from the customer side'). This clearly distinguishes it from sibling ticket tools like create, reply, get, and list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., ticket must be open), exclusions, or situations where another tool would be more appropriate. The parenthetical offers a hint of purpose but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the external reset service URL, the authentication method, and optional polling. It does not mention potential side effects like IP change, timeouts, or error conditions, making transparency moderate.
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 three sentences, front-loaded with the main action, and contains no redundant information. Every sentence adds meaningful detail.
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 no output schema and sparse annotations, the description covers the core mechanism, authentication, and polling but leaves gaps around max_wait_time, return values, and error handling. It is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only documents proxy_identifier; max_wait_time and wait_for_completion lack descriptions. The description clarifies that polling is optional (aligning with wait_for_completion) but does not explain max_wait_time or how it relates to polling, failing to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Token-based rotation via the public reset service', specifying the action and method. It distinguishes from siblings like restart_modem and get_rotation_status by mentioning the token-based service and polling.
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 notes that no API token is required, using the per-modem rotation token instead, which gives context on when to use this tool. However, it does not explicitly compare to alternative rotation/restart methods or state when not to use it.
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 carries the full burden. It adds useful information about the return fields, which is beyond the schema. However, it does not explicitly state that this is a read-only operation, nor does it cover behavior like filtering by status or pagination. 'List' implies safety but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and lists return fields. Every word adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers the core purpose and return fields. However, it omits the status filter parameter, which is part of the tool's functionality, making it incomplete. No mention of pagination or sorting, but the tool is simple enough that this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'status', with no description, and the tool description does not mention it at all. With 0% schema description coverage, the description should compensate by explaining that tickets can be filtered by status (open/closed/all), but it completely omits this key behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('customer's support tickets'), and clearly states the returned fields. This distinguishes it from sibling tools like coronium_get_ticket (which likely retrieves a single ticket) and create/reply tools.
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: you call this when you need a list of support tickets. However, it does not explicitly mention when not to use it or contrast with alternatives like coronium_get_ticket for retrieving a single ticket. No exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'using account_credit' which indicates a financial effect, but it does not disclose side effects, reversibility, required permissions, or error conditions (e.g., insufficient balance). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Renew', and contains no redundant words. It is optimally concise.
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 that there is no output schema and no annotations, the description provides the core action and payment method but omits important behavioral context such as failure modes, preconditions, and return values. The coupon parameter also remains unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes modem_ids and tariff_id, covering 67% of parameters. The description adds context that the action is for 'existing modems' and 'additional tariff period', but it does not explain the optional coupon parameter, leaving it ambiguous.
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 is specific and clear: it states the action (renew), the resource (existing modems), the scope (one or more), the effect (additional tariff period), and the payment method (account_credit). This differentiates it from sibling tools like buy_modems_with_balance.
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 use case is implied by the description and name, but there is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent could infer the purpose but not get explicit context on when it should be chosen.
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 provided, the description carries the full burden. It does disclose a significant behavioral trait: 'Returns 503 if the pool tier is not enabled on this deployment.' However, it does not describe what a successful response looks like or whether the operation is read-only (though implied). This is minimal but honest.
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 two sentences: the first states purpose with a clarifying parenthetical, the second adds a key error condition. Every word earns its place; there is no fluff or redundancy. It is tightly written and front-loaded with the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should clarify what the tool returns on success, but it only says 'live pool stock availability' without specifying the format (e.g., integer, object, list). It also omits any note about authentication, though that may be implicit across the toolkit. For a tool with no other documentation, this is a significant gap.
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 is vacuously complete. Per the rubric, a 0-parameter tool receives a baseline of 4. The description does not need to explain parameters, and it adds no confusing parameter-related content.
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 'live pool stock availability' for the 'Pool Gateway (pay-per-GB)'. The verb 'get' is implied by the name and the description names the specific resource (pool stock) and distinguishes it from sibling tools that handle buying or session management. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like buying pool or listing sessions. It only mentions the 503 error case but does not explain prerequisites, such as needing a pool tier enabled, or suggest using this before a purchase. No alternative tools are referenced.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes return fields but does not mention side effects, safety, permissions, or whether the operation is read-only. This is a gap for a tool that could be assumed to have side effects.
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 two sentences, front-loaded with the main purpose, and includes a useful cross-reference to another tool. Every sentence contributes value without unnecessary elaboration.
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 list tool with one optional parameter, the description covers the purpose and the content of the returned entries, and adds a workflow pointer. It does not mention authentication or pagination, but these are not critical given the tool's simplicity and the schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the only parameter (country_code: 'Filter to tariffs offered in this country.'). The tool description adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 action: 'List available tariffs (price plans)', and elaborates on the content of each entry (duration, price, supported countries, included GB). This distinguishes it from sibling tools, as no other tool lists tariffs.
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 a workflow hint ('Use coronium_check_coupon before buying for coupon validation') but does not explicitly state when to use this tool versus alternatives or when not to use it. The usage is implied by the tool's listing purpose.
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?
With no annotations, the description carries the full burden for behavioral disclosure, but it only states the action and a use case. It does not disclose whether the change is persistent, takes effect immediately, requires a modem restart, or has potential side effects on existing connections. This is a significant gap for a mutating operation.
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 remarkably concise: two sentences, with the primary action and resource stated up front. Every word contributes to understanding, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a setter tool with no annotations. It lacks guidance on how to discover valid preset values (e.g., via coronium_get_p0f_options), does not mention prerequisites like authentication, and does not address potential impacts of changing the fingerprint. The schema covers parameters well, but the overall operational context is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning by explaining the 'advertise' aspect and providing examples of preset names, but it largely mirrors the schema. It does not introduce new parameter-specific behavior beyond what the schema already provides.
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 (Set), the resource (p0f OS fingerprint preset), and what it does (the modem should advertise). It distinguishes itself from sibling tools like coronium_get_p0f_options by focusing on the setting action, and it gives concrete examples of valid values (Android / iOS / Windows), making the purpose unambiguous.
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 a clear use case: 'Useful when the destination platform fingerprints clients.' This gives the agent a contextual trigger for when to use the tool. However, it does not explicitly mention alternatives or when not to use it, such as referencing coronium_get_p0f_options for listing valid presets.
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 carries the full burden. It discloses the return content ('full ticket detail including all replies') and the read-only nature implied by 'Get', but it does not mention authentication requirements, error behavior, or potential side effects like marking the ticket as read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the action and object. There is no redundant or irrelevant 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?
For a simple single-parameter retrieval tool with no output schema, the description covers the core functionality and return content. It could be more complete by mentioning parameter details or auth context, but given the low complexity, it is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate by explaining ticket_id, but it does not even mention the parameter. The parameter name is somewhat self-explanatory, but the description adds no semantic value beyond the schema property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('ticket') with a clear scope ('full ticket detail including all replies'). This differentiates it from sibling tools like list_tickets, which likely list summaries, and reply_to_ticket, which adds replies.
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 this tool should be used when full ticket details are needed, but it provides no explicit guidance on when to use this versus list_tickets or other ticket-related tools. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It says the tool 'adds traffic/credit' but does not mention side effects like deducting from account balance, whether the operation is reversible, or if any prerequisites apply beyond having an existing pool key. This leaves significant uncertainty for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It conveys the action, the object, and a clarification in parentheses, all in a compact and front-loaded manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is fairly complete about the core action. However, the lack of annotations means the description should also explain expected side effects (e.g., balance deduction) or prerequisites. It is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter 'id' as 'Pool key id' with 100% coverage, so the schema does most of the work. The description adds the nuance that the id must refer to an 'existing' pool key, which is a minor improvement over the schema alone. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'top up' with a clear resource 'pool key' and clarifies the action with 'add traffic/credit'. This clearly distinguishes it from sibling tools like buying a new pool, listing pool keys, or canceling a pool key.
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 this is for an 'existing pool key', which gives clear context for when to use it (adding credit to an already-existing key) versus purchasing a new pool. It does not explicitly name alternatives or exclude scenarios, but the 'existing' qualifier provides some guidance.
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 the full burden. It discloses the output ('host gw.proxies.sx + credentials') and confirms optional parameters, which adds some value. However, it does not explain authentication requirements, error conditions, or the exact format of credentials, leaving behavioral uncertainty.
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 two sentences, front-loaded with the primary action, and contains no unnecessary verbiage. It efficiently conveys the core purpose and key parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must fully explain return values and behavior, but it only vaguely states 'Returns host gw.proxies.sx + credentials.' It does not specify the URL format, how credentials are encoded, behavior for multiple URLs, or failure modes, leaving the description incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters clearly, with 75% coverage. The description adds the 'active' condition for the id parameter and reiterates the optionality of protocol, count, and country, but does not supply deeper semantic nuance 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's purpose with a specific verb and resource: 'Build a usable proxy URL (or URLs) for an active pool key.' It distinguishes itself from sibling tools like coronium_get_proxies and coronium_get_proxy by focusing on URL construction rather than listing or retrieving proxies.
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 is for building URLs when you have an active pool key, and optional parameters (protocol, count, country) are mentioned. It does not explicitly name alternatives or exclusions, but the context is clear enough to indicate when to use it.
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 the full burden. It adds ownership and return format context, but does not explicitly state read-only nature, pagination behavior, or any side effects. This leaves gaps in behavioral disclosure but is adequate for a simple list operation.
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 two concise sentences, front-loaded with the core action and supplemented by essential return detail. No unnecessary words or repetition; it is a model of efficient writing.
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 list tool with three optional filters and no output schema, the description adequately covers purpose and return format. It does not mention how filters combine or result ordering, but the schema covers parameter semantics, making it sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, each with a clear meaning (online_only, country_code, expiring_within_days). The tool description adds no additional parameter semantics, so the schema carries the load; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the user's mobile proxies, using the specific verb 'List' and resource. It further specifies the return format (name, host:port, login, expiry, country), which distinguishes it from singular get_proxy and other list-oriented siblings.
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?
Usage is implied ('List the user's mobile proxies') but no explicit guidance is given about when to use this instead of alternatives like coronium_get_proxy or list_free_modems. There are no exclusions or alternative suggestions, making it clear but not prescriptive.
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 the full burden. It adds behavioral context by noting 'available right now' and 'live stock,' implying a real-time read-only operation. But it doesn't disclose side effects, authentication requirements, or return behavior, leaving some uncertainty.
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?
Two concise sentences that front-load the core purpose in the first sentence and add usage context in the second. No redundant or filler content.
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 the main purpose and usage context, but with no output schema and no annotations, it leaves gaps around parameter details, return structure, and any prerequisites. For a simple list tool this is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'country/tariff combination' but doesn't explicitly explain the country_code parameter, its requiredness, or format. The hint is insufficient for an agent to understand how to populate the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource as 'free (purchasable) modems available right now.' It distinguishes itself from purchase or management siblings by emphasizing the pre-purchase availability check.
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 it is 'useful before buying' and that it 'confirms the country/tariff combination has live stock,' providing clear context. However, it doesn't explicitly mention alternatives or when not to use it, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'list' implies a read-only operation, but no further behavioral details are disclosed (e.g., return format, pagination, or whether it only shows sessions owned by the authenticated user). The description is minimal and doesn't add meaningful transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence fully describes the tool's functionality without any fluff or repetition. Every word contributes meaning.
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 parameterless list operation with no output schema, the description is nearly complete. It specifies 'my currently-open sticky pool sessions', which covers the key attributes. However, it doesn't mention what information is returned (e.g., session IDs, status), though this is a minor gap given the 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 tool has zero parameters and the schema is empty, so there is nothing to explain. The baseline for 0 params is 4, and the description appropriately doesn't invent parameters.
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 my currently-open sticky pool sessions' with a specific verb ('list') and resource ('my currently-open sticky pool sessions'). It distinguishes this from sibling tools like coronium_close_pool_session and coronium_list_pool_keys by focusing on open sessions.
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 its use case by mentioning 'currently-open sticky pool sessions', but provides no explicit guidance on when to choose this over alternatives or when not to use it. Context is clear but no exclusions or alternative comparisons are given.
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 provided, the description carries the burden of behavioral disclosure. It reveals that the tool is authenticated, triggers a rotation (new IP), and is idempotent in-flight (returns status if a rotation is already pending). This adds meaningful context beyond the tool name and action. However, it does not disclose potential side effects like connection disruption or error conditions, which keeps it from being a 5.
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 and front-loaded. It consists of three short sentences, each adding value: what the tool does, idempotency behavior, and a clear next-step pointer. No unnecessary words or repetition.
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 low complexity (one parameter, no output schema, no annotations), the description covers the essential aspects: purpose, behavior, and a follow-up action. It is fairly complete for this scope, but the lack of differentiation from the sibling coronium_rotate_modem and the absence of return-value details prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a 100% description of the sole parameter 'proxy', making the description's lack of parameter detail acceptable. The description does not add any extra meaning about the parameter beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Trigger a rotation (new IP) on the customer's modem via authenticated /v3 endpoint.' It uses a specific verb and resource, and distinguishes from coronium_get_rotation_status by naming it as a polling tool. However, there is a sibling tool coronium_rotate_modem that seems to perform a similar action, and the description does not differentiate between the two, so it does not fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by directing the agent to 'Use coronium_get_rotation_status to poll' after triggering, which clarifies the follow-up step. However, it does not state when to use this tool versus the similar sibling coronium_rotate_modem, nor does it mention any exclusionary conditions. The 'Idempotent in-flight' note is a behavioral property, not explicitly a usage guideline.
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?
Discloses that the note is 'Visible only to the owner', adding useful context. However, it does not describe whether the metadata is overwritten, required permissions, or the response format, which is important given no annotations are provided.
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?
A single, straightforward sentence that front-loads the action and includes a relevant example. No wasted 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 simple set tool with fully documented parameters, the description provides purpose and a visibility constraint. It could mention overwrite behavior or return value, but given the tool's simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with examples and constraints (100% coverage). The description adds an example value for metadata but does not explain the proxy identifier 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 action: 'Set a free-form metadata note on a modem' with a concrete example. It distinguishes from siblings like 'coronium_apply_modem_settings' by focusing on metadata rather than settings.
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?
It provides a use case ('useful for tagging proxies in agent workflows') but does not explicitly state when to use this tool over alternatives or mention any exclusions. Usage is implied rather than fully guided.
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 carries the full burden of behavioral disclosure. It states that a request is sent through the modem's endpoint and returns IP/latency, but it does not mention whether the operation is read-only, any prerequisites (e.g., modem must be active), or error behavior. This is adequate but leaves gaps.
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 two sentences long, front-loading the purpose ('Test connectivity through a proxy') and adding essential detail in the second sentence. Every word earns its place with no 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?
For a simple one-parameter tool with no output schema, the description adequately covers purpose, mechanism, and return value. It lacks preconditions and output format details, but these are not critical for this straightforward diagnostic 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 input schema fully documents the single 'proxy' parameter with a clear description (modem _id or portId/name), and the tool description adds no additional parameter-level meaning. Since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tests connectivity through a proxy, specifying the mechanism (HTTP/SOCKS endpoint) and the outputs (external IP and latency). It is distinct from sibling tools like coronium_get_proxy_health or coronium_get_proxy, 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 usage for verifying proxy connectivity, but it does not explicitly state when to use it over alternatives or provide any exclusions. No alternatives or when-not-to-use guidance is given, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Check the status' which implies a read operation but doesn't explicitly state it's non-mutating, nor does it disclose auth requirements, return format, or any side effects. Minimal behavioral disclosure beyond the basic action.
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?
Two sentences with front-loaded purpose followed by usage context. No unnecessary words – every word earns its place, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param tool without an output schema, the description provides purpose and usage context but omits expected response/status values. The agent knows when and how to call it, but not what the response will look like, leaving some ambiguity for a status-check 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 schema provides no description for payment_id (0% coverage), but the description phrase 'by id' reinforces its purpose as the payment identifier. However, no format or example is given, so the agent must infer the expected string format.
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 'Check the status of a payment by id' – a specific verb and resource, clearly distinguishing it from sibling 'coronium_get_payments' which likely lists payments. The mention of buy/renew operations further clarifies its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage context: 'Useful after coronium_buy_modems_with_balance / coronium_renew_modems_with_balance to confirm settlement.' This tells the agent exactly when to call this tool, satisfying the requirement for clear when-to-use guidance.
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 carries the full burden. It discloses that settings are re-pushed on the server and implies the modem must be online, but doesn't describe side effects, whether it disrupts connections, or what the outcome looks like. Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It conveys purpose and usage context efficiently, earning a top score.
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 one-parameter tool with no output schema and no annotations, the description covers the core purpose and when to use it. It could mention the expected result or effect, but the current level is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'proxy' with a clear description (Modem _id or portId/name). The tool description adds no additional parameter meaning, and schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool re-applies/re-pushes a modem's port settings on the server, with a specific verb and resource. It distinguishes itself from sibling tools like restart, rotate, and test by focusing on re-pushing settings rather than changing device state.
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 gives explicit when-to-use guidance: 'after a config change or if a proxy stops responding but the modem is online.' It doesn't explicitly mention alternatives or when-not-to-use, but the context is clear enough to guide selection among siblings.
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 disclose behavioral traits. It states that a new random password is generated server-side and returned, which is useful. However, it does not mention side effects such as invalidating existing connections or requiring authentication, which is a notable gap for a mutation tool.
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?
Two concise sentences, front-loaded with the action, no unnecessary words. Every word earns its place, and the purpose and outcome are clearly conveyed in a compact form.
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 one-param tool, the description explains what it does and that the new password is returned, covering the essential outcome. However, with no annotations and no output schema, it could be more explicit about side effects or response format, but the core context is adequately addressed.
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 single parameter 'proxy' is fully described in the schema (coverage 100%), so the description does not need to add parameter details. It also doesn't, but the schema's description is already sufficient, so this is a baseline score.
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 ('Rotate the HTTP/SOCKS proxy password') and the resource, distinguishing it from sibling tools like get_proxy or restart_modem. It also explains the outcome (generates a new random password and returns it), making the purpose unambiguous.
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 clearly implies when to use the tool – when a proxy password needs rotation – but does not explicitly contrast it with alternatives or mention prerequisites/exclusions. It provides clear context for its specific purpose, though without explicit when-not guidance.
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 carries the behavioral disclosure burden. The verb 'Get' and the listing of returned fields imply a read-only operation with no side effects. However, it does not disclose authentication requirements, the fact that it returns data for the currently authenticated account, or the possibility of null/empty fields. It is adequate but not rich in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that succinctly names the operation and lists key result components. Every word earns its place, and there is no unnecessary detail or repetition.
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 low complexity (no parameters) and absence of an output schema, the description provides a reasonably complete overview. It covers the main payload items (profile and balance summary), though it could be slightly more specific about the structure of the balance summary or what 'business data' entails. Still, it is sufficient for an agent to understand the tool's scope.
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 input schema already provides 100% coverage. Per the baseline rule for parameterless tools, the description need not add parameter information. It appropriately does not attempt to invent parameter details.
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 gets the account profile and lists specific contents (email, role, contact, business data) along with an overall balance summary. This distinguishes it from sibling tools like coronium_get_balance, which focus only on balance, and coronium_get_payments, which focus on payments.
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 by enumerating what it returns, allowing an agent to infer when to call it (when account profile or overall balance is needed). However, it does not explicitly mention alternatives or when not to use it, leaving potential ambiguity with coronium_get_balance for balance-only needs.
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 present, so the description carries full burden. It discloses that it returns .ovpn content and that VPN support varies by modem, but does not mention error behavior for unsupported modems, authentication requirements, or response format details beyond the file type.
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 consists of two concise sentences, front-loaded with the action and resource. No redundant or extraneous information is present.
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 getter tool with one parameter and no output schema, the description covers the core purpose and output type. It lacks explicit error handling notes, but given the low complexity, the coverage is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter (modem _id or portId/name) with 100% coverage. The description adds minimal extra meaning, only reinforcing that the parameter identifies a modem, which is already clear from 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 uses a specific verb 'Get' with a clear resource 'OpenVPN config blob for a modem'. It explicitly distinguishes this tool from HTTP/SOCKS proxy tools by mentioning VPN tunnel access, which aligns with sibling tools like coronium_get_proxy.
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 by stating that some modems offer VPN tunnel access in addition to proxy, implying this tool is for VPN configuration. However, it does not explicitly name alternative tools or state when not to use it, only implies differentiation.
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 the full burden. It implies a read-only operation via 'List,' but does not explicitly state safety, auth requirements, or error behavior. For a simple getter this is acceptable but not comprehensive; a note confirming it has no side effects would have been stronger.
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?
Two sentences, no waste. The first sentence states the primary purpose; the second provides a crucial usage hint. Information is front-loaded and every word earns its place.
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 one-parameter lookup tool without an output schema, the description adequately explains what will happen (list of valid values) and when to use it. It doesn't describe the exact return format, but the phrase 'List the valid ... values' sufficiently implies the result. Given the tool's simplicity, this is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the sole 'proxy' parameter with 100% coverage, providing a clear description (Modem _id or portId/name). The tool description doesn't add extra parameter context beyond referencing 'for a modem,' so the baseline of 3 is appropriate—schema does the heavy lifting.
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 purpose: 'List the valid OS fingerprint (p0f) values accepted by coronium_set_modem_os for a modem.' It uses a specific verb ('List') and resource ('valid OS fingerprint values'), and differentiates itself from siblings by explicitly naming the companion tool it supports.
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 usage guidance: 'Call this first so you don't guess the OS string.' This explicitly tells the agent to invoke this tool before coronium_set_modem_os, establishing a temporal workflow. It lacks formal alternatives or when-not-to-use conditions, but the context is clear and actionable.
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 provided, the description carries the burden of behavioral disclosure. It clearly indicates a read operation ('Get') and lists the returned fields (credentials, expiry, external IP, rotation interval). It does not mention authentication requirements, rate limits, or error behavior, but for a simple read-only tool this is a reasonable baseline.
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 two short, front-loaded sentences. The first states the action and target, and the second lists key included details. There is no redundant phrasing or filler.
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 single-parameter read tool with no output schema and no annotations, the description sufficiently conveys purpose, selection method, and response contents. It does not explicitly mention the read-only nature beyond 'Get' or contrast with the plural variant, but given the low complexity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the 'proxy' parameter (Modem _id or portId/name with an example), achieving 100% schema coverage. The description's 'by id or name' restates the schema without adding new semantic detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') plus resource ('full details for a single proxy') and identifies how the proxy is selected ('by id or name'). It clearly distinguishes itself from the sibling tool 'coronium_get_proxies' (plural) by emphasizing 'single proxy'.
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 phrase 'single proxy' provides clear context that this tool is for one specific proxy rather than a list, which contrasts with the plural sibling. However, it does not explicitly state when to use this versus an alternative or mention any exclusions, so it stops short of a 5.
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 convey safety and behavior. 'List' implies a read-only operation and the return format is disclosed, which is helpful. However, it does not explicitly state that it is safe/non-destructive, mention authentication requirements, or describe any potential side effects. The information given is adequate for a simple list operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and return fields with no wasted words. It is concise and well-structured.
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 low complexity (0 params, no output schema), the description is nearly complete: it states what it does and what it returns. It could mention whether the list is exhaustive or if pagination applies, but for a country list this is likely unnecessary. The return fields are clearly specified.
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 fully covers everything. With 0 parameters, the baseline is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('countries that have stock available'), and clearly states the return fields (ISO-2 + display name + count of free modems). This distinguishes it from siblings like list_free_modems, which lists modems rather than countries.
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: use when you need to know which countries have stock. However, it does not explicitly mention when not to use it or contrast it with alternatives such as list_free_modems or get_pool_stock. The context is clear but no exclusions or alternative guidance is provided.
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 carries the full burden. It discloses the subscription transfer ('you keep the same expiry') and the existing-customer auth requirement. However, it does not detail side effects like deactivation of the old modem or potential costs. This is moderate transparency, missing some behavioral specifics.
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 three sentences, front-loaded with the primary purpose, and contains no filler. All sentences add meaningful information about usage, effects, and requirements.
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 moderate complexity (2 params, simple operation), the description covers the key aspects: purpose, trigger conditions, subscription effect, and auth. It lacks details about the return value, but the absence of an output schema reduces that burden. The description is adequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds the context of 'same country/tariff' which aligns with the same_country param, but does not add new syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Swap a broken/dead modem for a working one'. It specifies the resource (modem) and the action (replace), and distinguishes it from sibling tools like restart_modem or rotate_modem by focusing on replacement due to failure.
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 provides explicit usage conditions: 'Used when a modem has consecutive ping failures or won't rotate.' This gives clear guidance on when to invoke it, though it does not explicitly mention alternatives or when not to use it, which would be a minor improvement.
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 carries the transparency burden. It discloses backend polling behavior and the disabling effect of 0, but does not mention whether changes apply immediately, require a restart, or affect ongoing rotations. This is adequate but not comprehensive.
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?
Four short sentences, front-loaded with the core purpose, followed by essential behavioral notes and examples. Every sentence provides value and there is no redundancy or filler.
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 configuration setter with a fully documented schema, the description covers the key behavioral aspects (cadence, disabling, backend polling). It lacks explicit return-value or error details, but the absence of an output schema makes that less critical. Overall, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters fully (100% coverage), including the '0 = manual only' semantics. The description adds typical value examples (60, 300, 1800) but does not significantly expand beyond the schema, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Configure' with a clear resource 'auto-rotation cadence', immediately conveying the tool's function. This distinguishes it from sibling tools like rotate_modem (manual rotation) and get_rotation_status (read-only status).
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 including typical values and the effect of 0, which implies when to use the tool (to set or disable auto-rotation). However, it does not explicitly reference alternative sibling tools or state when not to use it, so it misses a point for exclusion guidance.
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 carries the burden of disclosing behavioral traits. It states that the purchase uses account balance, implying a financial transaction and cost. However, it does not disclose potential outcomes, required permissions, or failure modes beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action, then provides necessary parameter context. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and no output schema, the description is reasonably complete for invocation. However, it does not mention what the function returns after purchase (e.g., key details or payment status), which could be valuable for a paid action.
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 provides basic description for tariff_id, but the tool description adds meaning by specifying the source (coronium_list_tariffs) and a distinguishing property (pool tariffs have a traffic cap). Since schema coverage is 100%, the added context goes beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Buy a pay-per-GB pool key using account balance.' It specifies a unique resource (pool key) and distinguishes it from sibling tools like buying modems or topping up existing pool keys. The mention of 'pool tariff_id' further refines the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by instructing to pass a pool tariff_id from coronium_list_tariffs and noting that pool tariffs have a traffic cap. It does not explicitly exclude alternative tools for related operations, but the guidance is sufficient for correct invocation.
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 provided, the description carries the full burden. It adds valuable behavioral detail by stating that it returns only last-4 digits and brand, implying sensitive data is masked. This goes beyond a generic 'list' description, though it does not mention auth requirements or other safety aspects.
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 two sentences, front-loaded with the core function, and contains no redundant information. Every word earns its place, making it an exemplar of conciseness.
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 (zero parameters, no output schema), the description is complete. It states what the tool does and what it returns, including the masked card data, which is sufficient for an agent to understand the outcome.
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 has zero parameters, so the baseline per rubric is 4. The description adds no parameter details because none exist, which is appropriate and complete.
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 'saved credit cards on file (Stripe)', specifying the provider. This distinguishes it from sibling tools like coronium_get_payments, which lists payment transactions rather than stored card information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as authentication. The usage is only implied by the tool's name and description, but there is no direct statement of context 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 provided, the description carries the full burden. It discloses key behavioral traits: payment via balance, auto-assignment from free stock, and country-pool matching. It does not detail failure modes or full side effects, but it is far more transparent than a bare 'Buy modems'.
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 two sentences, front-loaded with the main verb and purpose. Every sentence adds value, and there is no redundant or filler 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?
The description covers the operation's input essentials and gives a clear outcome (modems auto-assigned from free stock). It lacks explicit mention of cost, failure conditions, or output format, but for a purchase tool with no output schema, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (tariff_id and country_code have descriptions). The description adds context by explaining that tariff_id drives the country pool and country_code constrains assignment, and it mentions coupon as optional. However, it does not elaborate on quantity constraints or coupon format, relying on the schema for that. It partially compensates for the schema gap but not fully.
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 ('Buy one or more modems') and the resource (modems), with a specific payment method (account_credit). This immediately distinguishes it from sibling tools like renew_modems_with_balance or buy_pool_with_balance, and the mention of auto-assignment from free stock adds specificity.
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 conveys clear usage context: buying modems with balance, specifying tariff_id and quantity, optional coupon. It does not explicitly mention alternatives or when not to use it, but the context and sibling names imply its role. A slight improvement would be stating 'Use this to purchase new modems; use renew_modems_with_balance for renewals.'
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 goes beyond a simple 'cancel' by disclosing that auto-renewals stop, the modem stays active until the current period ends, and refunds are subject to terms. This is good behavioral context, though it could mention prerequisites like authentication or reversibility.
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?
Two concise sentences with no waste. The core action is front-loaded, and the second sentence adds essential behavioral details. Every word earns its place.
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 single-parameter cancellation tool with no output schema and no annotations, the description adequately covers the action, effects, and refund policy. It could mention expected output or authentication needs, but given the simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter semantics, including the format and examples for the 'proxy' parameter. The description adds no additional parameter information, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cancel) and the resource (modem subscription), and specifies the effect (no further auto-renew). It distinguishes from sibling tools like coronium_cancel_pool_key by explicitly mentioning 'modem subscription'.
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: the modem remains usable until tariff_expired_at and refund policy applies, which informs the agent about the consequences. However, it does not explicitly name alternatives or state when not to use it, but the context is sufficient for a straightforward cancellation.
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 transparency burden. It adds valuable behavioral context: account_credit is 'what's actually used to pay for proxies,' crypto prices are 'cached 60s,' and 'not shown per row' indicates output format nuance. This goes beyond a bare 'get balance' statement, though it could mention response format or error cases.
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 two sentences, front-loaded with the main verb ('Get'), and every phrase adds value: explains wallet, crypto valuation, caching, and a formatting caveat. 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?
For a simple 0-parameter read tool with no output schema, the description adequately covers what it returns (account_credit + crypto in USD) and important nuances (caching, per-row display). Minor ambiguity in 'not shown per row' prevents a perfect score, but overall it's 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 tool has 0 parameters, so the baseline is 4 per the rubric. The description doesn't need to explain parameter meanings since there are none, and the schema already reflects this with 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the customer's spendable balance.' It specifies the resource (balance) and differentiates from siblings by explaining that it includes account_credit (USD wallet) plus crypto balances valued in USD, which distinguishes it from tools like get_crypto_balance or get_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need the spendable balance) but does not explicitly state usage context or alternatives. It provides enough clarity for a simple read operation but lacks explicit guidance on when not to use it or which sibling to use instead.
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 the full disclosure burden. It reveals that setting the webhook triggers auto-swapping, specifies the POST payload fields (old_modem_id + new_modem_id), and explains how to disable via null/empty. This covers the core behavioral aspects, though it omits details like error handling or authentication.
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 two concise sentences, front-loaded with the main action ('Set or clear'). The second sentence adds essential detail about behavior and disabling without any filler, earning every word.
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 one-parameter tool with no output schema, the description sufficiently covers the operation, the triggering event, the payload, and the disabling path. It lacks details on the response format or edge cases, but given the tool's simplicity, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear description of webhook_url, including the null option. The tool description echoes the null/empty behavior and adds context about the payload, but doesn't materially expand parameter 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 'Set or clear the modem-lifecycle webhook' with a specific verb+resource. It distinguishes itself from related tools like get_webhook by focusing on configuration, and explains the operational effect (auto-swap and JSON POST).
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 gives context on when this tool is relevant (when a modem dies) and the consequence (auto-swap and notification), implying its use for lifecycle automation. However, it doesn't explicitly name alternatives or when not to use it, so guidance is implicit rather than explicit.
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 provided, the description carries the burden of warning about the destructive 'close all' behavior. It explicitly states that omitting session_key closes ALL sessions, which is a critical behavioral risk. It does not mention reversibility or side effects, but the main hazard is disclosed.
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 two concise sentences, front-loaded with the action and clearly explaining the optional parameter behavior. Every word earns its place, with no filler or 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 tool with one optional parameter and no output schema, the description is complete: it states the action, the parameter behavior, and the dangerous default. It is fully adequate for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter (session_key) with 'Session key to close; omit to close all', and the description repeats the same information. Since schema description coverage is 100%, the description adds no additional parameter semantics 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 uses a specific verb ('close') and resource ('pool session'), and clearly distinguishes between closing one session (by key) or all sessions (by omission). This makes its purpose unambiguous and differentiates it from sibling tools that list or create pool sessions.
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 gives clear guidance on how to use the tool: pass session_key to close one, or omit it to close all. It implies the context of managing pool sessions but does not explicitly name alternatives or when not to use it. The conditional behavior is well explained.
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 carries the full behavioral burden. It discloses the return values (states and IPs) and the backend janitor behavior that auto-clears stale 'rotating' states within 5 minutes. It does not mention error handling, authentication, or side effects, but for a read-only status poll this is reasonably transparent.
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 and well-structured: purpose first, then return values, then an operational note about the janitor. Every sentence adds value, and there is no redundancy or fluff.
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 simple one-parameter schema and lack of output schema, the description adequately covers the return payload (status states and IPs) and a notable backend behavior. It provides enough context for an agent to understand what the tool will return and how to interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a fully documented 'proxy' parameter with format and examples, achieving 100% schema coverage. The description adds no parameter-specific information beyond what is in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 purpose with a specific verb ('Poll') and resource ('rotation status for a modem'), and it enumerates the returned states. This distinguishes it from sibling tools like rotate_modem or set_rotation_interval, which perform different actions.
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 a clear context for use ('Poll rotation status') but does not explicitly name alternatives or exclusions. The mention of the stuck-rotation janitor hints at how to interpret stale states, but there is no direct comparison to other tools like get_proxy or rotate_modem.
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 carries the full burden. It discloses the scope ('my' keys) and the output fields (status, traffic remaining, tariff), but does not explicitly state that the operation is read-only, nor mention auth requirements or edge cases like empty results or pagination. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both purposeful: the first explains what the tool lists and the fields, the second points to a complementary tool. There is no wasted text and the main action is front-loaded.
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 0-parameter list tool with no output schema, the description fully covers the purpose, the data returned, and the relevant next step. It is complete within its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because there are none to document.
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 states a specific verb and resource: 'List my pay-per-GB pool keys' and details the returned attributes (status, traffic remaining, tariff). This clearly distinguishes it from sibling tools like coronium_list_pool_sessions or coronium_get_pool_stock.
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 provides clear context by naming a direct alternative: 'Use coronium_build_pool_proxy_url to get a usable proxy URL for an active key.' This tells the user when to switch, though it does not enumerate other exclusions or situations for which the tool is not appropriate.
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 discloses key behaviors: it returns discount %, fixed-amount, or an error if invalid/expired. The term 'validate' implies a read-only check without side effects, though this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that covers purpose and return behavior without any fluff or repetition.
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 one-parameter validation tool, the description adequately covers its purpose and expected outputs. It could mention the exact error format or explicitly confirm no side effects, but these are minor omissions for such a straightforward 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?
The schema has one parameter 'code' with no description coverage. The tool description clarifies that 'code' is the coupon code to validate, adding semantic meaning beyond the bare schema property name.
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 opens with a specific verb and resource: 'Validate a coupon code.' It clearly distinguishes this tool from siblings, as no other tool deals with coupons.
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 context is clear: use this to validate a coupon code and retrieve its discount or error. No explicit alternatives exist among siblings, so the lack of exclusions is acceptable.
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 the full burden. It discloses the read-only nature via 'Get', explains the behavioral meaning of the tiers (alert when balance drops below a tier), and notes the endpoint ship date. It does not detail return format, but for a simple getter with no parameters, the disclosed information 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each adding value: the action, the alert behavior, and the release date. It is front-loaded with the core purpose and contains no filler.
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 zero-parameter read tool with no output schema, the description adequately explains what the tool does and the meaning of the tiers. It mentions USD amounts, which hints at the return values, and the sibling setter completes the context. It could specify return structure, but it is not critical for this simple getter.
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 has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because there are none, but it provides context about the returned tiers being USD amounts, which indirectly explains the domain. This meets the baseline.
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 the configured low-balance email alert tiers, using the specific verb 'Get' and the resource 'low-balance email alert tiers'. It distinguishes from the sibling tool 'set_low_balance_threshold' by explicitly indicating this is the retrieval counterpart, and adds relevant detail about USD amounts.
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 the tool is used to check the thresholds that trigger alert emails, providing clear context. It does not explicitly mention alternatives or exclusions, but the sibling setter is obvious from the name and the read-oriented phrasing. This meets the 'clear context, no exclusions' level.
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 the specific side effect of caching an encrypted token at a file path, and explains the auto-login behavior of other tools. However, it does not explicitly state whether the token is overwritten or what happens on failure, leaving some behavioral ambiguity.
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 two sentences long, with the first stating the core action and the second providing necessary usage context. No redundant information; every clause serves a purpose.
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 2-parameter login tool with no output schema, the description covers the primary purpose, the token cache side effect, and the specific circumstances for manual invocation. It lacks an explicit statement of return values or error behavior, but that is not critical given the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, including the env fallback behavior for both login and password. The description's mention of 'email + password' adds no new information beyond the schema, so it meets the baseline.
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 opens with 'Authenticate with email + password and cache an encrypted token at ~/.coronium/token.enc', clearly stating the verb and resource. It also distinguishes from siblings by noting that most other tools auto-login, making manual login only necessary for re-auth or account switching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'calling this manually is only needed for explicit re-auth or account switching.' It also implicitly names alternatives by explaining that 'most other tools auto-login when CORONIUM_LOGIN/CORONIUM_PASSWORD are set in the env', which guides the agent away from calling this tool routinely.
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 responsibility for behavioral disclosure. It reveals that emails are sent independently per tier when account_credit dips below each tier, and it clarifies the current backend constraint on allowed values. This goes beyond the bare 'set' action and gives the agent useful behavioral expectations.
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 and front-loaded, with each sentence contributing: purpose, allowed values, examples, and behavior. There is no fluff or vague language, and the structure guides the agent from the high-level action to specific constraints and effects.
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 single-parameter setter with no output schema, the description covers purpose, allowed values, examples, and behavior. It omits potential side effects like error handling or confirmation, but these are not critical for such a simple tool. The description, combined with the thorough schema, is sufficiently 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?
The schema already has 100% parameter description coverage, stating that thresholds is a subset of [100, 300, 500] and that an empty array clears all tiers. The description adds value with concrete examples and notes the USD unit, but the independent-trigger behavior is more about the tool's effect than parameter syntax. Overall, it supplements the schema without being redundant.
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 opens with a specific verb+resource: 'Set low-balance email alert tiers.' It clearly differentiates from the sibling get_low_balance_threshold by the 'set' verb and elaborates on the exact allowed values and behavior, leaving no ambiguity about what the tool does.
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 on when to use this tool: to configure low-balance email alert thresholds. It gives concrete examples and notes the backend constraint of exactly 100/300/500, but it does not explicitly mention alternatives like get_low_balance_threshold for reading current settings. Still, the intended use is unambiguous.
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 carries the burden of disclosing behavior. It reveals that the tool checks the cached token, returns a boolean, and suggests action on invalid. Does not mention exceptions or edge cases, but adequately covers the essential 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?
Two sentences: first states purpose and return type, second gives usage context and alternative. Front-loaded with purpose, no redundant or extra 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?
For a simple one-parameter check tool with no output schema, the description covers purpose, usage timing, return value, and fallback actions. It is complete enough for an agent to decide when and how to use it.
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?
Input schema already provides 100% coverage for the single optional parameter, describing it as an explicit token defaulting to cached. The description adds no new parameter details beyond referencing the cached token, which is already stated in 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?
Specific verb 'Verify' with resource 'cached token', clearly states the tool checks token validity and returns true/false. Distinguishes from login/logout by focusing on validation status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before a long agentic session) and provides a clear alternative if invalid (call coronium_login or rely on auto-login). This gives both usage context and fallback behavior.
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 burden of behavioral disclosure. It explains the webhook's purpose, the condition for firing, and the meaning of null (disabled with email fallback). It doesn't elaborate on auth requirements or rate limits, but for a simple getter this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a parenthetical clarifying null behavior. It is front-loaded with the primary action and resource, and every word adds value.
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 no output schema and no annotations, the description must explain return value semantics, and it does: it indicates the success value (URL) and the disabled case (null). For a simple getter with no parameters, this is a complete description.
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, and the schema coverage is 100%, so the schema fully defines the input. The description adds no parameter details, but given the absence of parameters, the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the account's modem-lifecycle webhook URL and specifies the triggering event (dead modem auto-swap). This distinguishes it from sibling tools like set_webhook and other getters, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is used to check the current webhook configuration and provides context for interpreting null results. However, it does not explicitly mention when to prefer this over coronium_set_webhook or other alternatives, so it lacks explicit when-not 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 provided, the description carries the full burden. It discloses the local file affected and the follow-up authentication requirement, which is good. It does not mention edge cases like idempotency or whether it affects server-side sessions, but for a simple cache-clear this is adequate.
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?
Two sentences that are direct and informative, no unnecessary words. Front-loaded with the verb and object.
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 zero-parameter logout tool, the description covers the action, the specific file, and the consequence. No output schema needs explanation. This is 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?
The tool has zero parameters, so there is nothing to explain. The schema coverage is trivially 100%, and the description adds context about the operation. Given zero params, baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear the cached token') and the specific resource ('~/.coronium/token.enc'), making it unambiguous. It distinguishes itself from siblings like coronium_login and coronium_check_token by focusing on removing local credentials.
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 the consequence (re-authentication required) which gives clear context for when to use it. However, it does not explicitly name alternatives or when-not scenarios, so it falls short of the highest bar.
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 present, so the description carries the full burden. It discloses that the tool returns the full ledger (not a single payment) and implies a read-only operation through the 'get' verb and reconciliation purpose. However, it doesn't explicitly mention absence of side effects, rate limits, or pagination, but for a read-only listing tool this is reasonably transparent.
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 sentences that front-load the action and resource, then provide purpose and sibling differentiation. Every word earns its place without unnecessary elaboration.
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 tool has no parameters, no output schema, and no annotations, so the description is the only source of context. It covers the core behavior (full ledger retrieval), the purpose (reconciliation), and the key contrast with a sibling. For a simple listing operation, this is nearly complete, though it could optionally mention response format or pagination if relevant.
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 is trivially complete. With 0 params, the baseline is 4, and the description adds no parameter-level detail because none is needed.
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 the full payment and invoice ledger for the account, using a specific verb ('Get') and resource. It also explicitly distinguishes itself from the sibling tool coronium_get_payment_status, which checks a single payment, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'for reconciliation / spotting duplicates or overpayments'. It also names the alternative tool (coronium_get_payment_status) and explains the difference, giving agents clear when-to-use and when-not-to-use 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 carries the burden of disclosing behavior. It explains that incoming transfers convert to account_credit at deposit time, a key behavioral trait. The read-only nature is implied by 'List', though it does not mention potential edge cases like pagination or error conditions.
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 and well-structured: first what it does, then how to use it, and finally a clarification with an alternative. Every sentence earns its place with no 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 zero-parameter read-only tool, the description covers the purpose, usage context, exclusions, and the relationship to account_credit. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description adds value by clarifying that the output includes crypto addresses and balances, but it does not need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'crypto deposit addresses + balances', clearly identifying what the tool returns. It also distinguishes from the sibling coronium_get_balance by explicitly excluding account_credit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('Use these addresses to top up') and when not to ('Account_credit itself is excluded; use coronium_get_balance for that'), naming the alternative 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?
No annotations are provided, so the description carries the full burden. It conveys that the tool is non-mutating via 'snapshot' and describes the output contents ('per-modem reachability + recommendation'). It does not mention permissions or rate limits, but for a read-only health check, the key behavioral trait is disclosed.
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 two sentences and entirely purposeful: the first defines the deliverable, the second gives actionable usage context. No filler or repetition; information is front-loaded.
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 low complexity (no params, no output schema), the description is sufficiently complete for selection and invocation. It explains what the tool does, when to use it, and how to respond to its output (swap dead modems). The output content is summarized, which is enough for a health-snapshot 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?
The tool has zero parameters, so the description cannot add parameter-specific meaning. The empty schema is fully self-explanatory, and the description appropriately avoids irrelevant parameter details, earning the baseline score of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Liveness/health snapshot for all your proxies (per-modem reachability + recommendation).' It specifies a distinct resource (proxy health) and differentiates from siblings like get_proxies or test_modem by emphasizing per-modem reachability and a recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'Call this before retrying through a proxy.' It also gives a clear alternative action: 'swap them with coronium_replace_modem.' This distinguishes it from other proxy-related tools and tells the agent exactly when it should be invoked.
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:

[![coronium-proxy-mcp MCP server](https://glama.ai/mcp/servers/coroniumio/coronium-proxy-mcp/badges/card.svg)](https://glama.ai/mcp/servers/coroniumio/coronium-proxy-mcp)

Score Badge

Copy to your README.md:

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

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