infomaniak-admin-mcp

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Most tools target distinct resources and actions (hosting vs mail vs kDrive vs Public Cloud), and the descriptions clearly separate similar-sounding ones. However, the sheer volume and the many generic 'manage_*' tools that bundle multiple operations create some potential for misselection, so it's not a perfect 5.
Naming Consistency4/5
The overwhelming majority follow infomaniak_<verb>_<resource> in snake_case, which is very consistent. Minor deviations like infomaniak_short_urls_quota, infomaniak_api_call, infomaniak_tool_catalog, infomaniak_overview, infomaniak_history, and infomaniak_undo break the strict verb_noun pattern, so it's not a perfect 5.
Tool Count1/5
221 tools is an extreme count, far beyond even the 50+ threshold for a 1. Even for a broad multi-product admin MCP, this is overwhelming and likely to cause agent confusion and poor selection performance.
Completeness5/5
The server covers an enormous range of Infomaniak products with deep lifecycle operations (create/read/update/delete) across hosting, mail, kDrive, Public Cloud, Swiss Backup, kChat, AI, and more. It also provides meta tools and an api_call escape hatch, so there are no obvious dead ends or significant gaps for the stated admin purpose.
Average 3.9/5 across 221 of 221 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish destructiveHint=true and readOnlyHint=false. The description adds the valuable behavior of two-phase confirmation, which is not in the annotations, but it does not elaborate on what actions require confirmation, side effects, or idempotency (which the idempotentHint false annotation implies but the description ignores).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste, which is good, but it is too terse for a tool with six parameters and multiple actions. It earns its place by mentioning two-phase confirmation, yet it omits crucial details, making it more under-specified than appropriately 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 high-complexity tool with six parameters, a nested payload, multiple action types, and a confirmation workflow, this description is severely incomplete. It does not orient the agent on how to construct requests, which actions are destructive, or what the output schema entails. It is minimally viable but inadequate for safe and correct invocation of destructive operations.
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 provides almost no parameter-level guidance. The 'two-phase confirmation' phrase hints at the confirmation_token parameter, but it does not explain the payload structure, required IDs, or when each action enum value should be used. The action enum is self-documenting but the rest of the parameters remain opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description conveys that this tool manages a Public Cloud DBaaS, but 'lifecycle and operational actions' is vague and does not name the specific actions (create, update, delete, reset_password, toggle_slow_logs) from the schema. It also does not differentiate from sibling read tools like get_public_cloud_database_service beyond the generic verb 'manage'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus sibling read/list tools, nor when not to use it. The existence of siblings like get/list implies a separation, but the description does not state that this is for mutations only or describe the two-phase confirmation trigger conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, which cover the safety profile. The description adds no behavioral context beyond the bare action, such as pagination behavior, return format, or that it only returns projects for the specified product. It neither enriches nor contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence with no filler or redundant wording. It is properly front-loaded with the verb 'List' and the object. However, it is so terse that it sacrifices potentially useful context, though conciseness itself is commendable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one required parameter and an output schema, the description is minimal. It lacks contextual guidance about prerequisites (e.g., obtaining a public_cloud_id via 'list_public_clouds') or the typical workflow of listing projects before fetching individual project details. The annotations and output schema cover some gaps, but the description alone does not complete the picture.
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 'public_cloud_id' at all. The parameter name is somewhat self-explanatory, but the description fails to clarify what constitutes a 'Public Cloud product' or how to obtain the ID, leaving the agent to infer semantics from the name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('projects'), scoped to 'a Public Cloud product'. It distinguishes itself from sibling tools like 'list_public_clouds' (lists clouds) and 'get_public_cloud_project' (singular project) by using plural 'projects' and the 'within' preposition, though it could more explicitly name the required public_cloud_id parameter.
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 'get_public_cloud_project' for details on a single project or 'list_public_cloud_project_users' for project members. It does not mention any prerequisites (e.g., first listing Public Cloud products to obtain an ID) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior, and the description adds little beyond listing operations. It does not explain side effects, token requirements for confirmation actions, whether operations are reversible, or any rate limits or permissions. The description does not contradict annotations, but it fails to disclose behavioral details beyond what the annotations already signal.
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 only two sentences and front-loads the primary operations. It avoids unnecessary filler, though the second sentence ('Also exposes...') somewhat restates content already implied by the action enum and adds little unique value. Still, it is appropriately short for a tool list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, 10 enum actions, nested objects, and destructive annotations, this description is far too thin. It does not map actions to required parameters, explain the meaning of 'service-level' in relation to sibling tools, or clarify when confirmation resend helpers should be used. The presence of an output schema reduces the need to describe return values, but the operational and relational context remains 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?
Schema description coverage is only 43%, so the description needed to compensate by explaining parameters like redirection_id, target_id, confirmation_token, and payload. It does not. The only parameter meaning added is the vague phrase 'target-list and confirmation resend helpers,' which does not clarify which parameters apply to which actions or how they interrelate.
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 enumerates the tool's operations ('List, create, update, delete, enable, and confirm service-level redirections') and identifies the resource as service-level redirections. However, it does not explicitly differentiate this tool from sibling tools like infomaniak_list_redirections or infomaniak_create_redirection, leaving some ambiguity about when to choose this composite tool over the individual ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus the sibling redirection tools, nor does it mention prerequisites, intended workflows, or exclusions. The action enum hints at possible operations, but the description itself offers no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds no additional behavioral context beyond the word 'Read,' such as what data is returned or any error behavior. It does not contradict the annotations, but it provides no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one short sentence with no fluff. However, it is under-specified, missing useful context that could fit without verbosity. It earns a 4 for efficiency but loses a point for omitting meaningful 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?
For a simple read operation with 3 integer parameters and an output schema, the description could be adequate if it clarified the parameter hierarchy. It does not, leaving the agent uncertain about resource nesting. The output schema may cover return values, but parameter context is entirely absent.
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%, so the description must compensate by explaining the parameters. It does not mention public_cloud_id, project_id, or dbaas_id at all, nor their hierarchical relationships. The agent is left to infer from names, which is insufficient for correct invocation.
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 "Read" and clearly names the resource "one Public Cloud DBaaS service." It distinguishes itself from sibling tools like list_public_cloud_database_services (which lists multiple) and manage_public_cloud_database_service (which modifies), so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the list or manage alternatives. It simply states the action without explicit context, prerequisites, or exclusions. Usage is only implied by the tool's name, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safe read-only nature. The description adds the 'canonical v2' API context and enumerates resource types, but it does not disclose pagination, permission requirements, or response behavior beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant words. It efficiently communicates the core purpose without bloat.
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?
Although output schema and annotations are present, the tool is a multi-mode dispatcher with eight resource operations and four parameters. The description lacks guidance on operation selection, parameter dependencies, and how this canonical tool relates to the many specialized sibling tools, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (resource, zone, domain, record_id). It only lists resource categories that loosely map to the resource enum, providing no meaningful parameter-level semantics.
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 reads canonical v2 domain, zone, DNSSEC, and DNS-record resources, specifying both the verb and the resource scope. However, it does not explicitly distinguish this from sibling tools like infomaniak_get_domain or infomaniak_dns_list_records, so differentiation is limited.
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 when-to-use or alternative guidance is provided. The phrase 'canonical v2' implies a preference for this read path, but the description never explains when to choose this tool over specialized siblings such as infomaniak_dns_list_records or infomaniak_manage_dnssec.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds that it downloads generated output, which is consistent with these hints but does not disclose behavior such as pagination, output format, or whether the report must be ready. This adds some context beyond annotations but lacks depth.
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 filler. Every word contributes to the core action, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested query object and an output schema, the description is too sparse. It does not explain the relationship to sibling report tools, what the generated output format is, or how query parameters apply to the download. This leaves important context to the agent's inference, which is risky for correct 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 coverage is only 33% (only drive_id has a description). The description does not mention report_id or the query object, nor explain how pagination/filter options like order_by and per_page affect the download. The agent must infer parameter meaning from names and enums, which is insufficient 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 uses a specific verb 'Download' and identifies the resource as 'generated output for a kDrive activity report,' which distinguishes it from sibling tools like get_drive_activity_report (likely metadata retrieval) and list_drive_activity_reports. However, it does not explicitly name alternatives or clarify what 'generated output' contains, so it falls short of a perfect score.
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 get_drive_activity_report or create_drive_activity_report. The description only states the action without explaining prerequisites (e.g., report must already be generated) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description adds no behavioral detail beyond the word 'Read.' It does not disclose response behavior, error conditions, or other constraints, adding zero value over the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is appropriately short and directly to the point, containing no unnecessary words. It is front-loaded with the core action and resource.
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's simplicity, the presence of an output schema, and read-only/idempotent annotations, the description provides the minimal necessary information for basic invocation. However, it omits any guidance on prerequisites (e.g., how to obtain the IDs) and does not clarify the relationship to list_swiss_backup_slots, making it only adequately complete.
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 the parameters (swiss_backup_id and slot_id) at all. The agent receives no contextual meaning beyond the bare parameter names, so the description fails to compensate for the complete lack of parameter descriptions.
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 ('Read') and identifies a precise resource ('one Swiss Backup slot'), clearly distinguishing it from sibling tools like list_swiss_backup_slots and manage_swiss_backup_slot. The singular scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_swiss_backup_slots or get_swiss_backup. The description merely states the action without context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, which cover the safety and idempotency profile. The description adds no extra behavioral context—beyond the word 'Read', which is consistent—but does not disclose error behaviors, rate limits, or what 'snapshot' implies. No contradiction exists.
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, tightly written sentence with no filler. Every word contributes to conveying the core action and resource, making it an exemplary concise description for a simple getter tool.
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's simplicity, the existence of an output schema, and strong annotations, the description is minimally adequate. However, it lacks domain context about what a Public Cloud product snapshot is and how to source the public_cloud_id, leaving some ambiguity for an agent unfamiliar with Infomaniak's Public Cloud schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not compensate. The sole parameter, public_cloud_id, is listed with only an exclusiveMinimum constraint, and the description fails to explain how to obtain the ID or what it references. The agent must infer semantics from the parameter name and tool name.
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 ('Read') and the resource ('one Public Cloud product snapshot'), which aligns with the tool name. However, the term 'product snapshot' is somewhat vague and does not explicitly distinguish it from sibling getters like get_public_cloud_project or get_public_cloud_kubernetes_service, beyond a general sense of 'product'.
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 offers no guidance on when to use this tool versus alternatives. It does not mention that a public_cloud_id would typically come from list_public_clouds, or contrast with related getters, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, which align with the description's 'Read' operation. However, the description adds no extra behavioral context—no mention of pagination, report expiration, permission requirements, or any constraints. It merely restates the obvious from the name and annotations without disclosing additional traits.
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, tightly worded sentence with no filler or redundancy. It front-loads the core purpose, making it easy to parse. While it could include more detail, that is not the role of this dimension—it is appropriately sized for the tool's apparent simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a valid output schema and annotations, which reduce the burden on the description. However, the description is too sparse to fully orient an agent: it doesn't explain that the report must be previously generated, how it differs from live activity endpoints, or that query parameters enable pagination/filtering. It is minimally viable but lacks contextual depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only 'drive_id' given a description. The tool description adds no meaning for 'report_id' or the nested 'query' object. Since coverage is low, the description should compensate but does not, leaving the agent to infer parameter roles from names alone. This is a significant gap.
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 a specific verb ('Read') and a specific resource ('one generated kDrive activity report'). It distinguishes from sibling tools like 'list_drive_activity_reports' (reads one vs lists all) and 'get_drive_activities' (generated report vs live activities). The scope is unambiguous for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_drive_activity_reports' or 'get_drive_activities'. It does not mention prerequisites (e.g., needing a report_id from a prior list call) or any exclusions. There is no explicit 'use this when...' 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds the scoping context of 'service-level' (as opposed to mailbox-level), which is useful but doesn't elaborate on return format, pagination, or included preferences. It aligns with the annotations, adding a small amount of behavioral context beyond them.
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 gets straight to the point. No filler words, no repetition. It is appropriately sized for a simple read operation and front-loaded with the action.
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 read tool with one parameter, an output schema, and strong annotations, the description covers the essentials. It lacks explicit differentiation from sibling mail tools, but the resource is specific enough. Given the output schema exists, return values need not be explained. Overall, it's nearly complete for its simplicity.
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 one parameter (mail_hosting_id) with zero description coverage. The tool description mentions 'for a mail hosting', which provides a weak hint that the parameter is the hosting ID, but it doesn't explain how to obtain it, its format, or any constraints beyond the schema's exclusiveMinimum. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the specific resource ('service-level mail preferences for a mail hosting'). It distinguishes from mailbox-level tools, though it doesn't explicitly name alternatives. The verb+resource is precise enough to understand the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like infomaniak_get_mail_hosting_full or get_mailbox_info. It doesn't mention prerequisites, related tools, or scenarios where this read would be appropriate. The description only states what it does, not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-idempotent operation, but the description adds valuable context: report generation is asynchronous and requires two-phase confirmation. This goes beyond what the annotations convey and helps the agent anticipate follow-up actions. It does not detail failure modes or the confirmation token flow, but 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, starting with the purpose and immediately adding the critical asynchronous confirmation note. Every word earns its place; no repetition of schema details or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, a nested payload, and a two-phase confirmation flow, yet the description only scratches the surface. It does not explain how to complete the confirmation, what the payload fields mean, or how this tool fits with related report tools. This is insufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only drive_id has a description). The description does not explain the payload object, lang, or confirmation_token parameters. The payload contains multiple fields with no documentation, and the description fails to compensate for this low 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 action: 'Create a kDrive activity report.' The verb 'create' is specific and distinguishes it from sibling tools like list, get, export, and delete reports. This is a clear statement of the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_drive_activity_report or export_drive_activity_report. The note about two-phase confirmation explains the process but does not clarify when to invoke the tool in a workflow or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent operation. The description adds the behavioral nuance of a 'two-phase commit with current file-access guard,' which suggests a confirmation step and protection against overwriting existing access. However, these terms are not elaborated, leaving the agent uncertain about the exact guard behavior or how to complete the second phase.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary action, and avoids redundancy with the schema. The second sentence is short but cryptic, which slightly reduces clarity. However, for its brevity, it packs informative hints, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and nested parameters, the description fails to explain critical aspects: the two-phase commit process, when confirmation_token is needed, how the 'current file-access guard' behaves (e.g., does it reject if user already has access?), or any error conditions. Sibling tools like update_drive_file_access_user exist, but no differentiation or context is provided. The description is too sparse for a complex mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, with most parameters (drive_id, file_id, user_id, payload) already described. The description adds no new parameter-level insights beyond mentioning 'payload accepted by endpoints' indirectly. The confirmation_token parameter lacks a description in the schema, and the description's 'two-phase commit' reference is too vague to compensate for that gap. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Grant' and the resource 'a user access to a kDrive file or folder.' This is a specific action that distinguishes it from sibling tools like update_drive_file_access_user or remove_drive_file_access_user. The two-phase commit phrase hints at a unique workflow, further separating it from simpler grant tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as update_drive_file_access_user or create_drive_file_access_invitation. It does not mention prerequisites or exclusion cases. The phrase 'Two-phase commit' implies a specific workflow but does not explain when it applies, leaving the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the agent knows this is a safe, deterministic read. The description adds minimal behavioral context by listing what the 'full definition' includes, but this is largely redundant with the output schema. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and object, with no filler or redundant words. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present, annotations provided), the description is adequate but lacks situational context. It does not mention when to prefer this over sibling meta-tools or what to do with the returned definition, making it not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'tool', with a clear description and example. The tool description does not add additional parameter semantics, 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.
Purpose4/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 ('Returns') and resource ('the full definition of a specific tool'), listing what that definition includes (description, annotations, input parameters, output shape). It is distinct enough from siblings like infomaniak_tool_catalog or infomaniak_overview because it targets a specific tool, though it does not explicitly name alternatives.
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 similar meta-tools like infomaniak_tool_catalog, infomaniak_overview, or infomaniak_help. It does not state conditions, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is well covered. The description adds the scope of resources but does not disclose additional behavioral traits like conditional parameter requirements or pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Read', and every word contributes to naming the resource scope. There is no filler, redundancy, or unnecessary 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?
This is a complex multi-resource tool with 10 enum values and 3 optional ID parameters, but the description lacks any guidance on how to choose the right resource or which parameters are needed for each case. Although an output schema exists, the description does not bridge the gap between the abstract purpose and concrete invocation, making it incomplete for reliable agent use.
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%, so the description carries the full burden of explaining parameters. It fails to explain the 'resource' parameter, the conditional ID parameters (team_id, account_id, invitation_id), or which IDs are required for which resource. The enumerated list merely restates the enum values already visible in the schema, adding no semantic value beyond what the schema 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 uses a specific verb 'Read' and identifies the resource as 'account inventory and governance drill-down resources', followed by an explicit enumeration of the resource types (accounts, products, services, tags, basic teams, team members, and B2B invitation customers). This clearly distinguishes it from sibling tools by covering a well-defined set of sub-resources.
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 reading the listed resource types, but it does not explicitly state when to use this tool instead of related siblings such as infomaniak_get_account_full or infomaniak_list_teams_and_tags. No when-not guidance or alternative suggestions are 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?
Annotations already declare readOnlyHint and idempotentHint, so the agent knows this is a safe read. The description adds no further behavioral context (e.g., return format, pagination, or any side effects). It does not contradict annotations, but provides no additional transparency beyond them.
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 that directly states the tool's function without unnecessary words. It is appropriately front-loaded and minimal.
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 3-parameter read operation, this description is incomplete. It lacks parameter semantics and explicit alternative guidance. While the output schema and annotations cover some context, the absence of any parameter explanation makes it hard for an agent to know what values to provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 required parameters (kaas_id, project_id, public_cloud_id) with no descriptions, and schema description coverage is 0%. The description does not explain what these IDs are, how they interrelate, or how to obtain them. This is a critical gap for tool invocation.
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 'Read one Public Cloud Kubernetes service' uses a specific verb (Read) and a clear resource (Public Cloud Kubernetes service). It distinguishes from sibling tools by implying a single get operation versus list (plural) or manage (mutating).
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 does not explicitly state when to use this tool versus alternatives like infomaniak_list_public_cloud_kubernetes_services or infomaniak_manage_public_cloud_kubernetes_service. Usage is only implied by the verb 'Read one', which suggests fetching a specific service, 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?
The description adds behavioral context beyond annotations by mentioning 'two-phase confirmation with a fresh invitation snapshot guard,' which hints at safety mechanisms. However, it does not explain what is destroyed or revoked, how the confirmation token works, or other side effects, relying heavily on the destructiveHint annotation.
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 purpose, and contains no filler. The second sentence adds important behavioral context without bloating the text.
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 complex 8-parameter, multi-action mutation tool with nested payloads and a two-phase confirmation flow, yet the description barely explains request construction. The vague 'snapshot guard' phrase and missing details on confirmation_token and payload leave significant gaps for correct 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 only 25%, and the description does not compensate. It maps high-level action/target enum values but leaves critical parameters like payload, mail_id, drive_id, and confirmation_token unexplained. The agent would struggle to construct valid requests, especially for actions like 'invite' or 'update'.
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 specific verbs ('Grant, update, invite, or revoke') and the resource scope ('invitation-scoped product access for kSuite, drive, mailbox, or kChat'). It distinguishes this tool from sibling invitation-management tools by focusing on product access rather than invitation CRUD itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus sibling tools like create_account_invitation, update_account_invitation, or delete_account_invitation. The name implies access management, but the description does not state exclusions or recommend alternatives for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'two-phase confirmation' behavior beyond annotations, which is crucial for understanding that actions require a confirmation token. Annotations already mark destructive/mutating, so the extra context about confirmation is valuable and not redundant.
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, compact sentence that front-loads the main actions and includes a key behavioral caveat. No wasted words.
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 multi-action CRUD tool with nested payload and confirmation flow, the description is too minimal. It omits when confirmation is required, what payload should contain, and how actions differ, making it insufficient for correct invocation despite the output schema.
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 provides no parameter details. It does not explain the roles of public_cloud_id, project_id, payload, or confirmation_token, leaving agents to infer semantics purely 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 clearly states the tool's function with specific verbs (create, update, delete, invite) and the resource (Public Cloud project). It distinguishes from sibling list/get/manage tools by enumerating the actions, and the 'two-phase confirmation' detail adds unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like list_public_cloud_projects or get_public_cloud_project. The description implies modification tasks but does not state exclusions or recommend alternatives for read-only operations.
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?
The description adds 'Two-phase commit with current invitation guard,' which reveals a non-obvious behavioral trait beyond the annotations (which only indicate write/non-idempotent). However, it doesn't explain what the guard does or how the confirmation token is used, leaving significant 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?
Two short sentences, front-loaded with the main action, and no extraneous words. Every word earns its place—efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves a nested payload, an optional confirmation_token, and a two-phase commit flow. The description is too sparse to guide an agent through the full invocation; it doesn't explain how to complete the second phase or what the 'current invitation guard' prevents. With such complexity, more operational context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 params described). The description's 'two-phase commit' hints at the role of confirmation_token, but it doesn't clarify the payload structure or how to obtain the token. This adds some value but doesn't fully compensate for the undocumented token 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 clearly states 'Invite a recipient to access a kDrive file or folder' with a specific verb and resource. This distinguishes it from sibling tools like create_drive_file_access_user or create_drive_file_access_team, which handle direct access grants.
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 (e.g., direct user/team access), nor does it mention prerequisites such as existing invitations or the need for a confirmation step. The two-phase commit mention is a hint but not actionable 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?
Annotations already indicate destructive and non-idempotent behavior, so the bar is lower. The description adds the 'Two-phase commit' detail and the fan-out forwarding behavior, which are useful. However, it doesn't disclose potential side effects, prerequisites beyond the schema, or what happens during the apply phase. It adds some context but not rich behavioral 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 two sentences, front-loads the primary purpose, and includes only essential information. It is concise and well-structured with no filler.
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 two-phase commit workflow is a significant behavioral complexity, but the description only mentions it in passing. It doesn't explain the phases, how to obtain the confirmation token, or the expected invocation sequence. While the schema documents the token, the description itself is incomplete for guiding an agent through a multi-step operation. The tool is also one of many redirection-related tools, and the description doesn't situate it within that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a detailed description (e.g., name pattern, targets format, mail_hosting_id discovery, confirmation_token purpose). The tool description adds no parameter semantics beyond what the schema already provides. 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 purpose: 'Create a server-side mail redirection.' This is a specific verb+resource pairing. It also explains the forwarding behavior ('Emails received at name@<domain> will be forwarded to every address in targets'), which adds clarity and distinguishes it from sibling tools like list or delete redirections.
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. It mentions 'Two-phase commit' as a process hint, but doesn't explain when to use it (e.g., for creating redirections) or when another tool like infomaniak_manage_service_redirections would be more appropriate. There are no clear usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, which cover the safety profile. The description adds the behavioral detail 'including pagination metadata when available', which is useful. Yet it does not elaborate on rate limits, authentication, or other operational behaviors, so it stays at a moderate level.
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 that front-loads the action ('Read') and the resource ('usage/consumption records'). Every word earns its place; no fluff or redundancy.
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 purpose is clear and an output schema exists, so return values are likely covered. However, the complete lack of parameter explanations, especially for the nested query object, leaves invocation details underspecified. The description is enough for tool selection but not fully sufficient for correct invocation without additional inference.
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?
With schema description coverage at 0%, the description must compensate, but it does not mention product_id or the query parameters (page, per_page, return) at all. The only thin hint is 'pagination metadata', which relates more to the response than to parameter usage. The agent must rely solely on parameter names, which is inadequate.
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 'Read' and the specific resource 'usage/consumption records for an Infomaniak AI product'. This distinguishes it from sibling AI tools like list_ai_products or get_ai_batch_result by focusing on consumption records. It is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need consumption records for an AI product, this is the tool. However, it provides no explicit alternatives, exclusions, or contextual differentiation from related AI tools. It is sufficient but not explicit.
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?
The annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safe read-only behavior is known. The description reinforces this and adds 'one' to indicate singular scope, but it does not add further behavioral context such as error handling, permissions, or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence: 'Read one Public Cloud project.' It is front-loaded with the action and resource, contains zero redundancy, and every word earns its place.
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 read-by-id tool with strong annotations and an output schema, the description is minimally viable. However, it lacks usage context and parameter semantics, so an agent may not know how to obtain the required IDs or distinguish this from related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or relationship of public_cloud_id and project_id. The parameter names are somewhat self-explanatory, but the description fails to compensate for the complete lack of schema descriptions.
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 'Read' and resource 'Public Cloud project', and the modifier 'one' clearly distinguishes it from list operations like infomaniak_list_public_cloud_projects. It is unambiguous and directly tied to the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention that list_public_cloud_projects should be used for enumeration, or how this differs from get_public_cloud, which could lead to incorrect selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a meaningful behavioral detail: 'Two-phase commit with a fresh team snapshot guard.' This goes beyond the annotations, which already indicate destructive and non-idempotent behavior, by revealing the commit process and concurrency protection. However, it leaves the exact mechanics and implications unexplained.
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 only two sentences and front-loaded with the main purpose. However, the phrase 'fresh team snapshot guard' is jargon that may require elaboration, slightly reducing effectiveness while maintaining 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?
For a destructive, non-idempotent mutation requiring a two-phase commit, the description omits crucial operational context: how the confirmation_token fits into the workflow, how the snapshot guard is triggered, and what happens on failure. The output schema may cover return values, but the process is 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 description does not reference any parameters. While the schema covers three of four parameters with descriptions, the critical confirmation_token is undocumented in the schema and entirely absent from the description, despite the two-phase commit implying its importance. The description adds no value for parameter understanding.
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: 'Update an account team.' It uses a specific verb and resource, and the name 'update_account_team' distinguishes it from create/delete/add/remove team operations among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like adding/removing team users or updating a tag. The two-phase commit mention hints at a specific workflow but does not explain prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and non-read-only. The description adds a 'current-state guard' suggesting deletion is conditional on the report's state, which is useful context beyond the annotations. However, it does not elaborate on failure behavior, needed authorizations, or the role of confirmation_token, so transparency remains partial.
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 redundant words, making it easy to scan and parse.
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?
Despite having an output schema and annotations, the description leaves important operational details unexplained: the meaning of the 'current-state guard', when deletion is allowed, and how the optional confirmation_token is used. The low parameter coverage amplifies this gap, so the tool is not fully contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with report_id and confirmation_token lacking descriptions. The description does not define these parameters; it only refers to the report generally and mentions a guard that might relate to confirmation_token but without specifics. Thus it fails to compensate for the schema gaps.
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 'Delete' with the resource 'generated kDrive activity report', clearly distinguishing it from sibling report tools (create/get/list/export). The phrase 'with a current-state guard' adds a clarifying condition without obscuring the primary action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, and does not mention exclusions. The term 'generated' implies a precondition but does not explain when deletion is appropriate or when to choose other report operations. Thus usage is only vaguely implied.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, establishing that this is a safe, read-only, idempotent operation. The description adds the 'complete user snapshot' context, which hints at the breadth of the return value, but does not disclose additional behavioral details such as permission requirements or error conditions. This is a minor addition beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the action and resource. There is no redundant phrasing, and it is front-loaded with the core purpose. It is appropriately sized for a simple read operation with strong structured metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich annotations, the description does not need to explain return values or safety. It provides enough context for an agent to know that this retrieves full user data for a specified drive user. However, it could have briefly mentioned that the tool requires both drive_id and user_id, which are already marked as required in the schema, so the gap is minor.
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 50% (only drive_id has a description). The description itself does not explain either parameter, nor does it clarify the relationship between drive_id and user_id. The parameter names are self-explanatory, but the description adds no extra meaning beyond the schema, failing to compensate for the missing user_id description.
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 'Read' and clearly identifies the resource as 'the complete user snapshot for a kDrive user'. It effectively distinguishes itself from sibling tools like list_drive_users (which lists users) and get_drive_full (which gets drive-level details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_drive_users or get_drive_full. It does not state explicit use cases, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and the generic action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint true, covering the safety profile. The description adds no behavioral context beyond the literal 'inspect', but does not contradict the annotations, so the baseline with annotations is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and contains no superfluous text. It communicates the essential action and resource without waste.
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 read-only getter with one parameter, an output schema, and strong annotations, the description is sufficient. The existing structured data covers return values, parameter meaning, and safety, so no additional context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for bot_user_id, so the schema already explains the parameter. The tool description adds no additional parameter semantics, but the baseline of 3 is warranted given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Inspect one kChat bot' uses a specific verb and clearly identifies the resource. The word 'one' differentiates it from list_kchat_bots, and 'inspect' contrasts with manage_kchat_bot, though it could be more explicit about retrieving details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like list_kchat_bots or manage_kchat_bot. The description does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description reinforces read-only and adds 'admin audit lookups' context, but does not disclose additional behavioral details like pagination or rate limits. It adds some value beyond annotations, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary verb and resource. No fluff. Exceptionally 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?
Despite having an output schema, the tool has a complex action enum with six distinct lookup modes. The description only provides a broad overview and does not clarify how to choose among the actions. This is a significant gap for correct 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 has 0% description coverage. The description mentions users, teams, and account-scoped access, providing a high-level overview, but it does not explain the specific action enum values or the optional parameters (team_id, user_id, account_id, mailbox_name). An agent would not know the difference between actions like 'user_team_accesses' and 'account_user'.
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 'Inspect' and identifies the resource as 'mailbox webmail access for users and teams' plus 'admin audit lookups'. It clearly states it is read-only, distinguishing it from the sibling manage tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (inspecting webmail access, admin audits) but does not explicitly state alternatives or when not to use it. The read-only nature is implied but not contrasted with manage_mail_webmail_access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, indicating a safe read-only operation. The description adds a subtle behavioral nuance by mentioning two modes (read vs. calculate), but it does not elaborate on output format, pagination, or any other behaviors beyond what annotations imply. The minimal extra context is credited, but the burden is largely on the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that begins with the primary action ('Read Swiss Backup pricing') and adds the alternative mode concisely. There is no redundant wording, and every word contributes meaning.
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 vague query parameter schema and the dual read/calculate behavior, the description is insufficient for an agent to know exactly what to pass or what to expect. The presence of an output schema partially covers return values, but the description does not explain how to structure the 'query' object or when to set 'calculate' to true. More detail is needed for correct 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%, so the description must compensate for the lack of parameter documentation. It mentions 'query parameters' in relation to calculating a price, hinting that the 'query' object holds pricing inputs, but it does not list or explain specific keys, or clarify the exact role of the 'calculate' boolean. This is only slightly more informative than the bare 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: reading Swiss Backup pricing or calculating a price from query parameters. It uses a specific verb ('Read'/'calculate') and resource ('Swiss Backup pricing'), distinguishing it from sibling tools that manage backups or retrieve backup details rather than pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for pricing-related tasks, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No comparison with sibling tools is provided, and there is no guidance on prerequisites or context where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds only the 'admin review' purpose, which is a use-case detail rather than a behavioral trait; no additional behavioral context like pagination or filtering is provided, but the output schema covers return values.
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 one sentence with just seven words, containing only the essential action and resource. There is no filler, repetition, or unnecessary detail, making it exceptionally 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 zero-parameter input schema, the available output schema, and the read-only annotations, the description is adequate for this simple list operation. The phrase 'for admin review' leaves slight ambiguity about the scope of the listing (all bots vs. pending review), but this is not a critical gap given the low tool complexity.
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 schema coverage is 100% vacuously. With no parameters to document, the baseline of 4 applies, and the description cannot add parameter semantics beyond what is already inherent to the tool.
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 (List) and resource (kChat bots), with the context 'for admin review.' It is distinct from sibling tools like get_kchat_bot (single bot) and manage_kchat_bot, but does not explicitly differentiate itself, so it's clear but not fully distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like infomaniak_get_kchat_bot or infomaniak_manage_kchat_bot. The phrase 'for admin review' hints at a use case but does not give explicit context, exclusions, or references to more appropriate tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the 'two-phase confirmation' detail, which is not present in the annotations, indicating that mutations require an extra confirmation step. However, it does not explain how the confirmation works or what precisely gets destroyed (though destructiveHint is already set). It provides some value beyond annotations but is 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 a key behavioral trait without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, including a free-form payload and action-dependent semantics (create vs update/delete). The description does not explain which parameters are required for each action, how to obtain needed IDs, or what the two-phase confirmation entails. Even with an output schema, an agent would struggle to invoke this tool correctly.
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 for parameter understanding. It only hints at the action parameter (create/update/delete) and the confirmation token via 'two-phase confirmation', but gives no guidance on the payload structure, kaas_id usage, or the roles of project_id/public_cloud_id. This is insufficient for a 6-parameter tool with a free-form payload.
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 specific verbs (Create, update, or delete) and names the exact resource (Public Cloud Kubernetes service). It also highlights a distinctive feature (two-phase confirmation) and clearly differentiates this mutation tool from the list/get sibling 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 action verbs imply when to use the tool (when creating, updating, or deleting), but there is no explicit statement of when not to use it or reference to alternatives like the get/list tools. The usage context is clear but implied rather than stated.
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?
The description adds the behavioral detail of 'two-phase confirmation,' which is not present in the annotations. However, it remains vague about the confirmation mechanism and does not elaborate on side effects beyond what destructiveHint already signals.
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 redundant words, effectively front-loading the core operations.
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 complex with 6 parameters including a nested payload and a confirmation flow, yet the description provides only a high-level summary. It does not clarify action-specific requirements, making it insufficient for reliable 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?
With 0% schema description coverage, the description fails to explain the purpose of payload, user_id, or confirmation_token. It only repeats the action enum values, leaving most parameters semantically unexplained.
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: to manage Public Cloud project users through create, update, delete, and invite operations, with two-phase confirmation. This distinguishes it from sibling list tools like list_public_cloud_project_users.
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 through the listed actions (create/update/delete/invite) but does not explicitly contrast with alternative tools or provide selection criteria. There's no mention of when to use this vs list_public_cloud_project_users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state destructive/non-idempotent behavior. The description adds 'Two-phase commit with a fresh account snapshot guard' and 'payload passed through as-is,' which are non-obvious behavioral traits. However, these are cryptic and not explained, leaving the agent without full understanding of the commit process or failure 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 two sentences, front-loaded with the core purpose, and every phrase adds some value (commit mechanism, snapshot guard, payload passthrough). 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-idempotent operation involving a two-phase commit, the description is too terse. It fails to explain what the two phases are, what the snapshot guard protects against, and what the confirmation_token is for. While an output schema exists, the process semantics are critical and remain underdescribed.
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 67%, covering payload and account_id but not confirmation_token. The description adds meaning to payload by stating it is passed through as-is, which is helpful. But it does not clarify confirmation_token's role in the two-phase commit, leaving a gap in parameter understanding.
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 'Create an account invitation,' which is a specific verb+resource pairing that distinguishes it from update, delete, list, and manage invitation tools. The action is unambiguous even though the two-phase commit mention adds technical detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when creating an account invitation) but provides no explicit alternatives or exclusions. It does not reference sibling tools like manage_account_invitation_b2b or update_account_invitation, so the usage context is clear but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds valuable behavioral context by detailing exactly what 'full certificate detail' means, including possible provisioning states (installed, updating, error) and validity flags. This goes beyond the annotations and helps the agent anticipate the kind of data returned, without contradicting the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the primary purpose and then lists the key data points with parenthetical examples. It is efficient with no wasted words, though it is quite long and run-on in style. The structure is logical and each clause adds meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required integer parameters) and the existence of an output schema, the description is remarkably complete. It enumerates nearly all relevant return fields, including states, types, validity flags, timestamps, fingerprint, and errors. It does not cover error conditions or prerequisites, but these are not critical for a straightforward read operation.
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 the parameters `hosting_id` and `site_id` at all. The parameter names are somewhat self-explanatory, but the description fails to explain their roles or relationship (e.g., which site on which hosting). With no param information in either the schema or description, the agent receives no guidance on how to populate required fields.
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 ('Return the full SSL certificate detail for one site on a web hosting') with a specific resource (SSL certificate) and scope (one site on a web hosting). It distinguishes itself from related siblings like request_certificate and delete_certificate by focusing on retrieval of existing certificate data. The enumeration of specific fields (provisioning state, type, issuer, validity flags, etc.) leaves 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for retrieving certificate details, but it does not explicitly state when to use this tool versus alternatives such as request_certificate or delete_certificate. No explicit 'when not to use' or alternative tool references are provided. The context is clear but the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds some context by specifying the categories of information returned, but it does not go beyond that to disclose potential error behavior, prerequisites, or other non-obvious traits. This is mild added value over the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that front-loads the action and resource, followed by a concise parenthetical list of included details. Every word is informative and there is no redundancy or 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 single-parameter read-only tool, the description provides sufficient context about what data is returned (DNS management status, DNSSEC, IDN, errors). The output schema exists, so return values need not be described. The only notable gap is the lack of relationship clarification with the sibling infomaniak_get_domain_full, which is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with a clear description ('The domain name, e.g. example.com'), so schema coverage is 100%. The tool description does not add any additional parameter semantics beyond what the schema already provides, which justifies the baseline score of 3.
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 uses a specific verb ('Get') and resource ('domain'), and lists the information categories covered (DNS management status, DNSSEC, IDN, errors). This clearly indicates what the tool does, but it does not explicitly distinguish it from the sibling tool infomaniak_get_domain_full, so it misses the full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving detailed domain information but provides no explicit guidance on when to use this tool versus alternatives like infomaniak_get_domain_full or infomaniak_get_domain_resources. No exclusions or alternative tool mentions are present, making the usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds cursor pagination and repeated filter support, which are useful behavioral details beyond annotations. However, it does not describe return format or any operational limits, so it remains within baseline value.
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 purpose, and every clause adds information. There is no redundancy or noise, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and strong annotations, the description adequately conveys the main capability across key dimensions. It covers the essential filtering dimensions (users, files, actions, time) and pagination. It could mention that multiple filters can be combined, but the current text is sufficient for an agent to understand 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?
Schema covers drive_id only, leaving query parameters undocumented. The description mentions cursor, actions, files, and users as filters, adding some meaning to those fields. However, it omits many other parameters like limit, from, until, order, and terms, so semantic coverage is only partially improved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as reading kDrive activity history, with explicit scope across users, files, actions, and time ranges. This distinguishes it from sibling tools like get_drive_file_activities and get_drive_root_activities, which target specific subsets.
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 choose this tool over alternatives like get_drive_file_activities or get_drive_root_activities. It only states capabilities, not selection criteria, so agents lack direction for tool 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?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds the scope constraint (single file/folder) but does not disclose additional behaviors like pagination, filtering, or depth handling offered by the query object. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, front-loading the action ('Read') and the resource ('activity history for one kDrive file or folder'). Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex query object and multiple sibling tools, yet the description is very brief. It does not mention the available filters, pagination, or depth options. While annotations and output schema cover some aspects, the description leaves notable gaps for a tool with this parameter complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only drive_id has a description). The description minimally explains that file_id refers to a file or folder, but the extensive query object parameters (from, depth, limit, order, terms, etc.) are entirely undocumented in the description, leaving users without guidance on their meaning or usage.
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 reads activity history for one specific kDrive file or folder. This distinguishes it from sibling tools like infomaniak_get_drive_activities (drive-wide) and infomaniak_get_drive_root_activities (root folder).
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 phrase 'for one kDrive file or folder' implies the tool is scoped to a single file/folder, but it does not explicitly state when to use this tool versus alternatives or mention any exclusion criteria. No alternative tool names are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the root-level scoping behavior, which is useful context, but it does not disclose pagination, filtering behavior, or return format. This aligns with the calibration example where scope context is credited but lacks behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose without redundancy or filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderately complex query object and a large sibling set, and while the output schema and annotations exist, the description does not explain available filters or how this tool differs from get_drive_activities and get_drive_file_activities. It is adequate but leaves room for agent confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (drive_id is described, query is not), and the tool description mentions no parameters at all. The description does not compensate for the undocumented query object or explain how 'root-level' relates to parameters like depth or files.
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 'Read' and identifies the resource ('activity history') with a clear scope ('root-level kDrive files and folders'). This scope distinguishes it from sibling tools like infomaniak_get_drive_activities and infomaniak_get_drive_file_activities.
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 'root-level' qualifier implies it should be used for activities at the drive root, but the description does not explicitly state when to use this tool over alternatives or provide exclusions. No sibling tool is named, so usage guidance remains 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, openWorldHint) already cover safety and idempotency. The description adds 'in detail' and implies a single resource, but these are minor and largely inferable from schema/annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. Every word adds value ('Read,' 'one,' 'in detail'), and it is 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with an output schema and read-only annotations, the description is minimal but not fully complete. It lacks guidance on using list_swiss_backups to obtain the ID or what 'in detail' entails, though the output schema may cover return structure.
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 explicitly describe swiss_backup_id beyond referencing 'one subscription.' The param name is self-explanatory, but the description fails to compensate for the lack of schema documentation, such as where to find the ID.
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 'Read' with a clear resource 'one Swiss Backup subscription' and specifies 'in detail,' distinguishing it from sibling tools like listing all subscriptions or accessing slots/pricing. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need details of a single subscription) but does not explicitly state when to use vs alternatives or provide any exclusions. No mention of 'list' to find IDs, though siblings are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description's 'Read' is consistent but adds no new behavioral context (e.g., authentication, rate limits, or output specifics). It doesn't contradict annotations, but also doesn't enhance them.
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 a front-loaded verb and no filler. Every word contributes to defining the tool's purpose.
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?
With only one parameter and an output schema present, the description is adequate for a simple read operation. However, it lacks parameter semantics and differentiation from sibling Swiss Backup tools, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the required 'swiss_backup_id' parameter. The phrase 'for a Swiss Backup subscription' hints that the ID identifies the subscription, but the description fails to provide explicit guidance on how to obtain or interpret this value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with a clear resource: 'Acronis connection information for a Swiss Backup subscription.' This precisely identifies the tool's action and scope, distinguishing it from sibling tools like get_swiss_backup or get_swiss_backup_slot.
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 Acronis connection info') but provides no explicit alternatives or exclusions. Sibling Swiss Backup tools exist, yet no guidance is given on when to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds useful context about pagination support and the ability to list root or a specific folder. It does not detail limits or edge cases, but with annotations present, 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?
The description is a single concise sentence that front-loads the action and resource. It adds value without unnecessary words, making it an efficient and focused description.
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?
With an output schema and annotations, the tool is partially covered. The description provides basic context (root/folder, pagination) but lacks details on parameter usage, page/per_page defaults, and potential alternative tools. For a 4-parameter tool with low schema coverage, this is a minimal but not fully complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only parent_id has a description). The description mentions pagination and folder selection but does not explain drive_id, page, or per_page parameters. It partially compensates for the coverage gap but leaves key parameter semantics undocumented.
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 ('files and subfolders of a kDrive root or a specific folder'). It distinguishes from sibling tools like list_drive_trash and list_drive_share_links by focusing on the file/folder listing operation.
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 conveys when to use the tool: when listing files/subfolders in a drive. However, it does not explicitly mention alternative tools or state exclusions (e.g., when to use list_drive_trash instead). The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context about the API surface ('Mattermost-compatible') and administrative scope, which is useful, but it does not disclose additional behavioral details like pagination or filtering semantics beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action, and contains no filler or redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (one optional parameter), the presence of an output schema, and the read-only annotations, the description covers the essential purpose and context. A minor gap is the lack of explicit distinction from the similarly named 'list_kchat_team_channels' tool, but overall 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?
Schema coverage for the single parameter (team_id) is 100% with a clear description, so the baseline is 3. The tool description adds no extra parameter context, but the schema already suffices.
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 lists kChat channels within the account, using a specific verb and resource. It distinguishes from the similar sibling 'infomaniak_list_kchat_team_channels' by emphasizing account scope, though it does not explicitly contrast with that tool.
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 admin/governance tasks via the phrase 'admin/governance side,' but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. The context is present but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations readOnlyHint, idempotentHint, and openWorldHint already indicate safe, read-only behavior. The description adds slight context about the scope (configured on a mail hosting) but no further behavioral details such as return format or pagination. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that starts with the verb 'List' and contains no fluff. Every word contributes to the 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 simple read-only list tool with one self-explanatory parameter and an output schema present, the description is nearly complete. It lacks explicit usage context but is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly references the parameter by mentioning 'a mail hosting,' but does not explicitly explain mail_hosting_id or provide format guidance. The parameter name is self-explanatory, so the gap is moderate.
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 ('List') and resource ('mailing lists') and adds the scope 'configured on a mail hosting.' It is unambiguous but does not explicitly distinguish from sibling tools like list_mailboxes, though the resource is distinct.
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 to list mailing lists for a mail hosting) but provides no explicit guidance on alternatives, prerequisites, or when not to use it. For a simple list tool, the implied usage is acceptable but not elaborate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds no further behavioral context such as pagination, permission requirements, or return details. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence ('List users with access to a Public Cloud project.') with no filler or redundant wording. It is appropriately sized for a simple list operation.
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?
With an output schema present and strong annotations, the minimal description is somewhat adequate. However, it lacks guidance on parameter disambiguation and differentiation from similar list/manage tools, leaving moderate gaps for a tool with such a rich sibling context.
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 only says 'Public Cloud project' and does not explain the roles of project_id vs public_cloud_id, leaving the two integer parameters 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 uses the specific verb 'List' and identifies the resource as 'users with access to a Public Cloud project'. This clearly differentiates the tool from siblings like list_public_cloud_projects and manage_public_cloud_project_user.
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 (to see users with access to a project) but provides no explicit guidance about alternatives, exclusions, or prerequisites. It does not mention sibling tools such as list_public_cloud_accesses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, and idempotentHint true, so the agent knows this is a safe read operation. The description adds the fact that this is Acronis-based, which is contextual but not behavioral. It does not detail any potential edge cases, pagination, or response structure, but the annotations carry most of the load.
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 immediately states the action and resource, with no filler or redundant information. It is appropriately brief for a simple list tool.
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 and an output schema, the description is fairly complete. It states the resource type, scope (Infomaniak organization), and notes the underlying technology (Acronis). It could clarify the relationship to Swiss Backup slots, but that is not essential for basic 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 only parameter, account_id, is fully described in the schema (100% coverage), including its optionality and default behavior. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Swiss Backup subscriptions on an Infomaniak organization, with a specific verb and resource. It partially distinguishes from the sibling 'infomaniak_list_swiss_backup_slots' by specifying 'subscriptions' rather than 'slots', but it does not explicitly mention the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to list Swiss Backup subscriptions, which is a typical read operation. However, it provides no explicit context about when to choose this tool over related siblings like list_swiss_backup_slots or get_swiss_backup, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context by specifying the exact return payload (primary FQDN plus preview URL) and noting that it is Manager-private, implying access restrictions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, starts with the action verb 'List', and contains no redundant information. It is front-loaded and every sentence earns its place.
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 explains what the tool returns, which combined with the output schema provides useful context. However, it lacks explicit parameter explanation and usage guidance, leaving the required inputs ambiguous. Given the tool's simplicity and annotated safety, it is partially complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema requires hosting_id and vhost_route_id, but the description does not mention or explain these parameters. With 0% schema description coverage, the description carries the burden to clarify the meaning of these identifiers, and it fails to do so, leaving users without guidance on what values are expected.
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' and clearly identifies the resource as 'FQDNs (domain names) serving a Node.js application,' explicitly stating the return includes the primary FQDN and automatic preview URL. This distinguishes it from sibling tools like list_site_aliases by scoping to Node.js apps, and from get_nodejs_app which focuses on broader app details.
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 is used to retrieve FQDNs for a Node.js app, but it does not explicitly state when to use it over related tools such as list_site_aliases or get_nodejs_app, nor does it provide exclusion criteria. The 'Manager-private' note hints at restricted access but does not offer usage 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context beyond these: 'Manager-private' indicates access control, and 'JWT-protected log_stream endpoint per job' reveals a detail about the response. This adds behavioral transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key purpose. It includes essential information (jobs, status, log_stream endpoint, manager privacy) without any 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 mentions the output element (log_stream endpoint), and an output schema exists which helps. However, it lacks explanation of the required parameters and does not reference related tools, leaving some contextual gaps for a tool that requires two identifiers to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the meaning or purpose of hosting_id or vhost_route_id. The parameter names are not self-explanatory, and the description does not mention them at all, leaving the agent without guidance on how to populate these required fields.
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 specifies the resource ('recent jobs that ran for a Node.js app') with examples ('builds, restarts, etc.'). It also mentions the output includes status and a JWT-protected log_stream endpoint, making it distinct from sibling tools like status or logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (listing jobs for a Node.js app) and indicates it is 'Manager-private', but it does not explicitly state when to use this tool versus alternatives such as infomaniak_nodejs_app_status or infomaniak_nodejs_app_logs. No exclusions or comparative guidance is 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?
Annotations already mark destructiveHint=true. The description adds behavioral context with 'two-phase commit' and 'current file-access guard', signaling that a confirmation step and access check are involved. This adds value beyond the annotation flags.
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 short sentences with front-loaded purpose and a useful safety warning. No filler.
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 destructive and has a two-phase commit, but the description doesn't connect this to the confirmation_token parameter or explain the guard behavior. With an output schema present, return values are covered, but the critical confirmation flow is under-specified.
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 drive_id, file_id, user_id. The description does not explain confirmation_token or how it relates to the two-phase commit. At 75% schema coverage, the description adds no parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (revoke), target (user access to kDrive file/folder), and distinguishes from siblings like remove_drive_file_access_team. The phrase 'Destructive two-phase commit' adds a distinguishing safety trait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives such as remove_drive_file_access_team or update_drive_file_access_user. The 'current file-access guard' hints at a precondition but doesn't state when not to use or direct to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations with 'Two-phase commit' and 'current user guard', which are not stated in the annotations. However, these terms are cryptic and not elaborated, leaving uncertainty about what the guard actually does and when a confirmation token is mandatory. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently states the action, endpoint, and key behavioral flags. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex mutation with a nested user object, optional confirmation token, and a guard, yet the description is only one sentence and omits crucial workflow details like when the token is required or what the current user guard protects against. The existence of an output schema does not compensate for the missing behavioral and payload context.
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 covers drive_id and user_id descriptions, but the description adds meaning to the optional confirmation_token by mentioning two-phase commit, which explains its purpose. The 'current user guard' also implies constraints on user_id. It does not clarify the user object payload structure, but schema coverage is 75% and the endpoint reference provides a pointer.
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 'Update a kDrive user' and gives the exact PUT endpoint, making the action and resource unambiguous. It distinguishes itself from sibling operations like create, delete, lock, and set manager by the verb 'update' and the explicit target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as infomaniak_set_drive_user_manager or infomaniak_lock_drive_user. The mention of 'two-phase commit' hints at a workflow but does not explain prerequisites, required confirmation tokens, 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?
Annotations indicate readOnlyHint=false and destructiveHint=true, and the description adds important behavioral context: the two-phase commit, the requirement for a confirmation token, and that creation only happens on the second call. This goes beyond the annotations and does not contradict them.
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. The first clearly states the action, and the second explains the necessary two-phase flow, with no redundant wording.
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 captures the essential two-phase workflow and is supported by an output schema and annotations. However, it omits prerequisites and alternative tool references, so it is slightly above minimum viability but not fully comprehensive.
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 only mentions confirmation_token, without explaining hosting_id, fqdn, directory, or environment. It fails to compensate for the lack of parameter documentation, providing almost no semantic value for most parameters.
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 creates a new site on Infomaniak web hosting, with a specific two-phase commit. It does not explicitly differentiate from sibling tools like infomaniak_provision_site_full, so it lacks sibling distinction.
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 explicit usage guidance by explaining the two-phase commit: first call returns a plan with confirmation_token, second call with same params + token creates the site. However, it does not mention when to use this tool versus alternatives or any 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?
The description adds 'two-phase commit with a fresh tag snapshot guard,' which conveys a safety mechanism beyond the annotations' destructiveHint:true. It hints at the need for confirmation and snapshot freshness, adding valuable behavioral context, though it remains somewhat cryptic.
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 with no filler. The action is front-loaded, and the qualifier adds important context without unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with a two-phase commit, the description is terse. It alludes to a safeguard but doesn't explain the process, the error conditions, or how the confirmation token works. The presence of an output schema covers return values, but procedural context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema coverage, the schema handles the required parameters. The description indirectly explains the optional confirmation_token by referencing a two-phase commit, but it doesn't explicitly define the token's role or acquisition method. It partially compensates for the missing schema description.
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 'Delete an account tag' with a direct verb and resource. It distinguishes itself from sibling tools like create_account_tag and update_account_tag, and the additional 'two-phase commit' phrase doesn't obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_account_tag. There are no exclusions, prerequisites, or decision rules, leaving the usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral detail 'Two-phase commit with a fresh team snapshot guard,' which goes beyond the annotations' destructive and non-read-only hints. This provides insight into the internal safety mechanism without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundant words. It efficiently conveys the core function and a key behavioral 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?
For a destructive operation, the description is minimal. It includes a key safety note but does not explain the snapshot guard or when the confirmation_token is required. The output schema covers return values, but gaps remain about prerequisites and the two-phase commit process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: team_id and account_id have descriptions, but confirmation_token does not. The description's mention of two-phase commit hints at the token's role but does not explicitly explain it, so it adds only marginal value 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 'Delete an account team' with a specific verb and resource. It distinguishes from sibling team operations like create/update/add/remove, and the extra detail about two-phase commit 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as update_account_team or remove_account_team_users. The description does not mention prerequisites, conditions, 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?
The description adds the 'Two-phase commit with current filter inventory guard before DELETE' behavior, which is not covered by the annotations. This provides useful insight into the deletion process beyond the simple destructiveHint annotation, though it does not explain the implication of this guard in detail.
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 crisp sentences: the first states the purpose, the second notes a key safety behavior. Every word earns its place, with no redundant or vague text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 4 parameters and an output schema, the description covers the core operation and a safety mechanism, but it does not explain the two-phase commit mechanics, the optional confirmation_token, or how to obtain the filter name. It is adequate for basic selection but leaves gaps for full understanding.
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 descriptions for 3 of 4 parameters (75% coverage), including clarity on mailbox_name (local part) and mail_hosting_id discovery. The description itself does not add parameter-specific meaning, and the optional confirmation_token parameter remains undocumented in both the description and 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 'Delete a mailbox Sieve filter by name' with a specific verb and resource. This distinguishes it from sibling tools like infomaniak_delete_mailbox_filter_script by emphasizing the filter (not script) and the deletion action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description does not mention list/create/update filter tools, nor does it state prerequisites such as obtaining the filter name via a listing tool. The schema hints at discovering mail_hosting_id, but the description itself offers no 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?
The annotations already declare readOnlyHint and idempotentHint, and the description aligns with these. It adds the scope dimension ('at the mailbox or service level') but does not disclose additional behavioral traits like pagination, rate limits, or required permissions. Since annotations cover the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and target resource, and the second sentence reinforces the read-only nature and intended use. Every word earns its place, with no redundant or vague filler.
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?
Despite having annotations and an output schema, the required 'action' parameter is completely undocumented in both the schema and description. An agent would not understand the difference between list, show, and show_default from the description alone. With 7 parameters and 4 required, this is a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, with descriptions for scope, resource, mailbox_name, and mail_hosting_id. However, the required 'action' parameter (list/show/show_default) has no description, and neither do 'signature_id' or 'template_id'. The description adds no parameter-level meaning beyond the schema, so it fails to compensate for the gaps.
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 'Inspect' and clearly identifies the resources (mailbox signatures and signature templates) and scope levels (mailbox or service). It distinguishes itself from the sibling 'infomaniak_manage_mail_signatures' by emphasizing 'Read-only inventory', making its purpose unmistakable.
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 with 'Read-only inventory for admin review and template selection', implying when to use it (inspection) rather than management. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a full 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?
Annotations already declare read-only, idempotent, and open-world hints. The description adds the notion that reports are 'generated' and that filtering is possible, providing a small amount of extra context. However, it does not disclose pagination behavior, authentication needs, or other operational details beyond what annotations imply.
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 action, resource, and key optionality efficiently.
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?
With an output schema present and annotations covering safety, the description is minimally adequate. However, it does not explain the query object's structure beyond a vague reference to filters, nor does it mention that the list is paginated. The schema compensates, but a bit more guidance would improve completeness.
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%, so the description partially compensates by mentioning 'filtered by users and report status metadata.' However, it does not explain the nested query object, pagination (page, per_page), ordering (order, order_by), or other parameters. It adds some meaning but leaves much to 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 ('List') and resource ('generated kDrive activity reports') and distinguishes this tool from siblings like get_drive_activity_report (singular) and create/delete/export report tools. It clearly communicates that this is a listing operation with optional filtering.
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 stating the tool lists reports and can filter by users and status metadata, but it does not explicitly mention when to use this vs alternatives (e.g., get_drive_activity_report for a single report). 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint true, and the description's 'List' is consistent. It adds small context that the response includes job state, but no further behavioral caveats or pagination warnings are provided, so it meets but does not exceed the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence delivers the essential purpose with no filler. It earns high marks for clarity and brevity.
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 operation, the description covers the core semantics, and the provided output schema handles return-value details. However, it leaves the purpose of required parameters and the optional query behavior unexplained, which is acceptable but slightly incomplete for a tool with nested query options.
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 only hints at mailbox scope without explaining mail_hosting_id or the query object's options. The required identifiers and pagination/filtering fields are left entirely to the schema, failing to compensate for the low 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 uses a specific verb ('List'), identifies the resource ('email-import jobs'), and adds scoping ('for a mailbox'). It clearly distinguishes from sibling mailbox tools like list_mailboxes, which focus on mailboxes rather than import jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving email-import job statuses, but it does not explicitly state when to choose it over alternatives or provide exclusion criteria. There are no sibling email-import tools, so the use case is evident from the name, but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld, covering the safety profile. The description adds that results include environment and SSH flag, but does not disclose pagination, ordering, or error behavior. This is acceptable given the read-only nature.
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?
Single sentence with no filler, front-loaded verb, and concise parenthetical about output fields. 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 listing tool with one parameter, an output schema, and safety annotations, the description is sufficient. It states the resource and included fields, and the schema covers the required input. It could mention that hosting_id is required, but that is already in the schema, so the description remains 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?
The schema has one required parameter (hosting_id) with 0% description coverage. The description refers to 'a web hosting' but never mentions 'hosting_id' or explains how to identify the hosting. The agent must infer the parameter from the schema alone, so the description adds no semantic value for 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 the verb 'List' with a specific resource ('FTP/SSH users') scoped to 'a web hosting', and mentions included fields (environment, SSH flag). This clearly differentiates it from siblings like list_hostings or create_hosting_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for enumerating users on a specific web hosting, but it does not explicitly state when to choose this over alternatives such as create_hosting_user or list_database_users. No when-not or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds the context that the models are 'service-level' and 'reusable,' which clarifies the scope, but does not elaborate on return formatting or additional behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence containing only the essential information, front-loaded with the action verb. 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 list tool with one parameter and an output schema, the description is adequate. It identifies the resource scope (service-level vs mailbox-level) and the reusable nature, but could benefit from clarifying what filter models are or how they relate to mailbox filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for mail_hosting_id (0% coverage), and the tool description does not mention parameters at all. The sole parameter is self-explanatory from its name, but the description fails to compensate for the schema gap.
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' and identifies a distinct resource: 'service-level reusable mail filter models.' This clearly differentiates it from sibling tools like list_mailbox_filters, which target mailbox-level filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives is provided. The 'service-level' qualifier implies this tool is for reusable models rather than per-mailbox filters, but no direct exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint true, so the safe read behavior is covered. The description adds scope (given web hosting) and mentions applications are attached, but doesn't disclose pagination, ordering, or result size. It is consistent with annotations and adds limited 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?
A single, front-loaded sentence that communicates purpose and a clarifying parenthetical. No filler, no redundant content, and the structure is easy to parse.
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 operation with one parameter, good annotations, and an output schema, the description is close to sufficient. It could be more complete by explaining how to obtain hosting_id or when to use this vs find_site, but the essential behavior is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the description doesn't explain the single 'hosting_id' parameter beyond saying 'given web hosting'. Since coverage is low, the description should compensate, but it doesn't clarify the parameter type, semantics, or where to find the ID. The param name is self-explanatory, which gives minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Lists' and identifies the resource 'all sites on a given web hosting', with a parenthetical clarifying that attached applications are included. It clearly distinguishes from sibling tools like infomaniak_list_hostings (which lists hostings) and infomaniak_find_site (which finds sites).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing sites when you have a hosting_id, but provides no explicit when-to-use guidance, exclusions, or alternatives. It doesn't mention that infomaniak_find_site or infomaniak_list_hostings could be used for related tasks, so 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the two-phase confirmation process and refetch-before-apply behavior, which adds context beyond the annotations' destructive hint. However, it doesn't detail confirmation token handling or side effects of deletion, leaving room for more 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 two concise sentences, front-loaded with action verbs, and contains no redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, multiple enums, and a two-phase workflow, the description is too brief. It omits parameter interactions, how to obtain a confirmation token, and prerequisites like mail_hosting_id discovery, making it incomplete for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 56%, and the description adds little beyond the action list. It doesn't explain payload structure, the relationship between scope/resource and other parameters, or the confirmation_token requirement, so it fails to compensate for the incomplete schema descriptions.
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 enumerates the tool's capabilities (create, update, delete, upload, set defaults, generate) and identifies the resource (mail signatures/templates). It distinguishes itself from read-only siblings like get_mail_signatures by focusing on mutation actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are given; usage must be inferred from the tool name and action list. It does not mention when to prefer this over other mail management tools, but the implied context is managing signatures and templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, readOnly=false, idempotent=false; the description adds valuable behavior beyond this by stating 'Uses two-phase confirmation and rechecks the current list before apply,' which warns the agent that operations may need a confirmation_token and may fail or change after rechecking. No contradiction with annotations; it reinforces the destructive/mutating nature.
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 short sentences; the first is a dense front-loaded action list, the second adds a critical operational caveat. Every phrase earns its place with no filler.
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 tool exposes 13 actions (including ambiguous delete_subscriber vs forget_subscriber vs unsubscribe_subscribers) and 6 params, yet the description gives no guidance on action selection, required payloads, or confirmation flow specifics beyond the single caveat. The output schema exists, so return values may be covered elsewhere, but the operational ambiguity makes the description insufficient for safe use of a destructive multi-action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (domain and payload are described in the schema, but group, subscriber, action, and confirmation_token are not). The description mentions groups/subscribers and two-phase confirmation indirectly, but does not explain identifier formats, payload semantics, or how the action enum maps to specific params, so it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb list ('Create, update, delete, assign, unassign, or forget') tied to concrete resources ('newsletter groups and subscribers'), clearly identifying the tool as the management counterpart to the read-only get_newsletter_admin sibling. The scope is unambiguous and distinguishes it from other Infomaniak manage 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?
No explicit when/when-not guidance or alternative tools are named; the description implies usage by listing mutating operations, and the 'two-phase confirmation' clue suggests a workflow but not when to choose it over get_newsletter_admin or how to choose among the many action values. This is only implied usage, not stated 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?
The description discloses the two-phase confirmation behavior, which is not captured in the annotations (readOnlyHint=false, destructiveHint=false). This adds useful context beyond the structured metadata, though it does not detail the exact workflow or 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 a single, front-loaded sentence that immediately states the core purpose. There is no unnecessary verbosity or repetition.
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 involves multiple parameters, a nested payload, an output schema, and a two-phase confirmation workflow, yet the description only provides a high-level summary. The confirmation process and payload structure are critical for correct invocation but remain undefined, making the description insufficient for a complex operation.
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?
With schema description coverage at 0%, the description must compensate, but it only indirectly hints at some parameters: 'create/update' maps to the action enum, 'Swiss Backup subscription' implies swiss_backup_id, and 'two-phase confirmation' implies confirmation_token. The payload object, a required parameter, is completely unaddressed, leaving its structure and content 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 clearly states the specific action ('Create or update') and resource ('administrator for a Swiss Backup subscription'). It also mentions the two-phase confirmation, which helps differentiate it from related tools like infomaniak_manage_swiss_backup_slot.
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 that this tool is used to create or update an administrator, but it does not explicitly state when to use it over alternatives or provide usage context. The two-phase confirmation is mentioned but not explained in terms of when each phase applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-readonly, non-idempotent write operation. The description adds valuable behavioral context with 'Two-phase commit with current share-link guard,' alerting the agent to a multi-step process and a potential existing-link check that would not be known from annotations alone. However, the exact semantics (e.g., failure vs. replacement) remain vague.
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 and every word contributes: action, endpoint, and a critical behavioral caveat. It is front-loaded and free of filler.
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?
Despite having an output schema, this tool has a complex shape: 4 parameters including a nested unstructured 'link' object, and a non-idempotent create operation with a two-phase commit. The description does not explain how to construct the link payload, when confirmation_token is needed, or what the 'current share-link guard' does. Sibling tools for discovery are also not referenced.
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 75%, with drive_id, file_id, and link already described. The description does not add parameter-specific guidance beyond repeating endpoint variables. The 'two-phase commit' hint may relate to confirmation_token, but the connection is not made explicit, and the link object is left as an opaque payload.
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 'Create a kDrive share link' with a specific endpoint (POST /2/drive/{drive_id}/files/{file_id}/link), using a specific verb and resource. It distinguishes itself from sibling tools like update_drive_share_link, list_drive_share_links, and remove_drive_share_link.
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 when one wants to create a new share link, but it does not explicitly state when to use this tool versus alternatives like get_drive_share_link or list_drive_share_links. The mention of 'current share-link guard' hints at a precondition but leaves the agent guessing whether to check for existing links first.
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?
Beyond the annotations (which indicate a non-read, non-destructive operation), the description adds 'Two-phase commit with current user-list guard'. This reveals non-obvious behavior about how the creation is processed and that a guard checks against the current user list, which is valuable for an agent to anticipate.
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 efficiently conveys the core action, the endpoint, and a key behavioral trait.
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 action and mentions two-phase commit, but does not explain how the confirmation_token is used or what the 'current user-list guard' does. While output schema and annotations reduce some burden, the two-phase commit flow is a significant gap that should be elaborated.
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 67%, and the description does not clarify the confirmation_token or the user object structure. The 'two-phase commit' phrase hints at the purpose of confirmation_token but never explicitly connects it, leaving important parameter semantics unexplained.
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 'Create a kDrive user through POST /2/drive/{drive_id}/users', combining a specific action verb, the resource type, and the exact endpoint. This distinguishes it from sibling tools like infomaniak_create_drive_file_access_user or infomaniak_update_drive_user.
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 through 'Create a kDrive user', but it does not explicitly explain when to prefer this over alternatives or provide exclusions. The 'two-phase commit' hint gives some context but no direct guidance on preconditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and destructive behavior. The description adds the 'Two-phase commit' detail, which is a notable behavioral trait beyond the annotations. However, it does not explain what the two phases are or that a confirmation_token is required, leaving important process behavior undisclosed.
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 purpose, and every word earns its place. The phrase 'Two-phase commit' is terse but conveys a critical constraint without unnecessary 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?
An output schema exists, so return values are covered. However, the two-phase commit process is underspecified: the description does not tell the agent that a confirmation token is needed or how the phases work. For a tool with a non-simple workflow, this is a notable gap in completeness.
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 implicitly clarifies alias and mailbox (via 'Add a new alias to an existing mailbox'), and mail_hosting_id is implied as an identifier, but the confirmation_token parameter—critical for the two-phase commit—is completely omitted. This leaves a key parameter unexplained.
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 (Add), the object (a new alias), and the target (an existing mailbox). It also explains the functional effect ('The alias will receive emails delivered to the underlying mailbox'), which distinguishes it from sibling tools like manage_mailbox_aliases.
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 for when to use the tool: adding a new alias to an existing mailbox. However, it does not explicitly mention alternatives or exclusion criteria (e.g., when to use manage_mailbox_aliases instead), so it lacks full if-then 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?
Beyond annotations (destructiveHint=true, readOnlyHint=false), the description discloses two-phase commit behavior and explicitly warns that all stored emails are deleted, adding valuable context not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, high-impact sentences: purpose, two-phase commit, and warning. Every sentence earns its place with zero waste.
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 destructive nature and two-phase commit, the schema compensates with detailed parameter descriptions (e.g., confirmation_token, verification steps) and an output schema exists. The description is brief but sufficient when combined with structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself contains no parameter details, but schema coverage is 100% with rich descriptions for each parameter, so the baseline of 3 applies. No added value from the description, but no gap either.
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 'Delete a mailbox' with a specific verb and resource, and the warning about deleting all stored emails distinguishes it from related mailbox operations like purging spam or emptying trash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives, nor any prerequisites. 'Two-phase commit' hints at a workflow but does not explain the plan/execute flow or recommend verifying with infomaniak_list_mailboxes beforehand (though the schema does provide this).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'permanently' and 'after confirmation', which are not fully captured by the annotations (destructiveHint, readOnlyHint). This communicates irreversibility and a confirmation step, providing useful behavioral context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no filler. It is front-loaded with the action and resource, making it easy to parse quickly.
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 captures the core purpose and irreversible nature, but it omits details about the confirmation token parameter and how it is used. While an output schema exists and annotations cover safety flags, the parameter semantics gap makes the description incomplete for accurate tool 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 explain the purpose of mail_hosting_id, mailbox_name, or confirmation_token. The only hint is 'after confirmation', which aligns with confirmation_token, but parameter roles are not explicitly clarified. This is a significant gap since the description must compensate for missing schema descriptions.
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 ('permanently delete'), the target ('all messages in a mailbox trash folder'), and a key condition ('after confirmation'). It distinguishes itself from sibling tools like infomaniak_purge_spam_folder and infomaniak_empty_drive_trash by specifying the mailbox trash folder.
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 usage context is implied by the description and name, but there are no explicit instructions on when to use this tool versus alternatives (e.g., purging spam folder) or any prerequisites. It is clear enough for a single-purpose tool but lacks explicit 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering the safety profile. The description adds that the tool can read 'export endpoints', which introduces the export feature, but it does not explain what the export endpoint does or when it applies. No contradiction with annotations is present.
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 sentence, front-loaded with the main verb and resource, then a compact list of statistic families. No wasted words or redundant information; it is appropriately sized for the tool's scope.
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 read-only statistics tool with a detailed input schema and an output schema, the description provides a sufficient high-level overview. It covers what the tool does and the available statistic types, but lacks explicit clarification on export endpoint usage and comparison with sibling activity tools, leaving a small gap in fully self-contained guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, including drive_id, statistic, query, and export, with clear meanings. The description adds value by translating the statistic enum values into concrete categories (storage sizes, activity summaries, user activity, shared-file activity, share-link activity), making it easier for the agent to map a user's intent to the correct statistic.
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 'Read' and the resource 'kDrive admin statistics', then enumerates the statistic families: storage sizes, activity summaries, user activity, shared-file activity, and share-link activity. This specificity distinguishes it from siblings like infomaniak_get_drive_activities or infomaniak_list_drive_activity_reports, which target raw activities or reports respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus the many sibling activity-related tools (e.g., infomaniak_get_drive_activities, infomaniak_get_drive_activity_report, infomaniak_export_drive_activity_report). The phrase 'admin statistics' implies a summary use case, but the description does not state alternatives or exclusions, leaving the selection ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the read-only nature is covered. The description adds the 'admin inspection' context but no additional behavioral details such as pagination or required permissions. No contradiction exists.
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 one succinct sentence that front-loads the verb and resource. It contains no filler words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple read-only getter with a single parameter and an output schema, the description is adequate. It does not explain return structure (handled by output schema) but is sufficient for a basic retrieval tool. Could mention what kind of channel info is returned, but not necessary.
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 documents the single parameter with a clear description ('kChat channel id'), so the schema covers semantics. The description adds no further parameter context, but given 100% coverage, 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 identifies the action (Get), the resource (one kChat channel), and the context (for admin inspection). It distinguishes itself from sibling list tools by specifying 'one channel'. The phrase 'for admin inspection' also clarifies intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when inspecting a specific kChat channel but does not explicitly state when to prefer this over list_kchat_channels or get_kchat_channel_moderation. It lacks explicit exclusions or alternatives, so guidance is implied rather than stated.
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?
The description adds no behavioral details beyond what annotations already declare (readOnlyHint, idempotentHint). It does not contradict annotations, but also does not provide extra context such as response format or prerequisites, which is acceptable given the simple read-only nature.
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 filler. It conveys the essential purpose efficiently.
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 is a simple get-by-id operation with one parameter, clear annotations, and an output schema. The description is sufficient for an agent to select and use it correctly, though it does not mention how to obtain the command ID (e.g., via list_kchat_commands), which would be a minor improvement.
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 covers 100% of the single parameter, and the description 'kChat command id.' is clear but minimal. The tool description adds no additional meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Inspect one kChat slash command' uses a specific verb and resource, clearly indicating a read operation on a single command. This distinguishes it from sibling tools like infomaniak_list_kchat_commands (list all) and infomaniak_manage_kchat_command (modify).
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 does not explicitly state when to use this tool versus alternatives, but the name and phrasing imply it is for inspecting a specific command by ID. Sibling tool names provide context, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by detailing the specific data categories returned and the 'Manager-private' access level, but it does not disclose other behavioral aspects like rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core purpose and then lists the exact scope of returned data. Every listed item is informative and there is no fluff, though the sentence is long and could be slightly more structured with separators.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive annotations, the description adequately covers the tool's purpose, usage context, and data scope. The only notable gap is the lack of parameter clarification, but this is partially offset by the schema and the tool's straightforward nature.
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 description coverage is 50%, with only mailbox_name having a description. The tool description adds no information about either parameter, leaving mail_hosting_id entirely unexplained. The agent must rely on external context or other tools to understand that parameter, so the description does not compensate for the schema gap.
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 begins with 'Full mailbox detail' followed by a comprehensive enumeration of specific attributes (auto-responder, aliases, redirections, security flags, filters, etc.), making it unmistakably clear that this tool retrieves an exhaustive mailbox snapshot. The scope distinguishes it from narrower siblings like get_mailbox_info or get_mailbox_security, even though those alternatives are not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Useful for mailbox audits and onboarding flows', providing clear context for when to employ this tool. It also adds a 'Manager-private' access restriction. However, it does not mention alternative tools or when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is established. The description adds contextual framing (two modes) but no additional behavioral details such as pagination or response format. It is consistent with annotations, with no contradiction detected.
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 one well-structured sentence that conveys both modes without redundancy or filler. It is front-loaded with the primary verb and remains compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema reduces the need to describe return values. However, the tool has two distinct actions and 5 parameters, and the description does not clarify which parameters are required per action or what distinguishes 'mailbox' from 'service' scope. This leaves a moderate gap for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 hints at two modes (inspect a user vs. list inventories) but does not explain required parameters like mail_hosting_id, nor how user_id and mailbox_name relate to action. This leaves key parameter semantics undocumented.
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 a read-only purpose with specific verbs 'Inspect' and 'list', identifies the resource (mailbox device/session access, device inventories), and differentiates from the sibling management tool 'infomaniak_manage_mail_device_access' by emphasizing inspection and planning rather than modification.
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 usage context: 'for a selected mailbox user' and 'for cleanup planning'. It does not explicitly name alternative tools or when-not-to-use, but the context is sufficient for an agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the 'OpenAI-compatible v2 endpoint' context, which is useful, but it does not disclose other behavioral aspects such as response format or potential errors. With annotations present, this adds modest value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and scope. No redundant information, every word contributes.
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 low complexity (one parameter), strong annotations, and presence of an output schema, the description covers the essential purpose and scope. It could be enhanced by mentioning how to find the product_id or that this complements infomaniak_list_ai_models, but the current description is complete enough for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'one Infomaniak AI product' weakly maps to the product_id parameter, but it does not explain how to obtain or interpret the product_id, nor does it reference related tools. The parameter is simple, but the description provides minimal semantic enrichment.
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 models exposed by an Infomaniak AI product, using the specific verb 'List' and specifying the resource scope. It distinguishes itself from sibling tools like infomaniak_list_ai_products and infomaniak_list_ai_models by targeting models for a single product via its OpenAI-compatible v2 endpoint.
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 is for when you need models specific to one AI product, but it does not explicitly state when to use it versus alternatives, nor does it mention prerequisites like obtaining a product_id from infomaniak_list_ai_products. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, and idempotent behavior. The description adds the scope filter 'pending' which is useful context, but it does not detail return format, pagination, or edge cases beyond what annotations provide. With annotations covering safety, the description adds moderate value.
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, immediately states the action and object, and contains no redundant information. 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?
Given the tool's simplicity (one parameter, output schema present, read-only annotations), the description is sufficient. It clearly specifies the resource (pending user invitations) and purpose (access review), and the output schema can handle return details. It lacks only optional guidance on pagination or ordering, which are minor gaps for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter (drive_id as 'kDrive identifier'). The description does not add any parameter-specific semantics, 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 verb 'List' and the specific resource 'pending kDrive user invitations', with the added context 'for access review'. This distinguishes it from sibling tools like listing drive users or share links, which target different resources.
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 a use case ('for access review') but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. For example, it doesn't mention that list_drive_file_access_invitations is for file-level invitations, not user invitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description is not required to repeat those. It adds scoping context but does not describe pagination, output format, or any edge cases. Given the annotations, 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?
The description is two concise sentences, front-loaded with the action and resource, and includes a practical use case without any fluff. Every word earns its place.
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 output schema exists, so return values are covered, and annotations handle safety. However, the scope parameter's enum values are not fully explained (e.g., 'team_by_channels' is ambiguous). The description is adequate for a simple list tool but not comprehensive.
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 hints at the scope values (team, channel, user) but fails to explain the 'all' and 'team_by_channels' enum values or how the IDs relate to each scope. This is insufficient for a tool with 4 optional 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' and identifies the resource as 'kChat groups', clearly distinguishing it from sibling tools like list_kchat_channels (which lists channels) and list_kchat_roles. The scope (team, channel, or user) further clarifies 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?
It explicitly mentions a use case: 'useful for auditing permission-linked group sync.' This gives clear context for when to use the tool, though it does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about the contents (filters, scripts, templates) and the administrative auditing purpose, which goes beyond the annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, and front-loaded with the main verb. It avoids redundancy and every sentence contributes meaningful information without fluff.
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 read-only list tool with full schema coverage, annotations, and an output schema, the description adequately conveys purpose and scope. Minor gap: it does not clarify the relationship with the sibling 'list_mailbox_filter_scripts' tool, but overall completeness is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter already has descriptive text (e.g., mailbox_name clarifies local part only, mail_hosting_id references discovery via another tool). The description does not add additional parameter-level detail, so 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 tool lists Sieve filters, scripts, and available templates for a mailbox, and identifies it as a read-only admin inventory. It distinguishes from mutating filter tools but does not explicitly differentiate from the sibling tool infomaniak_list_mailbox_filter_scripts, which may cause ambiguity.
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 spam/filter policy auditing ('admin inventory'), which provides context. However, it does not explicitly state when to use this tool over alternatives like infomaniak_list_mailbox_filter_scripts, nor does it mention any exclusions or prerequisites beyond what the schema already provides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the global-or-project scoping behavior, which is useful but does not disclose additional details like pagination, result limits, or auth requirements. The added value is moderate, similar to the high-calibration example.
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 efficiently conveys the core function and scope without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list with two parameters), annotations, and an output schema, the description is mostly complete. It captures the essential global/project scope, though 'globally' is slightly ambiguous and could be clarified (e.g., 'across all projects in the public cloud'). Overall, it is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by implying that project_id filters 'within a project', but it does not explain public_cloud_id's role or provide explicit parameter-level semantics. The parameter names are somewhat self-explanatory, but the description does not fully bridge the gap left by 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 ('List') and resource ('Public Cloud DBaaS services'), and clarifies scope ('globally or within a project'). It clearly distinguishes this from the sibling 'get_public_cloud_database_service' which fetches a specific service, and from other list tools for different resource types.
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 contexts ('globally or within a project') and hints at the optional project_id parameter, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. It provides context but no explicit when-to-use/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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint, idempotentHint, and readOnlyHint=false, so the description needn't restate them. It adds 'Two-phase confirmation with a fresh partnership snapshot,' which reveals a non-obvious workflow. However, it does not explain what the two phases entail, whether a confirmation token is required, or what happens upon unassignment, leaving significant 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 concise: two sentences, front-loading the primary action and adding one relevant process note. No redundant information or filler is present.
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?
With 6 parameters, a two-phase workflow, and an output schema, the description is too terse. It hints at the confirmation process but doesn't specify the mechanics, payload usage, or the meaning of 'fresh partnership snapshot.' The annotations and output schema cover some aspects, but the tool's complexity demands more explanatory detail than provided.
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 for missing parameter documentation. It mentions 'B2B customer partnerships' (implying partnership_id) and 'action' is clear from the enum, but account_id, invitation_id, payload, and confirmation_token are unexplained. There is no guidance on constructing the payload or when confirmation_token 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's function: 'Assign or unassign B2B customer partnerships on an account invitation.' This specific verb+resource combination distinguishes it from sibling invitation management tools like manage_account_invitation_access or create_account_invitation. The added detail about two-phase confirmation further clarifies the intended operation.
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 for when to use this tool (managing B2B partnerships on an account invitation), and the action enum (assign/unassign) reinforces the scope. However, it does not explicitly name alternatives or exclusion conditions relative to similar invitation-related tools, so some inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructive and non-read-only. The description adds valuable context by mentioning 'two-phase confirmation with a current domain snapshot,' which informs the agent about the confirmation workflow and safety mechanism, going beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core functionality and a key behavioral detail without any redundant wording. It earns its place with high information density.
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 complexity of a five-parameter destructive tool, the description is somewhat thin. It mentions two-phase confirmation but does not explain when confirmation is required or how the snapshot feeds into the workflow. However, the presence of an output schema reduces the need to describe return values, and the description provides a reasonable starting point.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not explain the parameters beyond the operation itself. It does not clarify the roles of 'confirmation_token,' 'verify_ns_availability,' or the relationship between 'nameservers' and 'use_infomaniak_ns,' leaving the agent to infer semantics solely from parameter names.
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 and resource: updating a domain's nameservers or restoring Infomaniak nameservers. This distinguishes it from sibling DNS record management tools, which target individual records rather than the nameserver level.
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 nameserver-level changes but does not explicitly state when to use this tool versus alternatives like DNS record tools. No exclusions or alternative recommendations are provided, so the guidance is mostly implicit.
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?
Beyond annotations (readOnlyHint=false, etc.), the description discloses 'Two-phase confirmation with a fresh settings snapshot guard,' which is important mutation behavior. This tells the agent to expect a confirmation step and staleness protection. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by a critical behavioral caveat. 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 tool with an output schema and action enum, the description covers the purpose and a key behavioral detail. It might benefit from stating the need for a prior action to get the confirmation_token, but 'two-phase' hints at it. Overall sufficient for initial selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's mention of AI, share-link, office, and preferences maps to the action enum, and 'two-phase confirmation' implies the confirmation_token parameter. However, it doesn't explain the settings payload structure or how to obtain the token, and schema coverage is only 50%, so description partially compensates.
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 'Update kDrive AI, share-link, office, or preferences settings,' specifying the verb and resource categories. It distinguishes from read-only siblings like get_drive_settings but doesn't explicitly contrast with more specific update tools like update_drive_share_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for updating these settings types, but doesn't provide explicit when-to-use vs alternatives. Given sibling tools include specific update tools, an exclusion note would help, though the general context is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that every mutation requires two-phase confirmation, a behavioral trait not present in the annotations. This adds valuable context about the confirmation workflow, though it does not detail what the second phase entails beyond the confirmation_token parameter.
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 with zero filler. It front-loads the action list and immediately notes the two-phase confirmation, making it easy to scan and understand.
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 basic purpose and confirmation behavior but lacks details on action-specific parameter requirements and the expected payload structure. Given the complexity of a multi-action tool, this is a moderate gap, though the output schema and annotations provide some support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the schema. It does not explain which parameters are required for each action (e.g., bot_user_id for update/enable/disable/delete, payload for create). With 50% schema description coverage, the description fails to compensate for the remaining gaps.
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 (create, update, enable, disable, delete) with a clear resource (kChat bot), making it unambiguous what the tool does. It also distinguishes itself from sibling tools like list_kchat_bots and get_kchat_bot by focusing on mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for managing a kChat bot's lifecycle, but it does not explicitly state when to use this tool over alternatives such as getting or listing bots. There is no mention of prerequisites or exclusions, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations by disclosing that all changes use two-phase confirmation and a fresh filter snapshot. This warns the agent about the need for a confirmation token and concurrency handling, which the annotations alone do not convey. No contradiction with readOnlyHint=false or idempotentHint=true is apparent.
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, immediately states the core actions, and adds a concise, high-value note about two-phase confirmation. No filler or redundant terms; it is appropriately front-loaded and efficient.
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's multi-action nature and two-phase confirmation workflow, one sentence is slightly under-specified. The description does not explain the confirmation flow steps (e.g., first call returns a token, second call applies), leaving the agent to infer details from the schema. However, the presence of an output schema and the descriptive action names mitigate some ambiguity.
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, but it only hints at parameters through phrases like 'reorder' (implying order) and 'two-phase confirmation' (implying confirmation_token). It does not explain critical parameters like is_enabled, filter_name, order, or how confirmation_token is obtained and consumed.
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 combination: 'Enable/disable mailbox filters or Sieve scripts, or reorder filters.' It clearly identifies the tool's scope and distinguishes it from create/update/delete siblings by focusing on lifecycle state changes and ordering.
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 naming the exact operations (enable/disable/reorder) and the two-phase confirmation requirement, but it does not explicitly say when to prefer this tool over alternatives like update_mailbox_filter or upsert_mailbox_filter_script. No exclusion or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the two-phase commit behavior: 'returns a plan first, then applies the undo on the second call'. This goes beyond the annotations, which only indicate destructive and non-idempotent behavior. It also notes the 'when reversible' limitation. However, it does not explain the content of the plan or the need for a confirmation token, leaving some 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, with the primary purpose stated immediately. Every word earns its place: it names the action, scope, and key behavioral caveat. There is no fluff or redundant restatement of the tool name or annotations.
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 explains the core two-phase mechanism but omits important operational details, such as how to obtain a history_id (e.g., via infomaniak_history) and what the plan contains. Given the tool's destructive nature and the presence of an output schema, a bit more guidance would make it fully self-sufficient. Still, it provides adequate high-level context for a capable agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate. While 'history_id' and 'confirmation_token' are inherently suggestive, the description fails to explain their roles, especially that history_id identifies the action to undo and confirmation_token is presumably obtained from the first-phase plan. The two-phase mention hints at the token but does not explicitly define 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 clearly states the tool's function: 'Reverse a destructive action recorded in the session history'. The verb 'Reverse' is specific, the resource is a destructive action, and the scope is limited to session history and reversibility. This distinguishes it from sibling tools like infomaniak_history or direct delete 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 when to use the tool: after a destructive action, when it's recorded in session history and reversible. However, it does not explicitly mention alternatives (like restoring from trash) or exclusions (e.g., non-reversible actions). The 'when reversible' qualifier provides some guidance but not a full usage policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the behavioral trait of a 'two-phase commit with a fresh tag snapshot guard,' which goes beyond the annotations by indicating a concurrency control mechanism. However, the exact semantics of this guard are not fully explained.
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 tool's purpose, and contains no filler. The second sentence adds unique context without unnecessary 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?
Complexity is moderate (nested payload, optional confirmation_token, destructive operation). The description does not clarify the two-phase commit workflow or how to obtain a 'fresh tag snapshot guard,' leaving critical operational details unexplained. Although an output schema exists, the description is insufficient for an agent to confidently use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with account_id, tag_id, and payload described in the schema. The description itself adds no parameter-specific meaning, only referencing the 'tag snapshot guard' which is not explicitly tied to confirmation_token. Baseline 3 is appropriate where 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 action: 'Update an account tag.' This distinguishes it from sibling tools like create_account_tag and delete_account_tag. The verb 'update' plus resource 'account tag' 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The 'two-phase commit' phrase implies this is for updates requiring concurrency protection, but it does not name alternatives or state exclusions. Usage is implied 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?
Beyond the annotations, the description discloses a two-phase commit process and a current-settings guard, providing insight into execution semantics and safety behavior not captured by readOnlyHint/destructiveHint. It adds meaningful context about how the operation is validated.
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 fluff. It conveys the main action, endpoint, and a key behavioral nuance, earning every word.
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's core two-phase commit workflow is only mentioned cryptically, leaving unclear how to initiate the first phase, obtain a confirmation_token, or what the 'current settings guard' entails. This is a significant gap for a tool with nested settings and a confirmation step, despite annotations and an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes drive_id and settings, but confirmation_token lacks a description. The description's mention of two-phase commit hints at the token's purpose, adding some meaning. However, it does not elaborate on the settings payload structure or how to obtain the token.
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 ('Update') and resource ('kDrive trash settings') with a precise API endpoint, clearly distinguishing it from sibling tools that empty trash or manage individual trash items. The two-phase commit mention further clarifies its unique role.
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 updating trash settings via a specific endpoint, but does not explicitly state when to use this over alternatives like empty_drive_trash or manage_drive_settings. The two-phase commit hint suggests a workflow, but prerequisites or exclusions are not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description adds meaningful behavioral detail by mentioning "Two-phase commit with a fresh team-members snapshot guard." This discloses non-obvious transactional behavior that annotations do not cover, enhancing the agent's understanding of side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the primary action. Every word contributes meaning, and the second sentence adds critical behavioral context without verbose explanation.
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?
Despite the tool's complexity (two-phase commit, snapshot guard, confirmation_token parameter, output schema), the description is minimal. It does not explain the mechanics of the two-phase commit, when confirmation_token is required, or what the snapshot guard entails. While the output schema exists, the behavioral complexity warrants more detail than what is provided. The description is adequate but leaves significant 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 provides descriptions for three of the four parameters (account_id, team_id, payload), and the description adds little beyond that. The payload is described generically as "Request body accepted by the corresponding Infomaniak endpoint," with no further clarification in the description. Since schema coverage is 75%, the baseline is 3, and the description does not elevate 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 clearly states the action: "Add one or more users to an account team." This is a specific verb and resource, distinguishing it from sibling tools like infomaniak_remove_account_team_users. The additional "Two-phase commit with a fresh team-members snapshot guard" further clarifies the tool's specific behavior.
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 usage context is implied by the description: use when you need to add users to an account team. However, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. It does not name alternative tools or conditions when this should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a two-phase commit mechanism and a fresh snapshot guard, which are non-obvious behaviors not captured by annotations. It also notes the payload is passed through as-is. Annotations already indicate non-read-only and destructive hints, and the description adds extra operational 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?
Two tightly packed sentences: the first states the action, the second adds the critical behavioral nuances. No filler or repetition of schema fields.
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 create tool with a two-phase commit guard and an optional confirmation token, the description gives a high-level frame but omits how the token is used in the two-phase flow. Since an output schema exists, return value details are unnecessary, but the confirmation_token role is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that the payload is passed through to Infomaniak as-is, adding meaning beyond the schema's generic 'request body' description. However, the confirmation_token parameter remains undocumented in both the schema and description, and with 67% schema coverage, there's room for more parameter guidance.
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 clear verb+resource statement ('Create an account team'), distinguishing it from sibling update/delete/add/remove operations. It also adds a distinctive detail (two-phase commit) that further characterizes this specific create variant.
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 context is implied by the 'create' verb and the tool's name, but the description does not explicitly state when to use this versus update/delete/add-user operations. The two-phase commit note hints at a special process, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and openWorldHint=true. The description adds 'Two-phase commit with current file-access guard,' which discloses that the operation involves a confirmation step and has safeguards. This is useful behavioral context beyond the annotation fields.
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 purpose and no redundant or filler content. Every word earns its place.
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?
Despite having an output schema and annotations, the two-phase commit behavior is a significant operational detail left underspecified. An agent cannot fully understand the call flow (e.g., whether a token is returned, how to finalize) from the description alone. This is a meaningful gap for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so baseline is 3. The description's mention of 'two-phase commit' hints at the purpose of confirmation_token (which has no schema description), but it doesn't explicitly explain the payload structure or how the token is used. It adds marginal value 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 a specific action ('Grant a team access') on a specific resource ('kDrive file or folder'), which distinguishes it from sibling tools like create_drive_file_access_user or remove_drive_file_access_team. The verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The two-phase commit hint implies a process but doesn't explain when to prefer this over update_drive_file_access_team or user-specific access tools. Context is minimal and inferred from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations by mentioning a two-phase commit and snapshot guard, which alerts the agent to potential side effects or prerequisites. The annotations already indicate destructive and non-read-only behavior, so the description supplements rather than contradicts them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, two short sentences, and front-loads the primary purpose. Every word adds value, with no filler or repetition of schema 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?
The description is adequate for a delete operation, especially with an output schema present and annotations covering safety. However, it does not explain the optional confirmation_token or provide context on when a two-phase commit applies, leaving some gaps 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 covers two of three parameters with descriptions, and the description does not explicitly explain the confirmation_token parameter. However, the 'two-phase commit' hint indirectly suggests the token's role, though not clearly. This is a moderate compensation for the 67% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete an account invitation') with a specific verb and resource, distinguishing it from sibling tools like create or update invitation. The additional technical detail about two-phase commit does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives such as cancel_user_pending_invitations or manage_account_invitation_access. No when-not or specific alternative is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds value by noting the asynchronous nature and the read/download modes, which inform the agent about two distinct retrieval behaviors. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with clear front-loading of the action and resource. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 3-parameter schema and presence of an output schema, the description captures the core purpose effectively. It mentions asynchronous behavior, which is key, but could elaborate on batch completion requirements or the difference between read and download. Still sufficient for a read-only tool.
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 adds meaning to the 'download' boolean ('Read or download') but leaves product_id and batch_id undefined beyond their names. This only partially addresses parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Read or download') and resource ('result of an asynchronous Infomaniak AI model batch'). It distinguishes itself from sibling list tools (e.g., list_ai_products, list_ai_models) by targeting the batch result specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving AI batch results but does not explicitly mention when to use this tool versus alternatives or provide exclusions. The asynchronous aspect hints at polling, but no concrete guidance is 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context by listing what 'full detail' includes (disk usage, application, permissions, backups), giving the agent a concrete sense of the returned information. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a parenthetical that adds value without clutter. Every word contributes to purpose and expected return content.
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 read-only get operation with a clear output schema and strong annotations, the description is mostly sufficient. It could be slightly richer by referencing sibling tools or clarifying prerequisites, but the available schema and annotations fill most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with hosting_id lacking any description and database_name getting a helpful description. The tool description does not add meaning for either parameter beyond calling the target 'a specific database', so it fails to compensate for the missing hosting_id semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get') and a clear resource ('full detail of a specific database'), adding concrete detail categories in parentheses. It clearly distinguishes itself from sibling tools like infomaniak_list_databases and infomaniak_get_database_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for one specific database rather than a list, but it does not explicitly state when to use it versus alternatives such as infomaniak_list_databases. The schema's reference to infomaniak_list_databases provides some context, but the description itself offers no direct exclusions or alternative 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?
Annotations already provide destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds valuable context with 'Two-phase commit with audit/current-state guard', explaining that the tool checks current state and likely uses a confirmation step. This goes beyond the raw annotations, though it stops short of fully detailing the audit guard's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first quickly lists concrete actions, the second adds the critical two-phase commit behavior. No filler or redundant repetition of schema/annotation info.
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 communicates purpose and key behavioral traits, but doesn't explain how the two-phase commit interacts with the confirmation_token parameter, leaving ambiguity about whether changes auto-apply or require explicit confirmation. Given 7 parameters and an output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so most parameters are already well-documented in the schema. The description's mention of 'optionally set filtering folders' maps to the folder parameters but adds no new semantic nuance beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: 'Plan and apply conservative mailbox security hardening' with specific sub-actions (enable spam movement, enable mail filtering, optionally set filtering folders). This distinguishes it from read-only siblings like infomaniak_get_mailbox_security and single-purpose setters like infomaniak_set_mailbox_spam_policy.
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 security hardening scenarios but does not explicitly state when to prefer this tool over alternatives like infomaniak_set_mailbox_spam_policy or infomaniak_update_mailbox_folders. It gives a context ('conservative hardening') but lacks explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the specific scope ('every mailbox on a given mail hosting') which is useful behavioral context. No contradictions; no additional limitations or side effects are mentioned but none are necessary 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 a single clear sentence that is front-loaded and free of filler. It conveys all necessary information in the most concise way possible.
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 is very simple with one parameter and an output schema that likely defines mailbox structure. The description is sufficient for a straightforward list operation, though it could have mentioned that the mail_hosting_id comes from list_mail_hostings. However, given the output schema and annotations, this is a minor gap.
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% for the only parameter (mail_hosting_id). The description only says 'given mail hosting,' which vaguely refers to the parameter but does not explain what the ID is, how to find it, or its format. With zero schema descriptions, this is insufficient compensation.
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') with a clear resource ('every mailbox') and a scope ('on a given mail hosting'). It clearly distinguishes from sibling tools like list_mail_hostings (which lists hostings) and get_mailbox_info (which gets a single mailbox).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you have a mail hosting and need all mailboxes, but it does not explicitly state when to use it vs alternatives or any exclusions. It lacks the explicit alternative naming seen in high-quality examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the 'every' completeness qualifier and the organizational scope but does not disclose additional behavioral details such as pagination, rate limits, or required permissions. It is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence of 13 words, front-loaded with the verb and resource, with no filler or redundant content.
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 listing tool with an output schema, full annotation coverage, and a single well-documented optional parameter, the description provides sufficient context. No return value explanation is needed given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter account_id is fully described in the schema (including default behavior), and the description does not introduce any new parameter semantics. With 100% schema coverage, 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 the specific verb 'List', identifies the resource as 'mail hosting (a.k.a. email_hosting)', and scopes it to 'attached to an Infomaniak organization', clearly distinguishing it from sibling tools like list_mailboxes or list_hostings.
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 enumerating mail hostings within an organization but does not explicitly state when to prefer this over related tools such as get_mail_hosting_full or list_mailboxes, nor does it mention exclusions. The context is present but lacks explicit alternative 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety and variability profile is clear. The description adds no extra behavioral context (e.g., return format or auth requirements), but it does not contradict annotations or mislead. Given the low bar for annotated tools, this is minimally 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?
The description is a single, concise sentence that immediately states the action and resource. It contains no fluff or repetition, 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?
For a zero-parameter read-only list operation with output schema and rich annotations, the description is complete. It clearly identifies the resource and action; the output schema explains return values, and annotations cover safety and variability. No further detail is needed.
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 does not need to explain any parameters, and the input schema fully covers the empty parameter set. There is no gap for the description to compensate for.
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' and names a distinct resource ('Public Cloud account accesses'), which clearly differentiates it from sibling tools that list other Public Cloud resources (e.g., database services, Kubernetes services, projects). It unequivocally states 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 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, no prerequisites, and no exclusions. The only implied usage is that it lists accesses, but there is no comparative or contextual advice for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds the scoping behavior ('belonging to a Swiss Backup subscription') but does not disclose other behavioral traits like pagination, ordering, or whether all slots are returned regardless of status. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundancy or filler. Every word earns its place.
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?
The tool is simple: one required parameter, output schema available, and annotations covering safety. The description fully states the operation and scope. No critical information is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero description coverage, leaving the description to compensate. The description clarifies that slots are tied to a Swiss Backup subscription, which helps infer that swiss_backup_id identifies the subscription. However, it does not explicitly map the parameter to the subscription ID or explain constraints like exclusiveMinimum. The parameter name is self-explanatory but the description could do more.
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 ('backup slots') with clear scope ('belonging to a Swiss Backup subscription'). It distinguishes from sibling tools like get_swiss_backup_slot (singular) and manage_swiss_backup_slot (mutating).
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 (when you need to list slots for a subscription) but provides no explicit guidance on when to prefer this over alternatives, such as get_swiss_backup_slot for a single slot or manage_swiss_backup_slot for modifications. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive/non-readonly behavior, and the description adds a valuable, non-obvious behavioral trait: 'Two-phase confirmation for all writes.' This reveals that writes require a confirmation step, providing context beyond the flags. No contradiction with annotations; destructiveHint=true aligns with the described write operations.
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 dense with information: the first lists the full action scope, the second reveals a critical behavioral aspect. No filler or redundancy; it is front-loaded with the primary verb list, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (5 parameters, nested payload, many actions), and while an output schema exists, the description omits crucial details about the two-phase confirmation flow—such as how confirmation_token is obtained or used. It adequately states the tool's scope but leaves the agent to infer per-action parameter requirements, which is a notable gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The action enum in the schema already lists the same actions the description mentions, so the description adds marginal value for parameter meaning. However, the 'two-phase confirmation' hint clarifies that confirmation_token is relevant for write actions, which is not fully explicit in the schema. The payload/team_id/channel_id relationships are left unexplained, so with 60% schema coverage, the description only partially compensates.
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 enumerates a specific resource (kChat channel) with a comprehensive list of verbs (create, update, patch, move, restore, delete, change privacy/scheme/moderation), making it clear this is the channel-level management tool. It distinguishes itself from sibling tools like manage_kchat_channel_members and manage_kchat_command by explicitly covering channel operations rather than member or command management.
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 listing the supported actions, giving the agent a clear sense of when to invoke this tool (e.g., when creating or deleting a channel). However, it does not explicitly state when not to use it or mention alternatives such as manage_kchat_channel_members for member operations, so usage guidance remains 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?
The description discloses that mutations use a two-phase confirmation, which is a behavioral trait not captured by annotations. Given annotations already indicate destructive potential, this adds useful context about the confirmation token requirement. It does not detail all side effects, but the output schema covers return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the actions and a key behavioral trait. No unnecessary words or repetition, making it 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?
For a multi-action tool with an output schema and annotations, the description covers the core CRUD-like operations and highlights the confirmation workflow. It does not elaborate on per-action nuances, but the schema and action enum fill in the remaining details, making it reasonably 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?
The description adds no parameter-level explanation. With schema coverage at 50%, several parameters (action, model_id, confirmation_token, payload) remain undocumented, and the description does not compensate for this gap. The only schema hints are for mail_hosting_id and mailbox_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 clearly identifies the tool's purpose: managing mailbox auto-reply models with list, create, update, delete, and reset actions. It specifies the resource (mailbox auto-reply models) and differentiates itself from sibling tools by covering both reading and mutating operations.
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 by the tool name and action list, but there is no explicit guidance on when to choose this tool over alternatives like infomaniak_list_service_auto_replies. The mention of two-phase confirmation gives some context for mutations but not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior, and the description's 'Delete' and 'revoke' align. The added 'Uses two-phase confirmation and current-state guards' provides valuable context beyond annotations, informing the agent that a confirmation token is required and that operations may fail if state changed.
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-loading the primary action and adding a key behavioral note. No redundant or filler text; every sentence earns its place.
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 7 parameters, a destructive annotation, and an output schema, the description is reasonably complete at a high level but lacks operational details such as the two-phase confirmation flow, parameter dependencies for each action, and error conditions. The output schema likely covers return values, but the description doesn't fully guide an agent through the tool's 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?
With 0% schema description coverage, the description is the only source for parameter semantics. It explains the two action modes and the mailbox/service scope, but does not clarify when `user_id` vs `mailbox_name` is required or the format/meaning of `device_access`. Thus it only partially compensates for the schema's lack of descriptions.
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 ('Delete', 'revoke') and a clear resource ('device access', 'device sessions'). It distinguishes two operation modes, making its purpose unambiguous and differentiating it from the sibling read tool `get_mail_device_access`.
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 clearly implies destructive management of device access, and the 'two-phase confirmation' note adds usage context. However, it does not explicitly name alternatives or state when not to use it, such as pointing to `get_mail_device_access` for read-only viewing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the important behavioral trait of 'two-phase confirmation,' which is not captured in annotations. Annotations already indicate destructive behavior and non-read-only, and the description does not contradict them. However, it does not detail how the two-phase flow works or mention side effects beyond what annotations imply.
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 lists all supported actions and the key confirmation behavior. Every word earns its place, with no wasted content. It is appropriately sized for a tool with a complex schema that the description cannot fully cover.
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?
Despite having an output schema, the tool has 5 parameters at 0% schema coverage, nested objects, and a destructive nature. The description only covers high-level purpose and two-phase confirmation, omitting crucial details about payload structure, when confirmation_token is required, and the role of slot_id. This is insufficient for accurate invocation for all actions.
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 carries the burden of explaining parameters. It does not explain payload, slot_id, confirmation_token, or how they relate to each action. The action enum is self-explanatory, but the remaining parameters are opaque, leaving agents without enough guidance for correct invocation.
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 lists the specific actions (create, update, delete, enable, disable) applied to a Swiss Backup slot, making the tool's purpose unambiguous. It distinguishes this tool from siblings like list_swiss_backup_slots and get_swiss_backup_slot by focusing on mutation operations.
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 usage context: use this tool when you need to create, update, delete, enable, or disable a slot. It does not explicitly state when not to use it or name alternatives, but the verb list and resource make the intended use clear. Sibling names support 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's 'Returns a summary' is consistent and adds little. It does add context about scope ('all organizations and products you have access to'), but it does not disclose potential latency, pagination, or other behavioral nuances. With strong annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: it states the core function and a usage recommendation. It is front-loaded and every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is an overview with a simple interface, good annotations (read-only, idempotent), and an output schema, so the description need not detail return values. However, the lack of any explanation for the optional 'account_id' parameter is a noticeable gap, preventing a perfect score. Overall, it is reasonably complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'account_id' with no description in the schema (0% coverage). The description entirely omits this parameter, leaving the agent to guess whether passing an account_id filters the summary or is otherwise relevant. Since schema coverage is low, the description should compensate, but it 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 clearly states the tool 'Returns a summary of all Infomaniak organizations and products you have access to,' specifying both the verb ('Returns') and the resource ('summary of all organizations and products'). This distinguishes it from sibling tools like 'infomaniak_list_organizations' which likely only list organizations, and the added 'Best called first in a session' reinforces its role as a high-level overview.
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 'Best called first in a session' provides clear contextual guidance on when to use this tool as a starting point. It does not explicitly list alternatives or exclusions, but the 'first in a session' recommendation implies it should precede more specific tools, which is useful direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive behavior and non-idempotency. The description adds valuable context with 'Two-phase commit with a fresh team-members snapshot guard,' which goes beyond annotations and hints at a confirmation step and concurrency guard. However, it does not elaborate on the exact mechanics or failure modes, so it is not a full disclosure.
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, consisting of two short sentences. It is front-loaded with the primary purpose and includes a necessary behavioral note. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with confirmation and a snapshot guard, the description is somewhat cryptic. It does not explain the two-phase commit flow, what the snapshot guard protects against, or how confirmation_token should be obtained. While annotations and output schema offset some gaps, the description leaves important operational details unexplained, making it minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (three of four parameters have descriptions). The description does not explicitly explain parameters, but the two-phase commit hint relates to the confirmation_token. Since the schema already covers most parameters, the description adds only marginal semantic value, aligning with the baseline of 3.
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: 'Remove one or more users from an account team.' This uses a specific verb ('Remove') and identifies the resource ('account team'), and it inherently distinguishes from sibling tools like add/update/delete account team users.
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 (when you need to remove users), but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternatives such as the sibling 'infomaniak_add_account_team_users' or other team management tools. It is sufficient to understand the basic context but lacks exclusionary or alternative 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so a safe listing operation is understood. The description adds that it catalogs by category/risk/capability and frames it as a pre-workflow discovery tool, but doesn't disclose details like default limits or return structure beyond that. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core listing action, then a practical usage note. 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 filtered catalog tool with output schema and read-only annotations, the description provides a clear high-level purpose and usage context. The low schema coverage for parameters is a minor gap, but the tool is self-descriptive as a tool catalog, so completeness is 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?
Schema description coverage is only 20% (only 'category' has a description). The description mentions 'by admin category, risk, and capability,' which implicitly maps to category/scope/risk filters, but it does not explain the 'limit' or 'include_descriptions' parameters, nor the enum semantics. The description doesn't compensate enough for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource ('the MCP's Infomaniak tools') and specifies the organizing dimensions (admin category, risk, capability). It distinguishes itself from sibling tools by focusing on the tool catalog itself rather than a specific resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'Best for asking what can this MCP do? before choosing a specific workflow,' which conveys when to use it as a discovery/overview tool. It doesn't explicitly name alternative tools or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool destructive and not read-only, so safety is known. The description goes beyond annotations by revealing a two-phase commit with a 'current filter inventory guard before PATCH,' which is a non-obvious behavioral detail that helps the agent understand the update workflow. This adds value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, then adds a valuable behavioral detail (two-phase commit). There is no fluff or redundancy, and it reads well for an agent scanning quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive 8-parameter tool, the description is sparse. The output schema and annotations cover some risk and return types, but the 'inventory guard' and confirmation-token workflow are left vague. It is minimally adequate but not fully complete for an agent to understand the entire update procedure.
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 88%, with clear descriptions for most parameters (e.g., mailbox_name explicitly says it's the local part, not the full email). The description itself adds no parameter-level meaning beyond the schema; the 'two-phase commit' phrase only indirectly relates to confirmation_token. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update or rename a mailbox Sieve filter,' using a specific verb plus resource that clearly states the operation. It also distinguishes this from sibling tools like create_mailbox_filter and delete_mailbox_filter by explicitly including rename, and the mention of 'PATCH' reinforces the update nature.
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 name and verb imply this tool is for modifying existing filters, and the presence of old_name clarifies that it updates a specific filter. However, there is no explicit guidance on when to use this versus create/delete/upsert siblings, nor any exclusions, so usage context is only implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent ('Fetch', 'report'). It adds useful context about what the report contains (admin candidates, risky writes, intentionally out-of-scope surfaces), but does not cover rate limits or error behavior. With annotations present, the bar is lower and the added detail earns a 4.
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 entire description is one efficient sentence front-loaded with the action and resource, followed by the report's specific outputs. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a clear purpose, fully described parameters, annotations, and an output schema, so the description doesn't need to explain return values. It covers the essential behavioral scope, though it could have included an explicit use case or contrast with sibling coverage tools for perfect completeness.
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?
Both parameters (limit and docs_url) have complete schema descriptions including defaults and constraints, so schema coverage is 100%. The description does not add any parameter-level meaning beyond that, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch... and report') and specific resource ('Infomaniak developer portal navigation'), plus the exact categories of output (MCP endpoint coverage, admin candidates, risky writes, out-of-scope surfaces). This distinguishes it from sibling tools like infomaniak_overview or infomaniak_api_call.
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 is for generating a coverage/audit report, but it does not explicitly state when to use it or mention alternatives such as infomaniak_tool_catalog or infomaniak_overview. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds the two-phase commit and inventory guard context, explaining that deletion is guarded. This provides value beyond the boolean hints, though it does not detail side effects or permissions.
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, front-loaded with the action, no filler. The second sentence adds critical safety context without verbosity.
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 destructive tool with an output schema and good annotations, the description covers the object, action, and a safety mechanism. It does not elaborate on prerequisites, but the inventory guard implies them. Sufficient for an agent to select and invoke.
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 75% of parameters with useful specifics (e.g., mailbox_name format, mail_hosting_id discovery). The tool description itself adds little parameter meaning beyond referring to 'by name', so it relies on schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a mailbox Sieve script by name', specifying the exact action and resource. It distinguishes from related tools by using 'Sieve script' and mentioning the two-phase commit guard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for deleting Sieve scripts but does not explicitly contrast with alternatives like infomaniak_delete_mailbox_filter or provide exclusions. The safety mechanism hints at a specific use case but lacks explicit 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?
The description adds the critical behavioral trait 'Two-phase commit' beyond what annotations provide. Annotations already indicate destructive and idempotent hints, so the bar is lower, but the two-phase process is essential context not present in annotations. This helps the agent understand the tool requires an extra confirmation step.
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 exactly two sentences with no filler. It front-loads the purpose ('Delete a mail redirection') and immediately follows with the essential two-phase commit caveat. Every word earns its place; 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 simplicity and the rich schema (all parameters explained, output schema present), the description is adequate. It captures the core purpose and the unique two-phase behavior. The schema fills in the remaining details about token handling and discovery steps, making the definition complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level detail; it does not mention mail_hosting_id, name, or confirmation_token. The schema descriptions are comprehensive, so the definition remains clear, but the description provides no extra semantic value for 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 the action ('Delete a mail redirection') with a specific verb and resource. It distinguishes itself from sibling tools like infomaniak_create_redirection or infomaniak_manage_service_redirections by naming the delete operation and adding the 'Two-phase commit' note, which uniquely identifies this tool's behavior.
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 (when you want to delete a mail redirection) but does not explicitly state when to use versus alternatives or exclude other tools. The schema provides some guidance via parameter descriptions (e.g., 'List existing rules with infomaniak_list_redirections'), but the description itself lacks direct usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag the tool as destructive, but the description adds valuable behavioral details: 'Two-phase commit' and the post-condition that the Apache vhost will no longer respond. It also states the main FQDN exclusion. This goes beyond the bare destructive flag.
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?
Three concise sentences, front-loaded with the primary purpose. Every sentence adds distinct information: action, exclusion, commit behavior, consequence, and access level. No 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?
The description covers the main effect and constraint, and an output schema exists to describe returns. However, 'Two-phase commit' is mentioned but not explained, and there is no mention of the confirmation_token parameter or that list_site_aliases should be used first. This leaves gaps for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only alias has a description). The description reiterates the alias constraint but does not clarify hosting_id, site_id, or confirmation_token. With low schema coverage, the description should compensate, but it does not explain the remaining 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 states a specific action: 'Remove one alias FQDN from a web hosting site', which clearly identifies the verb and resource. It also distinguishes itself from siblings by noting the main FQDN cannot be removed, differentiating it from list/add alias tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for removing an alias from a hosting site, explicitly excludes the main FQDN, and notes the operation is 'Manager-private'. It does not explicitly name sibling tools as alternatives, but the scope is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive behavior, so the description needs less. It adds valuable context with the 'Manager-private' access restriction and clarifies the support tier value (premium=2). Enumerating the returned fields also enhances transparency beyond what annotations offer.
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, information-dense sentence that front-loads the purpose with 'Full organization detail.' Every listed field is relevant, and there is no redundant wording 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 read-only getter with one parameter, existing output schema, and rich annotations, the description sufficiently covers the tool's function and data scope. Minor gaps like explicit usage alternatives and return-format details are acceptable because the output schema handles format and the sibling list implies scope.
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 complete description for account_id, including how to discover it (via infomaniak_list_organizations), achieving 100% schema description coverage. The tool description adds no parameter-specific information, but that is unnecessary given the schema's thoroughness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'Full organization detail' and enumerates specific data fields (legal entity, billing addresses, VAT, locale, timezone, etc.). It unambiguously identifies the resource as the account/organization and distinguishes itself from sibling tools targeting other resources (domains, drives, VPS).
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 is the comprehensive org-detail tool via 'Full organization detail,' but does not explicitly state when to use it over alternatives like infomaniak_list_organizations or infomaniak_get_account_resources. No exclusions or alternative recommendations are provided, making usage guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent hints. The description adds the nuance of a 'snapshot' (implying a point-in-time view rather than a live query) and enumerates the specific settings areas covered. This contextual information goes beyond the annotations, providing useful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb and resource clearly. It contains no redundant words or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, clear annotations, and an output schema), the description covers the purpose and scope sufficiently. The only minor gap is the lack of explicit usage tie-ins to related drive management tools, but the overall context 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 describes drive_id and points to infomaniak_list_drives for discovery, giving 100% schema coverage. The description does not add additional meaning to the parameter itself, so it reads at the baseline expected when the schema covers the parameter 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 uses the specific verb 'Read' and identifies the resource as 'kDrive policy settings snapshot' with clear subcategories (AI, share links, office, preferences). This distinguishes it from sibling tools like infomaniak_manage_drive_settings (write) and infomaniak_get_drive_full (broader resource).
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 when one needs to inspect current policy settings, but it does not explicitly state when to prefer this over alternatives like infomaniak_get_drive_full or how it relates to infomaniak_manage_drive_settings. The schema hints at discovering drive_id via infomaniak_list_drives, but that is a parameter prerequisite, not usage 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's 'Read-only' adds no new safety info. It does add that the tool lists links 'visible to the account', which clarifies scope, but it does not disclose behaviors like pagination or whether results are limited to the drive specified by drive_id. Moderate value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A two-sentence description that is front-loaded with the verb and resource. Every word is purposeful: 'all', 'visible', 'account', 'admin exposure review', and 'Read-only'. 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 list operation with one well-documented parameter, an output schema, and safety annotations, the description is nearly complete. It could explicitly mention that results are scoped to the given drive_id or note pagination, but these gaps are minor relative to the overall clarity.
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 documents drive_id (100% coverage) with a clear description ('kDrive id. Discover via infomaniak_list_drives.'). The description adds no additional parameter semantics, 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 action ('List'), the resource ('all kDrive share links'), and the scope ('visible to the account'). It also gives a specific use case ('admin exposure review'), which distinguishes it from sibling tools like get_drive_share_link (singular) and create/update/remove.
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 'for admin exposure review' provides clear context for when this tool should be used (security/audit enumeration). It stops short of explicitly naming alternatives or stating when not to use it, but the listing vs. management distinction is apparent from sibling names and the singular/pural difference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds the behavioral nuance that passing user_id returns a specific member snapshot, which is beyond what annotations provide. However, it does not discuss pagination or empty results, though the output schema likely covers return format.
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 action and resource, then adds the optional behavior. No filler or redundant information, 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?
The tool is simple, and the annotations plus output schema provide substantial context. The description explains the core operation and the optional parameter behavior, which is sufficient for a basic list command. However, it could be more complete by explicitly noting the read-only nature or contrasting with the manage-members sibling, though these are inferable.
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 completely (channel_id and user_id) with 100% coverage. The description only paraphrases the optional user_id behavior ('optionally including one specific member snapshot') and adds no new meaning beyond the schema. Baseline 3 applies because schema coverage is high.
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' and clearly identifies the resource as 'members of a kChat channel', which distinguishes it from sibling tools like 'manage_kchat_channel_members' (which modifies) and 'list_kchat_channels' (which lists channels). The optional member snapshot feature adds further specificity.
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 stating the action, but it does not explicitly say when to use this tool over alternatives or provide exclusions. There is no mention of 'for read-only member listing' or 'use manage_kchat_channel_members to modify members', which would be helpful given the many kChat sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint, openWorldHint, and idempotentHint. The description adds a behavioral nuance: it can list for a team or the account, implying the optional team_id parameter affects scope. However, it does not explain pagination, sorting, or what exactly is returned, though the output schema helps. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately states the action and scope. No wasted words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, an output schema, and strong annotations, the description is sufficient. It covers the core action and the parameter's role. It could mention what the list contains (e.g., names, descriptions) but the output schema likely handles that. Overall, complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (team_id has a description). The description's 'for a team or the account' clarifies the meaning of the optional team_id parameter, reinforcing the schema. The baseline is 3 because the schema already provides the parameter meaning, and the description adds modest context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'kChat slash commands', and specifies the scope ('for a team or the account'). This distinguishes it from siblings like infomaniak_get_kchat_command (which retrieves a single command) and infomaniak_manage_kchat_command (which modifies commands).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: to list commands, optionally filtered by team. It clearly indicates the scope (team or account) but does not explicitly mention alternatives or exclusions. Given the sibling tools, it would be stronger to say 'Use this to see all commands; for a specific command use get_kchat_command', but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds content scope but no additional behavioral details such as pagination, response format, or rate limits. This is acceptable given the annotations and output schema, but no extra transparency is provided beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clean, front-loaded sentence that states the action, target, and examples. No filler or redundant information; 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?
The tool is simple with one enum parameter, an output schema is present, and annotations cover safety. The description is sufficient to understand the tool's purpose and content scope. It could be slightly more explicit about the role of the 'resource' parameter, but the enum and examples leave little ambiguity.
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 'resource' parameter is well-defined by its enum in the schema, but schema description coverage is 0%. The description partially compensates by listing example values (regions, packs, types, Kubernetes versions), though it does not explicitly map these to the parameter or mention all enum values. More explicit guidance could improve semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'Public Cloud configuration and service catalog data' with concrete examples (regions, packs, types, Kubernetes versions). This distinguishes it from sibling tools that list actual projects, services, or resources.
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 for when to use this tool: when needing configuration or service catalog data. It does not explicitly name alternatives or exclusions, but the focus on catalog/config versus actual resources (as seen in sibling tool names) gives implicit 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds 'service-level' scope but does not disclose pagination, filtering, or response structure. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no unnecessary words. The key information is front-loaded: 'List service-level auto-reply configurations'.
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 is simple with one parameter, and annotations plus an output schema provide additional context. The description adequately covers the purpose, though it could explicitly mention that it returns multiple configurations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but there is only one parameter (mail_hosting_id) whose purpose is inferable from the description ('for a mail hosting'). However, the description does not explicitly map the parameter, so it adds only partial meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (service-level auto-reply configurations) with a scope (for a mail hosting). It distinguishes from sibling tool 'infomaniak_manage_mailbox_auto_reply' by specifying 'service-level'.
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 usage context: you need a mail hosting ID. It doesn't explicitly mention when not to use it or alternatives, but the verb 'list' and resource scope provide clear context.
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?
Beyond the annotations (destructiveHint, readOnlyHint false), the description adds a key behavioral trait: two-phase confirmation for writes. This is valuable context. However, it does not elaborate on the consequences of delete or token regeneration, though the annotation already flags destructiveness.
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 fluff. The first sentence front-loads the purpose with specific verbs, and the second adds an essential behavioral note. 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?
The output schema exists, so return values are documented elsewhere. The description covers the core actions and the confirmation mechanism, which is sufficient for an agent to select and invoke the tool. Minor omissions about side effects of delete/regenerate are partially covered by annotations.
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 payload, team_id, and command_id (60% coverage). The description's mention of two-phase confirmation hints at confirmation_token but does not explicitly map parameters to actions. It adds little beyond the schema, and leaves confirmation_token's purpose partially implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the actions (create, update, delete, regenerate) on a particular resource (kChat slash command token). It distinguishes this mutation tool from read-only siblings like get_kchat_command and list_kchat_commands.
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 action verbs imply this is for mutations, and the existence of read-only siblings provides context, but the description does not explicitly state when to choose this tool over alternatives or when to pick one action over another. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two-phase confirmation and refetching of current access state before apply, which are valuable behavioral traits not available in the annotations. This goes beyond the existing readOnlyHint and destructiveHint flags by describing the tool's execution workflow.
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-loading the core purpose and adding one key behavioral note. No filler 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?
The tool is complex with 8 parameters, multiple actions, and a two-phase confirmation flow. While annotations and an output schema exist, the description lacks details on the confirmation token workflow and action-specific parameter requirements. It is adequate for high-level understanding but not fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, with only the payload parameter having a description. The description mentions action types and two-phase confirmation but does not explain the meaning or relationships of team_id, user_id, mailbox_name, invitation_webmail, or confirmation_token, leaving the agent to infer from parameter names and enums.
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: create, update, delete, or invite webmail access for mailbox users and teams. It uses specific verbs and a clear resource, and it distinguishes itself from the sibling tool infomaniak_get_mail_webmail_access by focusing on management operations.
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 purpose statement provides clear context for when to use the tool (any mutation to webmail access), and the mention of two-phase confirmation adds workflow context. However, it does not explicitly name alternatives or exclusions, such as recommending the get tool for read-only access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds meaningful behavioral context beyond annotations: 'two-phase commit' suggests a confirmation step (likely the confirmation_token), and 'trashed-item guard' implies validation that the item is in trash. This enriches the agent's understanding without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the primary purpose and then adds a key behavioral trait. No wasted words; every phrase earns its place. The structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and informative annotations, the description is largely complete for a straightforward restore operation. It covers the core action, resource, and a key behavioral nuance ('two-phase commit'). It could mention the need for a prior list-drive-trash step or explicitly describe the guard's failure behavior, but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover file_id and drive_id well, with 67% coverage. The description adds some value by linking the restore action to file_id and hinting at confirmation_token through 'two-phase commit', but it does not explicitly explain the confirmation_token parameter or its role. The added meaning is marginal relative to 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 ('Restore') and the resource ('one file or folder from kDrive trash'), which is specific and unambiguous. It distinguishes from sibling tools like remove_drive_trash_item or empty_drive_trash by focusing on restoration. The added mention of 'two-phase commit' further clarifies its unique role in the trash workflow.
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: restoring a single trashed item. The phrase 'from kDrive trash' and 'trashed-item guard' indicate it is meant for items currently in trash, but it does not explicitly state when to use this instead of alternatives (e.g., permanent deletion via remove_drive_trash_item) or mention prerequisites such as listing trash first. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not required to restate safety. It adds the specific output content (consumption and limit), but does not disclose additional behavioral traits such as account-level scope implications or units. This is adequate for a simple read operation with annotations present.
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 uses no unnecessary words. It conveys the exact purpose in under 15 words, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an existing output schema, and clear annotations, the description provides sufficient context for an agent to select and invoke it. Minor gap: it does not mention that this is a prerequisite check before creating short URLs, but this is implicit and not essential for a read-only quota endpoint.
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 with 100% coverage. Per the rubric, a baseline of 4 is appropriate because there are no parameter semantics to explain; the description correctly focuses on the return value instead.
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 ('Return') paired with a precise resource ('current consumption and limit of your account's short-URL quota'), clearly distinguishing it from siblings like infomaniak_list_short_urls (lists URLs) and infomaniak_create_short_url (creates URLs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking quota status before creating short URLs, but it does not explicitly state when to use it versus alternatives or mention any exclusions. Context signals from sibling tools provide some differentiation, but the description itself offers no direct 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?
Annotations already mark this as a write operation that is idempotent and non-destructive. The description adds behavioral context with 'Two-phase commit' and 'current user guard', which are not present in annotations. However, 'current user guard' is ambiguous and does not explain error conditions or exact consequences.
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 that front-loads the action and endpoint, followed by two compact behavioral hints. It contains no filler and does not repeat schema or annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, an output schema, and well-described core parameters, the tool is mostly complete. The two-phase commit behavior is flagged but not fully elaborated, which is a gap for an agent needing to perform the confirmation step correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes drive_id and user_id well, but confirmation_token has no description, contributing to 67% schema coverage. The 'Two-phase commit' hint hints at the token's purpose but does not explicitly explain when or how to populate confirmation_token.
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 'Unlock a kDrive user' and specifies the exact REST endpoint, making the tool's purpose unambiguous. It distinguishes itself from the sibling tool 'infomaniak_lock_drive_user' by targeting the unlock operation.
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 does not explicitly state when to use this tool over alternatives or mention prerequisites/exclusions. The 'Two-phase commit' phrase implies a multi-step workflow but does not explain when the confirmation token is required or how to complete the workflow, leaving usage guidance mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only, non-destructive, and idempotent. The description adds valuable behavioral context beyond annotations by disclosing a 'two-phase commit with current file-access guard', which alerts agents to confirmation requirements and concurrent-modification safety. This is meaningful extra information without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. The clause about two-phase commit adds meaningful technical detail without unnecessary verbosity. Every phrase 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?
With an output schema present and strong annotations, the description doesn't need to explain return values or safety profile. It does highlight a critical workflow aspect (two-phase commit) that is essential for correct invocation. It could mention the need for confirmation_token explicitly, but the hint is adequate given the output schema covers responses.
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 high (80%) and the schema provides clear descriptions for drive_id, file_id, and team_id. The description does not enrich payload semantics beyond calling it 'Access payload accepted by Infomaniak's file access teams endpoints', which is slightly vague. The 80% coverage keeps this at baseline, with no notable additional value from the description.
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 ('Update'), the resource ('a team's access role'), and the target ('kDrive file or folder'), distinguishing it from sibling tools like create or remove access. The additional 'Two-phase commit' phrase adds specificity without obscuring the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying existing team access, but does not explicitly state when to prefer this over create_drive_file_access_team or update_drive_file_access_user. It provides a mechanism hint (two-phase commit) but no clear alternatives or exclusions, leaving usage context to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds unique behavioral information about a 'two-phase commit with current file-access guard,' which is not expressed in annotations. This helps the agent understand the operation is not a simple direct update. However, it stops short of explaining what the guard does or how the two-phase flow works.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that front-load the primary purpose and add a key behavioral note. No wasted words, and the structure makes it easy to scan.
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?
Despite having an output schema and annotations, the description omits critical operational detail about the two-phase commit: how a confirmation token is obtained and used, and what the 'current file-access guard' checks. For a mutating tool with this workflow complexity, this is a significant gap that could lead to incorrect invocation. The description gives purpose but not enough to fully operate the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 of 5 parameters documented), so baseline is 3. The description does not add parameter-level meaning beyond the schema; the only undocumented parameter (confirmation_token) is only indirectly hinted at by 'two-phase commit.' The description neither remedies nor contradicts 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 states a specific action ('Update a user's access role') on a specific resource ('kDrive file or folder'), clearly distinguishing it from sibling create/remove/list tools. The two-phase commit note adds extra context without obscuring the core 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 action verb 'Update' clearly signals the intended use case (modifying an existing user's access role), providing clear context without explicitly excluding alternatives like create or remove. No when-not-to-use guidance is given, but the purpose 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?
Annotations already declare readOnlyHint=true, and the description aligns by saying 'Read'. It adds useful behavioral context by specifying the content of the audit log and that it is persistent, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word adds value. It avoids redundancy with schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema exists), the description is largely complete. It explains the tool's purpose and typical use cases. A minor gap is the lack of explicit differentiation from audit_log_search, but purpose clarity already handles that.
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 for the only parameter 'limit', and the description does not mention or explain it. The parameter is inferable from its name and constraints, but the description fails to compensate for the missing schema description, leaving the agent to guess its exact purpose.
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 a specific verb ('Read') and resource ('persistent MCP audit log'), scoped to 'newest entries'. It explicitly lists what can be inspected (recent tool calls, write confirmations, applied changes, failures), effectively distinguishing it from siblings like infomaniak_audit_log_search.
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 for when to use the tool: 'Use this to inspect recent tool calls, write confirmations, applied changes, and failures.' It does not explicitly mention alternatives or exclusions, but the intended use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, making the safe read nature clear. The description adds valuable context about what the detail includes (applications, permissions, link to phpMyAdmin), going beyond the annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise, front-loaded with the verb 'Fetch', and contains no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get tool, the description provides sufficient context: what the tool returns and the resource type. Output schema covers return structure, and annotations cover safety. The only minor gap is the lack of parameter details, but that is a separate dimension and not critical for overall completeness.
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 covers 50% of parameters (user_name has a description, hosting_id does not). The description does not compensate for the undocumented hosting_id; it only mentions 'single MariaDB-level user' which implicitly relates to user_name but not to hosting_id. No additional parameter meaning is provided 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 ('Fetch') and the resource ('detail of a single MariaDB-level user'), and specifies the type of details returned ('applications, permissions, link to phpMyAdmin'). It distinguishes from siblings by emphasizing 'single' user as opposed to listing tools like infomaniak_list_database_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need details of a single MariaDB-level user. It does not explicitly mention alternatives or exclusions, but the 'single' scope provides clear context relative to list tools. No misleading 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?
Annotations already declare read-only, idempotent, and open-world hints. The description adds the 'pending' qualifier, which is useful context, but does not disclose additional behaviors like error conditions or response specifics. Given the annotations cover the safety profile, 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?
The description is a single sentence of six words, front-loaded with the verb and resource. Every word adds value, 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 simple 2-parameter read operation with output schema and strong annotations, the description is complete. It clearly states what the tool does, and the schema covers the parameters, so no further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (drive_id described, invitation_id not). The description adds minimal meaning beyond the schema, though 'pending' implies invitation_id must refer to a pending invitation. It does not fully compensate for the missing invitation_id description.
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 'Read' and names the exact resource ('one pending kDrive user invitation'), clearly distinguishing it from sibling tools like list_drive_invitations. It is concise 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading a single pending invitation, contrasting with listing all invitations. It does not explicitly mention when to use this versus alternatives, but the context is clear and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description 'Inspect' aligns with read-only behavior but adds no additional behavioral context beyond what annotations provide. No extra details about response handling, errors, or side effects are given, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that fully states the tool's purpose with no filler or redundancy. It is appropriately sized for the tool's simplicity.
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?
This is a simple read-only tool with one parameter, existing output schema, and comprehensive annotations. The description sufficiently communicates the tool's role without needing additional detail on return values or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes channel_id as 'kChat channel id.' with 100% coverage. The description does not add any further parameter context or relationships, so it remains at the baseline of 3.
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 'Inspect the moderation settings for a kChat channel' uses a specific verb ('Inspect') and resource ('moderation settings for a kChat channel'). This clearly distinguishes it from sibling tools like infomaniak_get_kchat_channel (general channel info) and infomaniak_manage_kchat_channel (which mutates channels).
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 states the context: inspecting moderation settings for a kChat channel. It doesn't explicitly mention alternatives or exclusions, but the scope is unambiguous. The read-only nature is implied by 'Inspect' and reinforced by annotations, making it clear when to use this tool versus management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior; the description aligns with these and adds useful context by listing the specific fields returned (authorized senders, blocked senders, spam policy, filtering folders, note). It does not cover error or authorization nuances, but annotations reduce the burden.
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 one efficient sentence, front-loaded with the core action and resource, and uses a colon-delimited list to enumerate the returned state. No wasted 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?
This is a simple read operation with two well-documented parameters, a full output schema, and annotations confirming its safety and non-destructiveness. The description adds the key conceptual scope, making it complete for an agent to select and invoke 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 has 100% description coverage for both required parameters, so the baseline is 3. The description adds no additional parameter-level semantics, but none are needed because the schema already explains mailbox_name and mail_hosting_id clearly.
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 ('Read') and identifies the exact resource and scope ('mailbox security and spam-control state'), then enumerates the contained items. This clearly distinguishes it from generic getters and mutators in the sibling list.
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 usage context by naming the security/spam-control state, but it does not explicitly contrast with overlapping siblings like get_mailbox_full, list_mailbox_filters, or audit_mailbox_security. No when-not-to-use 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's 'read-only' statement adds limited new behavioral insight. It does not disclose additional traits such as authentication requirements or response behavior, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear sentences, front-loaded with an action verb, and contains no redundant or filler content. Every word contributes to understanding the tool's scope.
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 rich annotations, an output schema, and a high-level description covering all action categories, the description is complete enough for the tool's complexity. It does not need to explain return values since an output schema exists.
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 only 25% (only domain is described). The description partially compensates by mapping the action enum values to high-level inventory types (groups, subscribers, count-status), but it does not explain the group or subscriber parameter forms or per-action details 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 uses a specific verb 'Inspect' and enumerates the exact resources it covers: newsletter groups, group subscribers, subscriber inventory, and count-status summaries for a domain. It also clearly distinguishes the tool from its manage counterpart by labeling it read-only admin inventory.
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 communicates read-only inspection for list governance, implying when to use it. However, it does not explicitly state when not to use it or name the alternative manage_newsletter_admin, but the read-only framing is sufficient 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the tool is known to be a safe, idempotent read operation. The description adds minimal context by saying 'current' and 'feed', but does not explain the return format or whether results are cached or live. With annotations covering the safety profile, this is acceptable 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, well-structured sentence that immediately conveys the action and resource. It is front-loaded with the verb and contains no unnecessary words 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 zero-parameter, read-only tool with an output schema, the description is complete. It tells the agent what the tool does, and the output schema covers return values. No additional behavioral context is needed for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage (100%). The baseline for zero-parameter tools is 4, and there is no need for the description to explain anything further about 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 a specific verb ('Read') and resource ('current Infomaniak Public Cloud service status feed'), distinguishing it from sibling tools that manage or list cloud resources rather than report on service status. The term 'status feed' uniquely identifies this operation.
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 (read when you want to know the current status), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative tools. Since there are no parameters or complex conditions, the implied guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the 'admin inventory' and 'access audit/offboarding' context but does not disclose additional behavioral traits beyond the annotations. It is consistent and non-contradictory, but adds limited extra behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the primary action, and every word contributes meaning. 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 simple read-only list tool with complete schema coverage, strong annotations, and an output schema, the description provides adequate purpose and usage context. It covers the core need (identifying what and when) without exceeding scope.
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 100% coverage with descriptions for both required parameters (user_id and account_id). The description does not add any parameter-level semantics 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 verb ('List'), the resource ('app accesses'), and the scope ('for one account user'). It also distinguishes this tool from siblings like infomaniak_list_account_users or infomaniak_audit_account_access by framing it as an admin inventory for access audit and offboarding.
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: 'Read-only admin inventory for access audit and offboarding planning.' It implies when to use it (audit, offboarding) but does not explicitly name alternatives or when-not-to-use conditions. This aligns with 'clear context, no 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?
The description adds 'Lightweight keyword matching against tool names and descriptions', which honestly discloses the simplistic mechanism and potential limitations. This goes beyond the annotations (readOnly, idempotent, non-open-world) by explaining how the tool arrives at suggestions. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences—and front-loaded with the primary purpose. Every word earns its place, explaining both what it does and how it works without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values. The tool is simple, and the description covers its input ('intent') and mechanism ('keyword matching'). However, it omits guidance on the 'limit' parameter and what to do with the suggestions (e.g., invoke the suggested tool), but this is partially covered by the schema's default value and the obvious meta-tool role.
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 provides a description for 'intent' but not for 'limit'. The tool description mentions 'intent' but does not explain 'limit' at all. With schema coverage at 50%, the description should compensate for the undocumented parameter, but it does not. The agent is left to infer that 'limit' controls the number of suggestions, which is a gap.
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 'Suggest' with a clear resource 'which Infomaniak tools' and input 'given intent expressed in natural language'. It also distinguishes itself from the many sibling tools by explicitly being a meta-tool that recommends other tools, rather than performing a specific Infomaniak operation.
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 this tool: when the user has an intent in natural language and needs to identify which Infomaniak tool to invoke. However, it does not explicitly mention alternatives or when not to use it, such as when the user already knows the exact tool or needs detailed explanations. This is clear but lacks explicit 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, making the safety profile clear. The description adds beyond annotations by revealing the content semantics (destructive actions) and the inline undoability reference, which is useful for decision-making. It doesn't detail session boundaries or additional behaviors, but the added value is meaningful.
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, both dense with information. It front-loads the action and resource, then adds the reversal context. No wasted words; every phrase 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 list tool with an output schema and good annotations, the description covers the essentials. It could mention the limit parameter and clarify 'current session,' but these are minor gaps given the tool's simplicity. The undoability hook provides extra context not present in the structured fields.
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?
With 1 parameter (limit) and 0% schema description coverage, the description must compensate. It does not mention the limit parameter at all. Although the schema provides type, min, max, and default, the description should have explained how limit controls the list size or that it's optional. This is a clear gap.
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: listing destructive actions from the current session, most recent first. It also specifies a unique distinguishing feature—each entry includes undoability via infomaniak_undo—which differentiates it from sibling audit/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: to review destructive actions in the session and determine reversibility. It references infomaniak_undo as the companion tool, providing context. However, it doesn't explicitly contrast with alternatives like infomaniak_audit_log_search or state when not to use it, so it falls short of a perfect score.
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?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds behavioral scope ('every domain owned by an Infomaniak organization') and discloses the returned attributes (creation and expiration dates). It does not discuss pagination, but the output schema likely covers return details.
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?
Single declarative sentence with a front-loaded verb and object. Every word earns its place; there is no fluff or redundant restatement of the tool name.
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?
This is a simple list operation with one optional parameter, rich annotations, and an output schema. The description adequately specifies the scope and key return fields, and no further behavioral details are necessary for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with account_id already documented as optional, defaulting to the first account the token has access to, and discoverable via infomaniak_overview. The tool description adds no additional parameter semantics, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List every domain owned by an Infomaniak organization, with creation and expiration dates.' It clearly distinguishes from sibling tools such as infomaniak_get_domain and infomaniak_get_domain_full by emphasizing enumeration of all domains rather than a single domain lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for enumerating all domains in an organization, but it does not explicitly state when to prefer this over related tools like infomaniak_get_domain_full or infomaniak_list_sites, nor does it mention exclusions. The optional account_id guidance is present in the schema rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safe read-only nature is covered. The description adds the 'admin inventory for file permission review' framing, which is useful but does not disclose additional behaviors like pagination or list limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action, and no filler. Every word adds value, and the read-only/admin context is efficiently conveyed.
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 simple 2-parameter schema, strong annotations, and presence of an output schema, the description is complete enough for an agent to select and invoke the tool correctly. It identifies the resource type, the action, and the administrative review context without needing to describe return values.
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% and both parameters have clear descriptions (e.g., drive_id 'Discover via infomaniak_list_drives'). The description's 'file or folder' wording is already present in the file_id schema, so no additional parameter meaning is added.
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 'List team access entries for a kDrive file or folder', which is a specific verb + resource + scope. It clearly distinguishes from sibling tools like list_drive_file_access_users and list_drive_file_access_invitations by focusing on 'team access entries'.
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 'Read-only admin inventory for file permission review' gives clear context for when to use this tool. It does not explicitly name alternatives or exclusions, but the team-specific scope makes the appropriate use case obvious relative to the user/invitation 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is well covered. The description adds 'Read-only' (redundant) and 'admin inventory', which hints at admin-level access requirements but provides no new behavioral details such as pagination, output format, or rate limits. With annotations covering the core safety traits, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for action and scope, one for use case. No wasted words, front-loaded with the primary purpose, and easy to scan.
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 simple nature of the tool (list operation, two well-documented parameters, read-only annotations, and an output schema present), the description is complete. It clarifies the resource scope (file/folder user access) and the administrative context without needing to explain return values since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (file_id, drive_id) fully described in the schema. The description adds no extra parameter semantics beyond what's already in the schema. Per the rubric, baseline 3 is correct when 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 verb ('List') and the resource ('user access entries for a kDrive file or folder'), and differentiates from sibling tools like list_drive_users (drive-level) and list_drive_file_access_teams/invitations by specifying 'user access' scoped to a file/folder. It also gives the admin use case.
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 'Read-only admin inventory for file permission review' provides a clear use context: admins reviewing file permissions. It implies this tool is for per-file user access, distinguishing it from drive-level user listing, but does not explicitly name alternatives or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds behavioral scope by specifying 'every kDrive the account has access to', which clarifies that no filtering is applied and results include all accessible drives. This goes beyond the annotation safety profile, though it doesn't describe pagination or return format.
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?
Single sentence, front-loaded with the action and resource, zero unnecessary words. Perfectly concise.
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 simplicity of the tool (one optional parameter, rich annotations, and an output schema), the description is complete. It clearly states what it lists, and the output schema handles return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already thoroughly describes account_id, including its optionality and default behavior. The description adds no parameter-specific information, but the schema fully compensates.
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 'every kDrive the account has access to', which distinguishes it from sibling tools like infomaniak_list_drive_files (which lists files within a drive) and infomaniak_get_drive_full (which gets details of a specific drive). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not explicitly provide guidance on when to use it versus alternatives. The scope ('every kDrive the account has access to') implies it's the tool for enumerating drives, but no alternative tools are mentioned or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context by noting that each item shows deletion and addition dates, and that the tool is manager-private. This enriches the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, succinct and front-loaded with the main purpose. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema. The description covers the action, scope, and a use case, and the 'manager-private' note adds operational context. No major gaps.
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 only parameter, drive_id, has no description in the schema (0% coverage) and the tool description does not explain it. While the name is somewhat self-explanatory, the description adds no meaning beyond the schema field 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 clearly states the tool lists items in the kDrive trash bin (files and folders), with a specific verb and resource. It distinguishes from siblings by focusing on the trash bin and mentions the audit 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 explicitly states the use case: 'Use this to audit what's pending hard-deletion.' It provides clear context but does not explicitly mention alternatives or when not to use the 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description adds the 'Manager-private' restriction, which is a meaningful behavioral constraint not covered by annotations. It also clarifies the meaning of 'access' with 'who can touch what's in this drive.' No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the verb and resource, and every phrase adds value. Three short sentences cover purpose, use case, and a critical access restriction without any fluff.
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 is simple (one parameter) and has an output schema, so the description only needs to cover usage context. It provides purpose, audit relevance, and manager restriction. The only gap is the lack of guidance on obtaining drive_id, but that is minor given the simplicity and output schema.
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 the drive_id parameter at all. While the parameter name is self-explanatory, the description should have compensated for the lack of schema documentation by explaining how to identify the drive or that drive_id is required. It adds no semantic value 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 function: 'List the users with access to a kDrive.' This is a specific verb+resource combination. It also distinguishes from siblings by emphasizing drive-level access ('who can touch what's in this drive') and the 'Manager-private' note, which differentiates it from file-access or invitation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use: 'Useful for access audits.' This implies when to use the tool (auditing drive access). However, it does not explicitly name alternatives or state when not to use it, 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful scope (given organization, classic + Node.js) but does not disclose return format, pagination, or auth details. It adds some value beyond annotations but not rich 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 two sentences, front-loaded with the primary action and resource, and includes a useful prerequisite without redundancy. Every word earns its place.
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 low complexity, presence of an output schema, and strong annotations (readOnly, openWorld, idempotent), the description is complete: it names the resource types, the required scope (organization), and the prerequisite discovery step. No significant information gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: account_id has a full description, while include_nodejs has only type and default. The description's 'classic + Node.js' partially clarifies include_nodejs's purpose, but does not explicitly state that setting it to false excludes Node.js. The description compensates somewhat but does not fully carry the parameter-semantics burden.
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 web hostings (classic + Node.js) for a given Infomaniak organization, using a specific verb ('Lists') and resource ('web hostings'). It distinguishes from siblings like infomaniak_list_sites and infomaniak_list_nodejs_apps by explicitly scoping to hostings and including both classic and Node.js types.
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 prerequisite: 'Use infomaniak_list_organizations first to discover account IDs.' This gives explicit when-to-use guidance, though it does not mention when not to use this tool or name alternative listing tools, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description aligns. It adds the detail that both public, private, and deleted channels can be listed, which is useful behavioral context beyond the annotations. No contradictions.
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 short sentences with no redundant information, front-loaded with the action. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with a small input schema and an output schema available, the description covers the essential aspects: what is listed, the scope, and a use case. No significant information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 50% coverage; team_id is minimally described while visibility is only an enum. The description explains that the tool lists public, private, or deleted channels, effectively clarifying the visibility parameter, but team_id remains underdescribed. It partially compensates for the schema gaps.
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 (List), the resource (channels for one kChat team), and the scope (public, private, or deleted). This distinguishes it from sibling tools like infomaniak_list_kchat_channels by specifying team-scoped listing.
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 use case ('admin inventory and channel governance') but does not explicitly state when to prefer this over alternatives or any exclusions. It implies usage context but lacks direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds 'read-only view' and 'derived from mailbox filter inventory endpoint,' but these largely reinforce annotation attributes without providing new behavioral details like pagination or ordering.
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 composed of two concise sentences that immediately state the tool's purpose and scope. Every word contributes value, with no unnecessary detail.
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 listing nature, strong annotations, and the presence of an output schema, the description adequately covers what is returned. It explicitly scopes results to advanced Sieve scripts and mentions the underlying endpoint, which is sufficient for this 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 provides 100% coverage of both parameters with detailed descriptions (e.g., mailbox_name is the local part, mail_hosting_id has an exclusiveMinimum). The description does not add any parameter-specific semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource combination: 'List only the advanced Sieve scripts configured on a mailbox.' This clearly distinguishes it from sibling tool infomaniak_list_mailbox_filters by highlighting the 'advanced Sieve scripts' subset.
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 that this is a focused read-only view, implying it should be used when only advanced Sieve scripts are needed. However, it does not explicitly state when not to use it or mention any alternative tool, such as the general list_mailbox_filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds a behavioral nuance—listing globally or filtered by project—which is not present in annotations. This is useful context beyond the structured hints, though it does not describe pagination, permissions, or response 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 a single, front-loaded sentence with no filler. It efficiently communicates the core action and the key scope variation. Every word earns its place.
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 list operation with only two parameters, read-only annotations, and an output schema present, the description adequately covers the necessary context. The scope options are clear, and the output schema handles return-value details, so no additional explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does hint that project_id is optional (via 'globally or within a project') and that public_cloud_id is the cloud identifier, but it does not explicitly explain either parameter's role or format. The names are self-explanatory, but the description offers limited added value over 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 ('List') with a clear resource ('Public Cloud Kubernetes services') and explicitly specifies the scope ('globally or within a project'). This clearly distinguishes it from sibling tools like list_public_cloud_database_services and get_public_cloud_kubernetes_service.
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 context on the two modes of operation (global vs project-scoped) but does not explicitly state when to prefer this tool over alternatives such as get_public_cloud_kubernetes_service or other list tools. The usage is implied by the verb 'List', but no clear when/when-not guidance is offered.
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?
The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety profile. The description adds the 'server-side' qualifier and 'every' scope, which is some additional context. No contradictions, but no further behavioral details like pagination or output format 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?
The description is a single, front-loaded sentence with no unnecessary words. Every word adds meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 read-only tool with annotations and an output schema, the description is sufficiently complete. It states what the tool does, and the schema/annotations cover parameter and safety details, so no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required parameter, mail_hosting_id, with zero description coverage. The description implies the parameter's role by mentioning 'mail hosting' but does not explicitly explain that mail_hosting_id is the ID of the hosting. The parameter name is descriptive, but the description could compensate more given the low 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 uses a specific verb 'List' and clearly identifies the resource as 'server-side redirection rule' with scope 'on a mail hosting.' This distinguishes it from sibling tools that list mailboxes or mail hostings, 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 clear context that this tool is for listing redirection rules on a mail hosting, making the usage obvious. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to know when to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a crucial behavioral trait: 'Two-phase confirmation for every mutation.' This goes beyond the annotations (which only mark destructiveHint) and warns the agent of a confirmation step. However, it does not explain how the confirmation workflow operates, so it is not 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?
Two concise sentences, front-loaded with the core operations and a critical behavioral caveat. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters and multiple action types, yet the description does not specify per-action required fields or the payload structure. The output schema exists, so return values are covered, and the schema descriptions help, but the input semantics could be clearer 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?
With schema description coverage at 78%, the schema handles most parameter documentation. The description groups roles, scheme roles, and notify props conceptually but does not map specific parameters to actions or clarify the two-phase token requirement.
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 explicitly states the tool's actions: add, remove, update roles, update scheme roles, and update notify props. This clearly distinguishes it from sibling tools like infomaniak_list_kchat_channel_members.
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 for use: all mutations of channel members. It does not explicitly name alternatives or exclusions, but the sibling list tool and the action list make the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations by disclosing the two-phase confirmation and refetch-before-apply flow for write operations. This helps the agent anticipate the need for a confirmation token and understand the tool's internal safety mechanism, complementing the destructiveHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at just two sentences, with the purpose front-loaded and the operational caveat stated without fluff. Every word earns its place.
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 tool with 7 parameters and 4 actions, the description leaves out action-specific parameter requirements (e.g., 'replace' needs 'aliases', 'add/delete' need 'alias') and does not explain when the confirmation_token is required or how to obtain it. The existence of an output schema mitigates the need to describe return values, but the operational flow remains partially underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, with most parameters already described. The description adds meaning to the undocumented 'confirmation_token' by explaining the two-phase confirmation, which clarifies its purpose. It also hints why 'aliases' is used for replace operations, though it does not explicitly map parameters to actions.
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 resource (mailbox aliases) and the specific operations (list, replace, add, delete), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like infomaniak_create_mailbox_alias and infomaniak_delete_mailbox_alias by covering the broader 'manage' scope.
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 through the 'action' enum and mentions the two-phase confirmation, but it does not explicitly tell the agent when to choose this consolidated tool over the dedicated create/delete sibling tools, nor does it provide when-not-to-use guidance. It relies on the agent to infer that the action parameter determines usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations: the JWT is one-shot and valid ~1h, the endpoint hostname is fixed, the stream uses SSE, and the tool is 'Manager-private.' Since annotations already mark readOnly and non-destructive, the added context about credential lifecycle and streaming behavior is valuable. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it leads with the primary purpose, then details the return value, transport mechanism, usage example, and a practical tip. Each sentence adds meaningful information without redundancy or fluff.
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 tool's main purpose, output, and consumption method, which is sufficient for a credential-fetching tool. An output schema exists to formalize return values, and annotations cover safety. The only gap is lack of parameter detail, but that is a separate dimension. Overall, the context is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the meaning or role of hosting_id or vhost_route_id. It only mentions 'of a Node.js application' generically, which fails to map the parameters to those identifiers. With no schema descriptions and no param explanations, the agent must infer their purpose from context, which is insufficient.
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 credentials to consume the LIVE stdout/stderr stream of a Node.js application.' This specifies a unique verb-resource combination (get credentials for logs) and distinguishes it from sibling tools like status, aliases, and jobs. The mention of the returned JWT and endpoint URL further clarifies 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 explaining how to consume the stream (curl with Authorization header) and how to fetch a snapshot (kill curl after a few lines). It implies when to use this tool (for live logs) without explicitly contrasting with alternatives or stating exclusions, which is acceptable given the tool's distinct name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description adds valuable context: it is cheap and safe to poll, returns specific states, and requires SASESSION + CSRF cookies. These are behavioral traits not covered by annotations, making it highly 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 two sentences long, front-loads the purpose, and adds only essential extra information. No redundancy or fluff.
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 status tool with an output schema and strong annotations, the description covers purpose, usage, and authentication context. However, the lack of parameter guidance leaves a small but notable gap in completeness.
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 zero parameter descriptions, and the description does not explain `hosting_id` or `vhost_route_id` at all. With 0% schema coverage, the description was responsible for providing parameter semantics but completely omitted them.
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 live status of a Node.js application and explicitly lists the return values (`Running` or `Stopped`). It uses a specific verb ('Get') and resource ('status of a Node.js application'), distinguishing it from sibling tools like `get_nodejs_app` or `nodejs_app_action`.
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 context for when to use it: 'Cheap call, safe to poll' suggests repeated status checking, and 'Manager-private' indicates access constraints. It does not explicitly name alternatives, but the guidance implies it is the dedicated status polling 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?
Annotations already mark the tool as destructive and non-read-only. The description adds valuable behavioral context by noting a 'destructive two-phase commit with mailbox security state guard', which goes beyond the raw annotations and warns the agent about the operation's safety mechanism and destructive nature.
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 and immediately followed by the critical destructive and safety caveat. No filler or redundant wording.
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 destructive tool, the description conveys the key safety behaviors (two-phase commit, security guard) and the exact scope ('all messages currently in a mailbox spam folder'). An output schema exists, which reduces the need to document return values. Slightly more detail on what the 'security state guard' entails could improve completeness, but overall it is 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 description adds no parameter-level detail beyond what the schema already provides. The schema covers mail_hosting_id and mailbox_name clearly, and the description's mention of 'two-phase commit' hints at the confirmation_token's purpose but does not explicitly explain when or why it is needed. At 67% schema coverage, the description should compensate for the under-documented confirmation_token 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 ('Delete all messages') and resource ('mailbox spam folder'), clearly distinguishing it from siblings like infomaniak_empty_mailbox_trash or infomaniak_block_sender. The scope and action are 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 states what the tool does ('Delete all messages currently in a mailbox spam folder'), so the use case is evident. It does not explicitly mention alternatives or when not to use it, but the 'currently' wording and destructive framing provide clear context relative to other mailbox tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false; the description goes beyond by revealing 'two-phase commit' and 'current file-access guard,' which explains the process has a safety mechanism. It doesn't fully describe the consequences or the confirmation_token flow, but it adds meaningful context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, 17 words, front-loaded with the primary action. Every phrase earns its place: action, resource, destructive warning, and safety guard. No 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?
The description is adequate but leaves gaps: the 'current file-access guard' and 'two-phase commit' are mentioned but not explained, and the optional confirmation_token parameter is undocumented. With output schema present and annotations covering destructive safety, the description doesn't need to list return values, but more detail on the commit flow would improve completeness.
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 75% of parameters (drive_id, file_id, team_id), so baseline is 3. The tool description does not explain parameters further; notably, confirmation_token is optional, has no schema description, and its role in the two-phase commit is only implicitly referenced. This leaves a minor gap, but not enough to lower below 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 the specific action 'Revoke a team's access to a kDrive file or folder,' clearly distinguishing it from sibling tools like create/update_drive_file_access_team and remove_drive_file_access_user. The 'Destructive two-phase commit' phrase adds operational context without ambiguity.
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 tool's purpose directly implies when to use it: when a team's access to a kDrive file/folder must be removed. It doesn't explicitly name alternatives or exclusions, but the 'Revoke' verb and destructive warning provide clear context. No explicit when-not-to-use guidance, so not a 5.
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?
Beyond the annotations (destructive, non-read-only, non-idempotent), the description adds a meaningful behavioral detail about a two-phase commit and a fresh invitation snapshot guard. This provides concurrency/state context not present in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences, front-loading the core purpose and adding a critical behavioral detail. Both sentences are information-dense without unnecessary fluff.
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 an output schema and annotations, the description need not repeat those. However, it leaves the 'two-phase commit' and 'snapshot guard' unexplained, which may confuse an agent. It is minimally complete but lacks clarity on the workflow and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 params have descriptions), so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; it only hints at a snapshot guard but does not explain how it relates to parameters like confirmation_token.
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 starts with 'Patch an account invitation,' a specific verb+resource combination that clearly distinguishes this from sibling tools like create/delete/get invitation. The added 'Two-phase commit with a fresh invitation snapshot guard' further clarifies the operation's nature.
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 verb 'Patch' clearly implies updating an existing invitation, establishing usage context. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough for an agent to select it over create/delete siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutating but idempotent and non-destructive. The description adds valuable behavioral context: 'Two-phase commit with current share-link guard', which explains that updates are not a simple one-step operation and involves a guard. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that starts with the core purpose, then provides the endpoint and a key behavioral trait. No redundant words or fluff.
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 lacks details about the two-phase commit process: how to obtain the confirmation token, whether a prior get call is required, or what the 'current share-link guard' checks. While the output schema may provide return info, the agent could be underinformed for correct invocation in a multi-step workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 75% of parameters with descriptions. The description's reference to 'Two-phase commit' adds meaning to the confirmation_token parameter (though it is optional) and the overall update flow, complementing the schema's basic field descriptions.
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: 'Update a kDrive share link' with the specific HTTP endpoint. This distinguishes it from sibling tools like create_drive_share_link and remove_drive_share_link.
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 'Update' verb implies usage for modifying existing share links, but there is no explicit when-to-use or alternative guidance (e.g., 'use create_drive_share_link to create a new one'). The two-phase commit hint gives some context but not enough to direct choice among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behaviors: two-phase commit, asynchronous return of progress_id, eventual consistency (alias appears in list after a few seconds), and the manager-private restriction. This adds meaningful context beyond the readOnly/destructive hints, and there is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying essential information: core action, architectural effect, and key behavioral caveats (async, two-phase, manager-private). No fluff, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two-phase commit, async provisioning, destructive hint, output schema), the description and schema together cover the essential workflow: what it does, when to use it, what it returns, and the confirmation token's role. A slightly more explicit walkthrough of the two phases would improve it, but it is largely 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 already provides descriptions for aliases and confirmation_token, but site_id and hosting_id lack schema descriptions. The description itself does not elaborate these parameters, though the tool name and top-level text imply the hosting/site context. With only 50% schema description coverage, the description partially compensates by clarifying wildcard usage and DNS prerequisites for aliases, but leaves some gap for the two id 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 the action (bind FQDNs), the target resource (web hosting site), and the effect (Apache vhost serves the new domains). It also distinguishes the tool from related siblings like delete_site_alias by noting 'no new site provisioning required'.
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 useful context: it mentions the two-phase commit, asynchronous behavior, and the fact that no new site provisioning is needed, implying when this tool is appropriate. However, it does not explicitly name alternatives or conditions for not using it, such as when deletion is needed (sibling delete_site_alias).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context by outlining what will be checked (expiring products, maintenance, locked products, ongoing operations), which is useful beyond the annotations. It doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's purpose and then lists the types of issues found. 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?
The tool has an output schema and robust annotations, so the description need not explain return values. It covers the core purpose and categories, though it could mention the scope (entire organization) more explicitly. Overall it is sufficient for agent understanding.
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%, and each parameter (account_id, days_ahead, max_domain_checks) has a detailed description including defaults, constraints, and rate-limit context. The tool description itself doesn't add parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scan') with a clear resource ('Infomaniak organization') and enumerates concrete categories of issues (expiring, maintenance, locked, ongoing operations). This distinguishes it from other audit tools like infomaniak_audit_dns_zones or infomaniak_audit_account_access.
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 this tool: for a broad health/audit scan of an organization. It doesn't explicitly state exclusions or alternatives, but the context is clear for a general audit 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?
Annotations already disclose read-only and idempotent behavior. The description adds valuable behavioral context: it scans all domains by default, each domain requires 2 sequential API calls, and the default max_domains keeps execution under ~30s. This goes beyond the annotations to set performance 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 two sentences, front-loaded with the core purpose, and includes a practical use case. Every word earns its place; no fluff or redundant details.
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 complexity (bulk audit, optional params, output schema present), the description covers purpose, use case, performance implications, and scoping options. It omits explicit alternative tool comparisons, but overall it is complete enough for an agent to select and invoke 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?
All three parameters are fully documented in the input schema, including descriptions, defaults, and constraints. The tool description adds little beyond the schema—only reinforcing the bulk-read scope. Since schema coverage is 100%, 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 a specific verb ('Bulk-read') and resource ('every domain owned by an account'), with the exact output (number of DNS records and DNSSEC status). It distinguishes itself from sibling tools like list_domains and dns_list_records by focusing on bulk auditing across all zones rather than per-zone operations.
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 for when to use the tool ('spot-checking large fleets') and how to scope it (via filter_contains for targeted audits). It does not explicitly name alternative tools or list exclusions, but the guidance is sufficient for a read-only audit 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?
The annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description reinforces this with 'Read-only' and adds valuable context about the audit scope (DNSSEC, MX, SPF, DMARC, wildcard, TTLs), which goes beyond the annotations. It does not disclose output format, but the output schema covers that.
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 entire description is one sentence, front-loaded with 'Read-only' and packed with specific audit items. It is concise with zero filler or repetition of schema 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?
The tool has an output schema and clear annotations, so the description does not need to explain return values. It sufficiently communicates the audit scope and parameters. However, it does not explicitly mention that the zone parameter defaults to the domain, which is a minor gap but covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds meaning by linking 'very low TTLs' to the low_ttl_threshold parameter, helping the agent understand why that parameter exists. It does not add syntax details, but the schema already handles that.
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 ('audit') and resource ('domain/DNS admin posture'), and enumerates the exact checks (DNSSEC, MX, SPF, DMARC, wildcard records, low TTLs). This clearly distinguishes it from siblings like infomaniak_audit_dns_zones by focusing on a single domain's administrative posture.
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 auditing a specific domain's DNS security posture, but it does not explicitly state when to use this tool versus alternatives such as infomaniak_audit_dns_zones or infomaniak_dns_list_records. No exclusions or comparison are provided, so guidance is implied 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?
Annotations already declare readOnlyHint=true and idempotentHint=true; the description reinforces this with 'read-only' and adds significant context by enumerating the audit categories. It does not describe return format or failure modes, but with strong annotation coverage this is not a major gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately states action and scope, then uses a compact list to enumerate audit areas. 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 read-only audit tool with an output schema and two well-documented parameters, the description covers the main behavioral aspects. It could elaborate on what 'posture audit' means or how results are structured, but the enumerated areas and output schema make it 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?
Schema description coverage is 100% — both drive_id and storage_warning_ratio have clear descriptions. The tool description adds no parameter-level detail beyond establishing the audit context, 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?
Description uses a specific verb ('audit') and resource ('kDrive admin') and enumerates the audit scope (product health, users, external users, public share links, settings, storage usage, trash count). This clearly distinguishes it from sibling tools like infomaniak_audit_account or infomaniak_audit_dns_zones.
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 makes clear this is for kDrive admin posture auditing and lists the covered areas, giving solid context for when to use it. It does not explicitly name alternatives or when-not-to-use, but the scope is unambiguous given the sibling tool set.
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?
The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the 'persistent' nature of the log and the search dimensions, but does not disclose behaviors like result ordering, pagination, or the fact that 'contains' searches across JSON entries (though the schema partially covers this). With annotations covering the read-only aspect, the description adds moderate value.
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 action ('Search the persistent MCP audit log'), and every word earns its place. It is concise without being under-specified.
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 an output schema, so return values are covered. The description gives the search dimensions and use cases, which is adequate for a read-only search tool. It could be improved by mentioning differences from sibling audit tools or how results are ordered, but given the output schema and annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, so the description needs to compensate. It lists the main filter categories (tool name, phase, risk, timestamp range, free text) which map to the schema parameters, giving the agent an overview of what filters are available. However, it does not detail each parameter's syntax or the limit parameter, but the schema provides types and enums, and the description helps connect purpose to 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 the tool searches the persistent MCP audit log with specific filter criteria (tool name, phase, risk, timestamp range, free text). It distinguishes itself from sibling audit tools by focusing on general-purpose search over the audit log. The use cases 'what changed today?' and 'did anything destructive run?' reinforce its 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 context for when to use the tool by listing example questions it answers. However, it does not explicitly mention alternatives like infomaniak_audit_log_tail or state when not to use this tool, so it lacks 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?
Beyond annotations (destructiveHint=true, idempotentHint=false), the description reveals crucial behavior: the two-phase commit, a fresh snapshot guard, and passthrough of the payload as-is. This adds meaningful context about how the operation executes and potential failure semantics, though it does not detail failure handling or prerequisites.
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. Each clause earns its place: action, key behavior (two-phase commit), and payload handling. No fluff or redundant rephrasing.
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 provides essential context for a mutating operation with annotations and an output schema present. However, the two-phase commit mechanics (e.g., when the confirmation token is required, what the snapshot guard checks) are under-specified, leaving some gaps for an agent to guess. Still, the existing structured metadata lightens the load.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers payload and account_id with descriptions, but confirmation_token lacks a description. The description explains that payload is passed through 'as-is', clarifying its role, and 'two-phase commit' implies confirmation_token's purpose. This partially compensates for the missing token description, though 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 states a specific action ('Create an account tag') with a clear resource, distinguishing it from sibling tools like update_account_tag and delete_account_tag. The two-phase commit mention adds a unique behavioral characteristic that further identifies this tool.
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 is for creating tags with a concurrency-safe two-phase commit, but it does not explicitly state when to prefer it over alternatives or what preconditions must hold (e.g., when confirmation_token is needed). The phrase 'fresh tag-list snapshot guard' hints at a use case requiring conflict prevention but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context beyond the annotations, including the two-phase commit process, the distinction between SFTP-only and full shell access, and the password policy. These details are not exposed by the readOnlyHint/destructiveHint annotations and are valuable for an agent to understand the tool's non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that front-load the core purpose and immediately provide essential distinctions (connection types, two-phase commit). Every sentence contributes functional information, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description tells the agent the essential facts: what it does, the two-phase commit, and connection type meanings. The schema covers parameter details and the output schema exists, so return values are not required. It doesn't elaborate on permissions or failure modes, but for a create operation with rich schema support, this 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 all 6 parameters with detailed descriptions (login prefix rule, password regex, hosting_id discovery, home_directory default, connection_type enum, confirmation_token purpose). The description text adds no significant parameter information beyond the schema, so it rests at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a new FTP / SSH user on a web hosting', identifying the specific verb and resource. It distinguishes from sibling tools like infomaniak_list_hosting_users and infomaniak_delete_hosting_user by focusing on creation. The mention of two-phase commit further clarifies the tool's unique scope.
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 specifying connection types and password policy, but it does not explicitly state when to use this tool vs alternatives like list_hosting_users or delete_hosting_user. No exclusions or alternative recommendations are provided, so the usage guidance is only 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations, such as the two-phase commit flow and that the password never appears in the plan output. However, it does not explain the non-obvious destructiveHint=true annotation, and the operation is described as 'create' without discussing potential destructive side effects, leaving a gap in 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 exactly two sentences, front-loaded with the primary purpose, and includes the workflow and security note without any extraneous words. Every sentence 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?
The tool has a complex two-phase commit behavior, and the description covers it sufficiently. An output schema exists to document return values, and the description explains the core workflow. It could be more complete by mentioning prerequisites like discovering the mail_hosting_id, but that is covered in the schema, so the overall context is adequate.
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 already provides descriptions for all 5 parameters (100% coverage), so the baseline is 3. The description adds value by clarifying the role of confirmation_token in the two-phase process and emphasizing that the password is only used in the apply call, which complements the schema's notes.
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 'Create a new mailbox on a mail hosting' with a specific verb and resource. It distinguishes itself from sibling tools like infomaniak_create_mailbox_alias and infomaniak_delete_mailbox, and the two-phase commit detail adds additional precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly describes the two-phase commit process ('plan + token first, then apply with token'), which is a critical usage guideline. However, it does not explicitly mention when not to use this tool versus other mailbox-related tools, though the purpose is clear enough to infer proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, but the description goes further by explaining the fallback to no HTTPS or default cert and the two-phase commit behavior. This adds context about what happens after deletion and the safety mechanism of a planning phase. It doesn't disclose every consequence (e.g., potential downtime) but provides useful transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 every word adds value. It explains the outcome, the two-phase commit, and the planning benefit without fluff. Structure is clear and focused.
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 destructive nature and two-phase flow, the description captures the essential context: what happens, how to preview, and that a new cert can be requested later. An output schema is present, so return values are covered elsewhere. The description lacks explicit prerequisites (e.g., hosting_id/site_id), but those are in the schema. Overall, it is complete for an agent to understand 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?
Input schema covers all parameters (100% coverage) with descriptions for site_id, hosting_id, and confirmation_token. The description does not add parameter-specific details beyond the schema, but it does reinforce the two-phase flow involving confirmation_token. Since the schema already provides thorough explanations, 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 purpose: 'Delete the SSL certificate of a site.' It uses a specific verb and resource, and the fallback behavior ('will fall back to no HTTPS or Infomaniak's default cert') distinguishes it from certificate provisioning tools like infomaniak_request_certificate. The name and description together leave no ambiguity.
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 two-phase commit process: 'The plan pulls the current certificate status so the caller can see what is about to be removed.' This tells the agent that a first call (without confirmation_token) generates a plan, and a second call executes. It also implies the alternative for re-adding a certificate ('until a new one is requested'), though it doesn't explicitly name infomaniak_request_certificate in the description. No exclusions are stated, but the context is sufficient for an agent to know 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: 'destructive two-phase commit' explains the staged deletion process and implies the confirmation_token's role, while 'current user guard' warns that deleting yourself is not possible. This goes beyond the simple destructiveHint=true already in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core action. Every word adds value, and it successfully conveys the purpose and critical behavioral traits 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 destructive three-parameter tool with an output schema and strong annotations, the description covers the essential context: what it does, that it is destructive, and that a two-phase commit protects against accidental deletion. It could mention consequences (e.g., loss of access) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 67% because confirmation_token lacks a schema description. The mention of 'two-phase commit' in the description adds semantics that help infer why confirmation_token exists, supplementing the schema. The drive_id description already explains discovery via list_drives.
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 begins with a specific verb+resource+scope: 'Delete a kDrive user from a drive.' This clearly distinguishes the tool from siblings like lock_drive_user, unlock_drive_user, and update_drive_user, and the destructive nature is immediately evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to remove a user from a drive, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites beyond the schema note for drive_id referencing list_drives. No explicit guidance is given for when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey destructive hint and non-read-only. The description adds significant behavioral detail: the two-phase commit process, including the plan preview and confirmation token. This context is not present in annotations and helps the agent understand the deletion is not immediate, requiring a second call. It does not cover token expiry or failure modes, but the core behavior is 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?
Two sentences, front-loaded with the primary purpose, followed by the two-phase explanation. Every word adds value—no fluff. The structure is clear and easy to parse.
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 output schema and annotations, the description covers the essential workflow: delete operation with two-phase commit, preview, and token. It doesn't explicitly mention prerequisites like zone ownership, but the schema's zone description includes that. It is sufficiently complete for a destructive tool with good annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a detailed description (zone, record_id, confirmation_token). The description adds minimal parameter info beyond referencing the token from the first phase, which the schema already explains. Baseline of 3 applies because the schema handles parameter semantics well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a DNS record from an Infomaniak-managed zone.' It uses a specific verb and resource, and the two-phase commit explanation further distinguishes it from simple delete tools. It is easily differentiated from sibling tools like infomaniak_dns_create_record and infomaniak_dns_update_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to delete a DNS record) and provides the two-phase workflow, which is a key usage guideline. It does not explicitly mention alternatives or exclusions, but the purpose is clear. The schema reference to infomaniak_dns_list_records for obtaining record_id also guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, so the description adds value by listing the specific data categories returned and the manager-level access requirement. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single efficient sentence that front-loads the purpose and uses a concise list of included data. Every item is specific and non-redundant.
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 a rich output schema present, the description covers all necessary behavioral context: input formats, included data, and access requirements. It is fully sufficient for selecting and invoking the 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 single parameter 'domain' is fully described in the schema (100% coverage); the description only briefly reiterates ID/FQDN acceptance without adding format or discovery details beyond what the schema 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?
Description clearly states it returns 'Full domain detail' and enumerates specific fields (auth_code, transfer_status, DNS health, etc.), distinguishing it from simpler domain tools like infomaniak_get_domain. The verb+resource+scope 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the accepted input forms (domain_id or FQDN) and notes 'Manager-private' access, giving clear context for invocation. It does not explicitly name alternative tools or exclusions, but the scope is evident from the detailed field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent, so the bar is lower. The description adds that it hits only the corresponding endpoints in parallel, revealing efficiency and conditional behavior. No contradiction.
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?
Three sentences, front-loaded with purpose, each sentence has a distinct role: purpose, field selection, replacement statement. 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?
With output schema and rich annotations, the description is sufficient: it names the three sections, explains field behavior, and provides migration context from old tools. No critical missing info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already fully documented. The description only restates the 'subset' concept and parallel behavior, adding minimal semantic value 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?
States 'Read mailbox metadata in one call' with a specific verb and resource. Explicitly distinguishes from siblings by naming the replaced trio and the three metadata sections (aliases, signatures, backups).
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 explicit guidance to use this instead of the v0.9 trio, and explains how to select subsets via the fields argument. Doesn't discuss alternatives like get_mailbox_full, but the replacement context gives a clear when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the account-scoped nature of the listing, which is useful context beyond the annotations. No contradictions or additional behavioral details are necessary for this read-only 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 a single concise sentence that immediately conveys the tool's purpose. It is front-loaded with the action 'List' and includes the essential scope ('your account' and the service). No filler or unnecessary details.
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?
The tool is simple with only two optional pagination parameters, and the output schema covers return values. Annotations cover safety and idempotency. The description provides enough scope information, and there are no missing behavioral or usage details that would hinder correct 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?
The input schema has two parameters (page, per_page) with defaults and constraints, but the description provides no additional meaning or explanation of pagination. Schema description coverage is 0%, so the description should compensate, but it doesn't mention that the tool is paginated or how the parameters behave.
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 a clear resource: short URLs on Infomaniak's url-shortener service. It also scopes to 'your account,' which differentiates it from sibling tools like infomaniak_create_short_url and infomaniak_short_urls_quota.
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 this is the read/list operation for short URLs, with no ambiguity. It doesn't explicitly state when not to use it or mention alternatives, but given the simple nature of the tool and clear sibling context, the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, idempotent mutation. The description adds the critical behavioral detail of 'two-phase commit with current user guard', which informs the agent that a confirmation token is required and that self-locking is guarded.
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 action, endpoint, and key behavioral traits with 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 mutating tool with an output schema and annotations, the description provides the essential hint about the two-phase commit workflow, but does not fully explain the sequence of calls. This is adequate but could be more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 67% of parameters; drive_id and user_id have descriptions. The description's 'two-phase commit' hints at the purpose of the confirmation_token parameter, adding some meaning beyond its format-only schema entry.
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 'Lock' and resource 'kDrive user' with the exact HTTP endpoint, clearly distinguishing from sibling tools like unlock_drive_user and delete_drive_user.
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 does not explicitly state when to use this tool over alternatives. It implies usage through the name and 'Lock' action, but there is no mention of unlock/delete/update alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two-phase confirmation with a fresh settings snapshot and that null removes the limit. This adds significant behavioral context beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), explaining the confirmation workflow and null semantics.
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 tight sentences: the first states the primary purpose, the second adds essential behavioral details. No filler, 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?
Given the moderate complexity and existence of an output schema, the description covers the core action, null behavior, and confirmation mechanism. It omits details on the confirmation token acquisition and snapshot meaning, but the annotations and output schema reduce the burden. Overall, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (drive_id has a description). The description clarifies that size_threshold is the maximum allowed size and null removes the limit, and it hints at confirmation_token via 'two-phase confirmation.' However, it does not fully explain how the confirmation token is obtained or how the snapshot works, so it only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update the maximum allowed size of kDrive private folders,' specifying the exact action, resource, and scope. It distinguishes this tool from broader drive management siblings by focusing on the private folder size limit.
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?
There is no explicit when-to-use or alternative tool guidance. The purpose makes it clear it is for updating private folder size limits, but it does not mention when to use it versus similar tools like manage_drive_settings, leaving usage implied 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?
The annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context by mentioning the forwarding-address collection endpoint and the two-phase confirmation for mutations, which goes beyond the annotations. This helps the agent understand that mutations require a confirmation token and are not immediate. It does not detail specific side effects of delete, but the annotations cover destructiveness.
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-loaded with the core purpose. Every word adds value, with no filler or repetition of schema details. It efficiently covers the main actions and a key implementation detail.
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 output schema exists, return values are covered. The tool has 6 parameters, an enum, and nested objects, making it moderately complex. The description provides the essential purpose, the actions, and the critical two-phase confirmation behavior. It could mention that confirmation_token is required for mutations, but the two-phase confirmation implies that. Overall, it is complete enough for an agent to understand the tool's scope and proceed, though some action-specific payload requirements are not described.
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 67%, with descriptions for mailbox_name, mail_hosting_id, and forwarding_address, but not for action, payload, or confirmation_token. The description mentions the action categories and two-phase confirmation, which indirectly relates to the action and confirmation_token parameters, but it does not fully compensate for the undocumented parameters, especially payload which is a raw object with no semantics. The schema enum for action is clear, but the description adds limited parameter meaning beyond what the schema 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 specific actions (list, replace, add, delete) on the resource 'mailbox forwarding addresses', which distinguishes it from sibling tools like manage_mailbox_aliases or manage_mailbox_auto_reply. It uses a specific verb-resource combination that leaves 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 gives clear context that this tool manages mailbox forwarding addresses and notes the two-phase confirmation for mutations. However, it does not explicitly state when to use this tool over alternatives or provide any exclusionary guidance. It implies usage for forwarding address management but lacks explicit when/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?
Beyond the annotations (destructiveHint, readOnlyHint, etc.), the description adds crucial workflow behavior: two-phase commit, plan listing every step, sequential ordered execution on apply, and visibility into partial completion on failure. This adds real context without contradicting the structured hints.
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?
Three tightly-scoped sentences: purpose first, workflow next, execution semantics last. No filler or repetition of schema content; every sentence 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?
Given the tool's multi-resource complexity and 8 parameters, the description covers the high-level workflow and failure visibility, while the rich schema and output schema carry the remaining burden. It could mention that the first call produces the plan and the confirmation_token comes from that plan response, though the schema already states this.
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%, and each parameter already carries detailed semantic documentation (FQDN pattern, zone derivation, TTL bounds, confirmation_token phase). The tool description itself adds no parameter-level detail, matching the baseline for fully-covered schemas.
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: 'Provision a complete website end-to-end' and explicitly enumerates the three components (web site, MariaDB database, DNS A record). This clearly distinguishes it from sibling tools like infomaniak_create_site or infomaniak_dns_create_record, which handle only one piece.
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 communicates clear context: this is the composite provisioning tool for a full website, and the two-phase plan/apply workflow explains how the agent should drive it. It does not explicitly name alternatives or state when-not-to-use cases, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and idempotentHint. The description adds meaningful context about 'two-phase commit' and 'current share-link guard', which are not present in annotations and help set expectations about safety and confirmation requirements.
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, information-dense sentence covering the action, endpoint, destructive nature, and the guard mechanism. 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 destructive operation with an output schema, the description covers key aspects: what is removed, the endpoint, the two-phase commit, and a safety guard. It does not explain when confirmation_token is required or what the output looks like, but the output schema handles the latter. Slightly incomplete due to token ambiguity.
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 covers drive_id and file_id with descriptions. The description mentions 'two-phase commit', which relates to confirmation_token but does not explicitly explain its purpose or required usage. With 67% coverage, the description could better clarify the optional token's role.
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 action: 'Remove a kDrive share link' with the HTTP method and path. It clearly distinguishes from sibling tools like create, update, invite, and list by focusing on removal.
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 indicates this is for removing a share link and mentions the destructive nature, implying when not to use it. However, it does not explicitly name alternatives or contrast with update/create, so it lacks explicit exclusion 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?
The description adds behavioral context beyond annotations by disclosing the two-phase commit pattern and the return of an operation_uuid for async tracking. Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description is consistent with these. It does not cover rate limits or auth requirements, but the two-phase commit disclosure is valuable.
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-loaded with the primary purpose, and efficiently packs in the two-phase commit, supported types, required parameters, and return value. Every sentence earns its place with no redundant or filler content.
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 complexity (8 parameters, two-phase commit, three types) and the presence of a rich input schema and output schema, the description adequately covers the workflow and key decision points. It mentions the return value and polling mechanism, which is essential. It does not enumerate every parameter, but that is appropriately delegated to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does summarize the three certificate types and their required fields, but this information is already fully present in the schema's parameter descriptions (e.g., type enum, certificate_id, certificate, private_key). The description adds no extra semantic value beyond what the schema 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 tool's purpose: 'Request a new SSL certificate (or re-issue / renew an existing one) for a site on a web hosting.' It uses a specific verb ('request') with a clear resource (SSL certificate) and scope (site on hosting). It also distinguishes itself from sibling tools like infomaniak_get_certificate by mentioning the workflow of polling that tool for progress, and from deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (new, re-issue, renew) and explicitly names infomaniak_get_certificate for tracking progress, which serves as an alternative. However, it does not explicitly state when NOT to use it (e.g., for certificate deletion or listing), though sibling tools are available. The guidance is strong but could be more comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable nuance by clarifying that the 'check' path is read-only and that 'rotate' requires two-phase confirmation. No contradiction with annotations; the description supplements them.
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 purpose, and contains no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, output schema, and the tool's complexity (destructive rotate with confirmation), the description covers the key safety distinction. It could be more explicit about prerequisites or the effect of rotation, but it is sufficient for an agent to understand the core workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description should compensate. It adds meaning to the 'action' parameter (check vs rotate) and explains why 'confirmation_token' exists ('rotate uses two-phase confirmation'). However, it does not explain how to obtain the token or that it is required for rotate, leaving some gaps.
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: 'Check or rotate the DKIM key for a mail hosting.' It uses specific verbs ('check' and 'rotate') and names the resource ('DKIM key', 'mail hosting'). This distinguishes it from sibling tools, none of which mention DKIM.
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 each action: 'The check path is read-only; rotate uses two-phase confirmation.' This helps the agent decide between check and rotate, though it does not explicitly compare to alternative tools or state 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?
The description adds valuable behavior beyond annotations: it reveals the two-phase commit mechanism (current-state diff, confirmation token, conditional apply if state unchanged). This is complementary to the destructiveHint and openWorldHint annotations, providing concurrency control details not present in structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function, with the second sentence explaining the critical two-phase behavior. 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?
The description is adequate for a tool with a comprehensive input schema and an output schema. It covers the essential purpose and the two-phase commit workflow, though it could be slightly more explicit about the invocation sequence (plan call without token, apply call with token). This is partially addressed by the confirmation_token parameter description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters are fully described in the input schema (100% coverage), so the description does not need to add per-parameter details. It does mention the categories of fields (spam movement, smart filtering folders, admin note), but does not add new meaning 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 uses the specific verb 'Update' and lists the exact resources: mailbox spam movement, smart filtering folders, and admin note. This clearly differentiates it from sibling tools like infomaniak_update_mailbox_folders or infomaniak_purge_spam_folder.
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 for when this tool is relevant (updating spam policy), but does not explicitly mention alternatives or exclusion cases. For example, it doesn't state 'use infomaniak_update_mailbox_folders for folder name changes' or 'do not use this for filter scripts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing the two-phase commit behavior, the need for a confirmation token, and the conditional apply ('if the mailbox sender lists have not changed'). This reveals concurrency protection and non-atomicity, which are critical for the agent to invoke correctly. No contradiction with destructiveHint or idempotentHint.
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 purpose, and then efficiently explains the two-phase process. No redundant or filler content.
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 complexity of a two-phase commit, the description clearly outlines the protocol. An output schema exists to document return values, so that is covered. However, it does not explain what happens if the sender lists have changed (failure mode), nor explicitly mention that a blocked sender must exist first. Minor gap for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters with meaningful details (e.g., mailbox_name format, confirmation_token format). The description adds no extra parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Unblock this sender') and identifies the resource (sender lists). It distinguishes from siblings like block_sender and unauthorize_sender by naming the inverse operation directly. The two-phase commit detail reinforces what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear procedural context (two-phase commit flow) but does not explicitly state when to choose this tool over alternatives such as authorize_sender or block_sender. The 'unblock' naming implies usage when a sender is blocked, but no explicit when/when-not guidance is 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?
Annotations already mark the tool as destructive, non-read-only, and idempotent. The description adds valuable behavioral context by mentioning a two-phase commit and a mailbox security state guard, which are not conveyed by the annotations. It does not contradict the annotations, and it helps the agent anticipate a multi-step confirmation process.
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-loading the primary purpose and then adding a critical behavioral note about the two-phase commit. No wasted words; every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 10-parameter schema, annotations, and the presence of an output schema, the description is largely complete. It explains the core operation and highlights the two-phase commit, but it lacks explicit guidance on when to use the tool and does not describe the output beyond what the schema likely covers. Still, it is sufficient for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has high description coverage (90%), so the baseline is 3. The description lists the folder types but does not add significant parameter-level detail beyond what the schema already provides. It does not explicitly explain the confirmation_token, though 'two-phase commit' indirectly references 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 ('Update') and identifies the exact resource ('mailbox folder mappings') and enumerates the folder types (archives, drafts, sent, trash, spam, commercials, social-networks), clearly distinguishing it from sibling tools like mailbox filters or security configuration. The mention of 'Two-phase commit' further clarifies the operation's nature.
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 usage for modifying folder mappings by listing the affected folder types, but it does not explicitly state when to use this tool over alternatives or when not to use it. The 'two-phase commit' and 'security state guard' hint at a confirmation step, providing some context for sensitive operations, but no explicit exclusions 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?
The description adds 'Two-phase commit with current inventory guard' beyond the annotations (destructiveHint, readOnlyHint=false), revealing a safety mechanism and a two-stage workflow. However, it omits how confirmation_token fits into that workflow, leaving some ambiguity about the required sequence.
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?
Three short, focused sentences with no redundancy: purpose, mode selection, and a key safety trait. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema and good annotations, the description fails to explain the two-phase commit protocol: when and how confirmation_token should be supplied, and what the 'current inventory guard' means for the caller. This is a critical gap for a tool with a complex workflow, leaving the agent to guess the required sequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the critical parameter old_name by explaining that omitting it creates and providing it updates/renames, which is not fully captured by the schema's description. With 71% schema coverage and good schema descriptions for most other parameters, this added semantics pushes it above 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 action ('Create or update') and the resource ('mailbox Sieve script'), distinguishing it from sibling tools like delete_mailbox_filter_script and list_mailbox_filter_scripts. The specificity to Sieve scripts further differentiates it from create_mailbox_filter/update_mailbox_filter.
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 explicit guidance for both modes: 'Omit old_name to create; provide old_name to update/rename.' It does not explicitly name alternative tools, but the create/update distinction is actionable. The mention of 'current inventory guard' implies a prior inventory listing step, which is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds valuable context beyond annotations: 'GET runs immediately. POST/PUT/PATCH/DELETE follow the two-phase commit pattern.' It also discloses the /proxy/ endpoint restriction. This is meaningful behavioral information not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the most critical information (escape hatch, target API, when to use). Every sentence earns its place: it covers purpose, usage boundary, and method-specific behavior with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic escape hatch with no dedicated schema descriptions. The description covers purpose, usage boundaries, and key behavioral differences (immediate GET vs. two-phase commit). It does not explain the two-phase commit process in detail, but the output schema and annotations provide additional context. Overall, it is reasonably complete for a generic API call tool, with minor gaps around parameter construction and explicit destructive operation warnings.
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 does not explain the path, body, query, or confirmation_token parameters in any detail. The only parameter-related hint is that non-GET methods use a two-phase commit pattern, implying the need for confirmation_token. The description does not clarify the structure of body/query or the expected path format, leaving a significant gap in parameter understanding.
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: 'call ANY Infomaniak public API endpoint (api.infomaniak.com) when no dedicated tool exists.' It uses a specific verb ('call'), identifies the resource (Infomaniak public API), and distinguishes itself from the many typed sibling tools by explicitly positioning itself as an escape hatch.
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 guidance on when to use this tool: 'when no dedicated tool exists.' It also states an exclusion and an alternative: 'Manager-private (/proxy/...) endpoints are NOT reachable through this tool — use a typed tool instead.' Additionally, it differentiates behavior by method (GET vs. POST/PUT/PATCH/DELETE), offering clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds value by revealing that the tool highlights privileged/broad access and reports per-user fetch errors, which implies multiple API calls and per-user error handling. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and key highlights. Every word earns its place, with no redundant details.
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 high annotation coverage (read-only, idempotent), a detailed output schema, and a schema that fully documents parameters, the description is sufficiently complete for a read-only audit tool. It communicates the audit scope and key output highlights without unnecessary expansion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (account_id and max_users) having clear descriptions. The max_users schema even notes 'Each user costs one API call.' The tool description adds no extra parameter semantics beyond what the schema already provides, so it meets the baseline of 3.
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 performs a 'Read-only admin audit of account users and their app accesses' and highlights specific output focuses (privileged access, broad access, per-user fetch errors). This distinguishes it from other audit siblings by specifying the resource (account users and app accesses) and the audit nature.
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 it is for admin auditing of account user access, but it does not explicitly mention when to use it instead of alternatives, nor does it provide exclusionary guidance. It offers clear context without naming sibling tools like infomaniak_list_account_users or infomaniak_get_user_app_accesses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent; the description adds that it is an admin operation and specifies the aspects audited, providing useful behavioral context beyond what annotations offer.
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?
Single sentence, front-loaded with action and scope, no wasted 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?
The description, combined with the rich annotations and output schema, fully covers the tool's purpose and scope; no significant missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema with examples and a discovery reference, so the description adds no additional parameter semantics. Baseline of 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('audit') and resource ('mailbox security posture') and lists the exact areas covered (spam policy, sender conflicts, Sieve scripts, disabled filters), distinguishing it from related get/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the context as an admin-level read-only audit for mailbox security, implying when to use it. It does not explicitly mention alternatives or exclusions, but the context 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context by explaining the tool returns all records on the zone and that the input must be a root domain, not a subdomain. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The key action and example are front-loaded, and each sentence earns its place by defining scope and clarifying the required input format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter listing tool with a robust output schema and annotations covering safety and idempotency, the description adequately covers the essential context. It states what the tool lists, the required input type, and the constraint against subdomains, leaving no significant gap for an agent to misuse 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?
Schema description coverage is 100% and already describes the zone parameter as 'Zone (root domain), e.g. example.com'. The description reinforces the root-domain requirement but does not add substantive new parameter semantics beyond what the schema provides, 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 lists every DNS record on an Infomaniak-managed zone, using a specific verb ('List') and resource ('DNS record on a zone'). It distinguishes the tool from DNS mutation siblings like infomaniak_dns_create_record and infomaniak_dns_update_record by focusing on enumeration, and gives a concrete example.
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 the agent to use the root domain and explicitly warns against using a subdomain. It does not name alternative tools for exclusions, but the second sentence provides actionable guidance on how to invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructive and not read-only, but the description adds valuable behavioral context: 'Destructive two-phase commit with trash count guard; not undoable.' This explains the safety mechanism (two-phase commit, trash count guard) and explicitly states irreversibility, going well beyond the annotation hints. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence. It leads with the primary action, then adds critical safety caveats ('Destructive', 'two-phase commit', 'not undoable') without any filler. 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?
Given the tool's simplicity and the presence of an output schema, the description covers the core purpose, destructiveness, and irreversibility. However, it leaves the confirmation_token parameter somewhat ambiguous and does not state prerequisites beyond what the schema provides (drive_id discovery via list_drives). A slightly more explicit note about the two-phase commit flow would make it 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?
The description does not explain either parameter. Schema coverage is only 50% (drive_id has a description, but confirmation_token has none). While 'two-phase commit' hints at why a confirmation_token might exist, the description fails to explicitly connect it to the parameter or explain how to obtain/use it. With low schema coverage, the description should compensate, but it doesn't.
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 ('Empty') and resource ('entire kDrive trash'), clearly distinguishing it from sibling tools like infomaniak_empty_mailbox_trash (mailbox trash) and infomaniak_remove_drive_trash_item (individual items). The word 'entire' clarifies scope, 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 clearly communicates that this tool is for emptying the entire trash, implying it should be used when all trash items must be permanently removed. It does not explicitly mention alternatives or exclusionary conditions (e.g., 'use remove_drive_trash_item for individual items'), but the context of 'entire' and the sibling tool names make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint, so the description adds value by specifying what the snapshot covers (kSuite, drive, mailbox, kChat access) and that it is a 'current' snapshot. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and object, no redundant words. It earns its place by stating both what the tool does and its intended use context.
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 a 2-parameter schema, strong annotations, and an output schema present, the description provides enough context for correct selection and invocation. It covers purpose and when to use, and there are no hidden side effects due to readOnly/idempotent annotations.
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?
Both parameters are fully documented in the input schema (account_id and invitation_id with descriptions), and the description does not add parameter-level syntax or formatting beyond that. Schema coverage is 100%, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Inspect' to name the resource ('single account invitation and its current access snapshot') and clarifies the domain scope (kSuite, drive, mailbox, or kChat access). This clearly differentiates it from sibling mutation tools like infomaniak_manage_account_invitation_access.
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 'before granting or revoking... access' tells the agent when to call this tool—as a pre-mutation inspection step. However, it does not explicitly name an alternative tool for the actual granting/revoking, so it provides context but not an explicit exclusion/alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the manager-private API context and the specific data fields returned, which goes beyond the annotation-provided safety profile. No contradictions exist, though more detail on response behavior would have improved it.
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, front-loaded with the tool's purpose and full detail fields, followed by a distinguishing note about the sibling tool. Every sentence earns its place with no 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 a simple read-only tool with one parameter and an output schema, the description covers purpose, return content, use case, and access-level differentiation. It is sufficiently complete for an agent to select and invoke 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 single parameter drive_id is fully described in the input schema with a hint to discover via infomaniak_list_drives. The description adds no parameter-specific semantics, but since schema coverage is 100%, a 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 it retrieves full kDrive detail, listing specific fields (name, total size, used size, timestamps, maintenance flag) and explicitly distinguishes from infomaniak_list_drives by API access level. It identifies a specific verb and resource with concrete scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usefulness for storage usage monitoring and explicitly contrasts with infomaniak_list_drives (public Bearer API vs manager-private), offering clear guidance on when to use this tool. It doesn't exhaustively cover when not to use it, so it falls slightly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds a valuable behavioral detail: 'returns null when no share link exists.' This helps the agent anticipate an edge case not visible in the schema or annotations. It does not cover auth or rate limits, but for a read-only get with output schema, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that leads with the action and resource, then adds the key null-return behavior. Every word earns its place with 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?
For a simple read-only single-resource tool with full input schema coverage and an output schema, the description covers purpose, scope, and an important return-value edge case. There are no significant gaps that would impede tool selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full 100% coverage for both parameters, including drive_id discovery via infomaniak_list_drives. The description only reinforces the file/folder scope and adds no additional parameter syntax, format, or relationship details, 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 and resource: 'Get the share-link settings for one kDrive file or folder.' The word 'one' clearly distinguishes this from sibling tools like list_drive_share_links, while the read-only phrasing differentiates it from create/update/remove share-link tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for retrieving share-link settings for a single file or folder, and 'Read-only' signals this is a safe lookup. It does not explicitly mention alternatives or when-not-to-use, but the singular scoping provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds meaningful context about returned data (MX/SPF/DKIM/DMARC health check, quotas) and access restrictions, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the most important information, and every word adds value. The structure is efficient and scannable.
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 existence of an output schema and read-only annotations, the description adequately explains what the tool does, what it contains, and when to use it. No significant gaps are apparent for a simple one-parameter getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage; the parameter description explains what mail_hosting_id is and how to discover it. The tool description does not add parameter-specific details beyond the schema, 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 returns 'Full mail hosting detail' and enumerates specific content (diagnostic_dns, quotas, admin user, etc.), distinguishing it from list_mail_hostings and other mailbox-specific tools. The verb 'get' is implied by the name, and the resource scope is explicit.
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 ('Use this for mail-config sanity checks') and notes access level ('Manager-private'). It does not explicitly mention alternatives or when not to use, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description reinforces the read-only nature and adds 'admin' context, implying require permissions. It does not contradict annotations and provides some extra behavioral context, though it does not detail things like pagination or field inclusions. Given the output schema exists, 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?
The description is two short sentences that are front-loaded with the action ('List users') and immediately specify the resource and use case. There is no redundant information, and every word contributes to understanding the tool's purpose.
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 simplicity of the tool (one parameter, clear annotations, and an output schema), the description covers the essential aspects: what it does, its read-only nature, and its intended use. It is sufficiently complete for a straightforward list operation without needing to explain return values or complex behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, account_id, with a clear description: 'Infomaniak account/organization ID.' Schema description coverage is 100%. The tool description does not add additional parameter semantics beyond what the schema already provides, 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 a specific action and resource: 'List users attached to an Infomaniak account.' It distinguishes itself from sibling tools by focusing on users within an account, and the phrase 'Read-only admin inventory' adds a clear scope. This is a specific verb+resource combination that separates it from tools like listing organizations or account details.
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 for when to use the tool by stating it is an 'admin inventory for access review and offboarding.' This implies suitable scenarios but does not explicitly name alternatives or exclusions. While the use case is clear, a direct comparison to related tools (e.g., infomaniak_get_account_full) would improve the 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds the scope ('public catalogue') and mentions the chat endpoint, but does not disclose additional behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action ('List the public catalogue'), and includes examples and a use case without any fluff. Every sentence earns its place.
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 tool with an output schema, the description is complete: it states what is listed, gives examples, and explains why it's useful. No additional context is needed for selection or invocation.
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 details, which is appropriate given the empty 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 function: 'List the public catalogue of LLM/STT/embedding models hosted by Infomaniak' with specific examples. It distinguishes itself from sibling AI tools like infomaniak_list_ai_products and infomaniak_list_ai_product_models by focusing on the public catalogue of models.
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 to know what to target with the OpenAI-compatible chat endpoint.' It explains when to use the tool but does not explicitly mention alternatives or exclusions, though the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds detail about disk usage and running operations, which helps set expectations beyond the schema, but no additional behavioral traits like permissions or pagination are mentioned.
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 zero unnecessary words. It efficiently conveys the action, scope, and extra output details.
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 list operation with an output schema, the description fully covers the purpose and scope. The presence of an output schema means return values are already documented, so no additional detail is needed.
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 single parameter hosting_id is self-descriptive by name, and the description's phrase 'attached to a web hosting' clarifies its role. With 0% schema coverage, this context compensates well, though it does not explicitly state that hosting_id is the identifier for the web hosting.
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 ('every MariaDB database attached to a web hosting'), clearly distinguishing it from tools like get_database. It also adds useful context about disk usage and running operations.
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 this tool: to enumerate all databases under a given hosting_id. It does not explicitly mention alternatives or exclusions, but the scope is self-evident from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the operation's safety is known. The description adds value by disclosing the data structure: each user has its own password, a permissions array for databases, and WordPress users are marked protected: true. This goes beyond the annotations and helps the agent set expectations about the response.
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 exactly two sentences, front-loaded with the core purpose, and includes necessary nuance about passwords, permissions, and WordPress protection. Every sentence earns its place with no redundancy or filler.
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?
The tool is simple (one parameter), has rich annotations (read-only, open-world, idempotent), and an output schema exists. The description explains what the list contains and the special WordPress case, which is sufficient for an agent to invoke the tool correctly. No critical details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is hosting_id, which the schema defines as an integer. The description references 'web hosting' in the first sentence, making it inferable that hosting_id refers to that web hosting. However, there is no explicit mapping or guidance on how to obtain a valid hosting_id (e.g., from list_hostings). Given 0% schema description coverage, the description partially compensates but could be more explicit.
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: 'List the MariaDB-level user accounts attached to a web hosting.' The verb 'List' is specific, the resource is well-defined (MariaDB-level user accounts, distinct from hosting users), and it differentiates itself from sibling tools like infomaniak_list_hosting_users by explicitly noting 'MariaDB-level' and mentioning the permissions array and protected flag.
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: when you need database-level user accounts for a web hosting, each with its own password and permissions. It does not explicitly name alternatives, but the scope (MariaDB-level vs hosting-level) implicitly guides the agent away from or toward sibling tools. It also adds a WordPress-specific nuance that aids usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark read-only and idempotent; the description complements with 'Read-only admin inventory' and 'pending access grants,' clarifying the nature of the data. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and object. Every clause adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema and annotations covering safety, the description sufficiently scopes the tool. The admin inventory context and file/folder target make it actionable for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have clear descriptions, including how to discover drive_id. The description adds no additional parameter semantics beyond what is already 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?
The description clearly states the tool lists file-access invitations for a kDrive file or folder, distinguishing it from drive-level invitations and user/team access lists. The phrase 'Read-only admin inventory for pending access grants' adds operational scope and differentiates it from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the scope ('for a kDrive file or folder') and purpose ('pending access grants'), which implies when to use it. However, it does not explicitly name alternatives like list_drive_invitations or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, repeatable read operation. The description adds no additional behavioral traits beyond the 'List' verb, such as scope, pagination, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core action and purpose.
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 list tool with a read-only annotation and an output schema present, the one-sentence description is sufficient. It states exactly what the tool returns and the intended use case.
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 accepts zero parameters, so there is nothing for the description to explain. The schema covers 100% of parameters (none), and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the exact resource ('kChat roles') and adds the purpose ('permission auditing'). This clearly distinguishes it from sibling tools that list other kChat entities (channels, groups, bots).
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 'for permission auditing' provides a clear use case for when to invoke this tool. However, it does not explicitly mention when not to use it or name alternative tools for other kChat listing tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the scoping detail 'available to the current account,' and the annotations (readOnlyHint, openWorldHint, idempotentHint) already cover the safety and idempotency profile. It does not contradict annotations and provides a small amount of additional context, but no further behavioral details like pagination or output format are 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 a single, focused sentence with no filler, making it highly efficient and well-structured.
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, empty schema, and presence of an output schema, the description sufficiently covers purpose and scope. It does not need to explain return values, and the context is adequate for selection among siblings.
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% (no params to describe). The description adds no parameter-specific information, but with no parameters, the baseline 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 uses 'List' as a verb and specifies 'Public Cloud products available to the current account' as the resource, distinguishing it from sibling tools like list_public_cloud_projects and get_public_cloud.
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 via the resource scope but does not explicitly mention when to use it over alternatives or provide exclusions. Sibling tools are widely varied, and no direct comparison is 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond that: 'Manager-private' indicates access restrictions, and the explanation of FQDNs/vhost/DocumentRoot clarifies what the listing represents and why aliases matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core action, and each sentence earns its place: the first states what it lists, the second explains the technical context, and the third gives the practical use case. 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?
With a rich output schema, complete annotations, and two fully described parameters, the description fills remaining gaps: it explains the vhost/DocumentRoot relationship, notes manager-private access, and connects to WordPress/domain serving. This is a complete and self-sufficient description for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both site_id and hosting_id already well-described in the input schema ('Discover via infomaniak_find_site', etc.). The tool description adds no new parameter-level 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 opens with a specific verb and resource: 'List the FQDNs (main + aliases) bound to a web hosting site.' It clearly distinguishes this from sibling tools like infomaniak_list_sites by focusing on aliases/FQDNs rather than sites themselves, and even clarifies the relationship to add_site_aliases/delete_site_alias.
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 explains the aliases share the same Apache vhost/DocumentRoot and that adding an alias serves more domains from one WordPress install. It doesn't explicitly name alternatives or state when not to use it, but the use case is evident and well-scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds the 'Manager-private' access requirement (an auth constraint) and clarifies that both teams and tags are returned in a single call. This goes beyond the annotations by disclosing an access restriction and the combined nature of the response.
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: the first states capabilities, the second gives a use case, and the third notes the access restriction. Every sentence 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?
The description covers what the tool does, why it is useful, and who can use it (manager-private). With an output schema present, the return format is captured elsewhere. For a simple read-only list operation with a single parameter, this is fully 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?
There is only one parameter, account_id, with 0% schema description coverage. The description maps it to 'an organization', providing some interpretive context beyond the bare integer type, but it does not explicitly name the parameter or explain the relationship to the account_id field. For a single obvious parameter, this is adequate but minimal.
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 a specific action ('List') applied to two resources ('teams' and 'tags') with details on the contents (owners, user/product counts, products per tag), all scoped to 'an organization, in a single call'. This distinguishes it from any sibling tool, as no other tool combines teams and tags listing.
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 concrete use case: 'Both are useful to understand how an org partitions access and labels its products', and notes the access restriction 'Manager-private'. It does not explicitly compare to alternative tools, but no direct sibling offers this combined view, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, lowering the burden. The description adds useful context by disclosing the 'Manager-private' access requirement and that it returns billing and flags, which goes beyond annotation metadata. No contradiction.
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 highly concise: two sentences front-loaded with the action and resource, followed by a compact field list, a usage note, and an access flag. Every sentence contributes meaning without redundancy or unnecessary detail.
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 low-complexity list tool with one parameter and an output schema present, the description covers purpose, key return fields, when to use it relative to a sibling, and access context. There is no notable gap in what an agent needs to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter (account_id) is already well-documented in the schema with guidance to discover via infomaniak_list_organizations. The tool description adds no additional parameter semantics beyond what the schema provides, 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 lists VPS (Cloud Server, Jelastic-managed) products of an organization, enumerates specific return fields (id, customer_name, internal_name, etc.), and distinguishes itself from sibling infomaniak_get_vps_full by serving as the id-discovery step.
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 instructs to use this before `infomaniak_get_vps_full` to find the id of a specific server, providing clear context for when this tool is appropriate. However, it does not mention any exclusion cases or alternative listing tools, so it lacks a full when-not-to-use contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral details beyond annotations: the two-phase commit flow, plan + confirmation_token, TTL, and the read-only nature of check. It does not contradict the annotations, though it could have explicitly noted the destructive nature of enable/disable (which is only implied by 'remove DS record').
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 tightly written in three sentences, front-loading the core purpose and then providing the critical workflow and migration note. Every sentence earns its place without unnecessary verbosity.
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 three modes, a two-phase commit, and a migration note, the description is remarkably complete. The existence of an output schema covers return values, so the description focuses on the essential operational flow and legacy replacement, leaving no major gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters, so the schema already fully describes domain, action, and confirmation_token. The description adds minimal new parameter-level meaning beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 as unified DNSSEC management with three specific actions (check, enable, disable), each with an explicit verb and resource. It distinguishes itself from sibling tools by focusing on DNSSEC operations and noting it replaces the deprecated v0.9 trio.
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 strong usage context by explaining the two-phase commit for enable/disable and the 60-second confirmation_token TTL. It also gives explicit alternative guidance by naming the replaced trio (dnssec_check/enable/disable). However, it does not explicitly compare to other DNS record tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description reinforces and extends this with 'read-only' and 'does not revoke anything.' It also adds scope details ('from app accesses and invitations') and 'initial' (suggesting the plan is a first pass), which are useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose and scope, and the second reinforces the non-destructive nature. It is front-loaded, easy to parse, and contains zero filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, annotations are present, and the parameter schema fully documents the two simple integer inputs, the description is sufficiently complete. It clearly explains what the tool does, what it uses as input, and what it does not do, making it adequate for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (account_id and user_id) with clear integer descriptions. The tool description does not add additional param-level semantics, such as how to obtain these IDs or their relationship, 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 a specific verb ('Build') and resource ('a read-only initial offboarding plan for one account user') with a defined input scope ('from app accesses and invitations'). It also distinguishes itself from sibling tools that actually revoke or cancel access by explicitly noting it does not revoke anything.
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 for when to use this tool: when building a read-only initial offboarding plan from accesses and invitations. It also gives an explicit exclusion: 'This does not revoke anything,' which helps the agent avoid using it for actual revocation. However, it does not name specific alternative tools like cancel_user_pending_invitations or delete tools, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the two-phase commit behavior, which is crucial for correct invocation and goes beyond what annotations provide. With destructiveHint=true and readOnlyHint=false already set, the description adds the state-changing nature and the confirmation token requirement. It doesn't mention irreversibility or specific side effects, but the two-phase protocol is substantial added 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?
Three short sentences, each adding distinct value: purpose, process, and prerequisite. No fluff or repetition of schema fields. The description is front-loaded with the core purpose and remains highly readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full parameter documentation, the description covers purpose, process, and precondition adequately. The two-phase commit workflow is hinted but not fully detailed (e.g., how to obtain the confirmation_token), but the schema's token description and output schema likely fill this gap. Complete enough for tool selection and basic invocation.
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 covers both parameters with clear descriptions (100% coverage), so the baseline is 3. The description adds context for the 'confirmation_token' by mentioning 'two-phase commit', which clarifies why the token is needed. This goes slightly beyond the schema's note about 'apply phase' and provides workflow context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('short URL') with a clear target ('long target'). It distinguishes itself from siblings like infomaniak_list_short_urls and infomaniak_short_urls_quota by indicating it creates rather than lists or checks quota. The 'Two-phase commit' adds process clarity.
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 explicit guidance to check quota with infomaniak_short_urls_quota when uncertain about headroom, which is a helpful prerequisite. It doesn't explicitly contrast with alternative create or list tools, but the create purpose is self-evident. Missing an explicit 'when not to use' or alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing the authentication requirement (SASESSION + CSRF cookies) and the 'Manager-private' restriction, which are behavioral constraints beyond the schema. It also enumerates the returned configuration fields, providing transparency about what will be fetched. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences. The first sentence fronts the purpose and enumerates the key data fields; the second provides access requirements. Zero filler, every word earns its place. The list of fields is dense but structured as a comma-separated enumeration that sets expectations for the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema is present, the description needn't explain return values, and it doesn't. It covers the tool's purpose, the resource type, key configuration fields, and access requirements. The access/auth caveat is important for an agent to invoke it correctly. An explicit pointer to list_nodejs_apps for discovery is present via the parameter description. It could mention relationship to nodejs_app_status or nodejs_app_aliases, but those are less relevant to a 'get full configuration' operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented well. The description adds crucial cross-referencing for vhost_route_id: 'Also called feature_id in some responses' and 'get it from infomaniak_list_nodejs_apps', which helps resolve the known ID naming ambiguity. hosting_id is straightforward but the cross-resource guidance is valuable. This goes beyond the baseline 3.
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 full configuration') and identifies the exact resource ('Node.js application') with a list of concrete details (Node version, listen port, SSL status, IPs, etc.). It also distinguishes itself from sibling tools like infomaniak_list_nodejs_apps (list vs. get) and infomaniak_nodejs_app_status by targeting full configuration rather than status or aliases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes 'Manager-private — requires SASESSION + CSRF cookies,' giving clear access context. The sibling tool name infomaniak_list_nodejs_apps is referenced in the parameter description ('get it from infomaniak_list_nodejs_apps'), providing a retrieval path. However, it doesn't explicitly state when NOT to use this tool or contrast it with alternatives like status/logs/aliases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'Manager-private' (a visibility/authorization caveat) and a detailed list of returned fields, but it does not discuss rate limits, errors, or pagination behavior. Given the existing annotations, this is solid supplementary context.
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 front-loaded with the core purpose, then gives a detailed but efficient enumeration of fields, followed by concise usage guidance. Every item in the list carries information, though the long comma-separated list makes it slightly dense; still, there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to describe return values. It fully explains the tool's scope, the information provided, the prerequisite list operation, and an access restriction. For a one-parameter read-only detail tool, this is contextually 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 schema already documents `vps_id` with 100% coverage, including the instruction to discover it via `infomaniak_list_vps`. The tool description reinforces the sequencing but does not add new parameter semantics beyond what the schema provides, 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 opens with 'Full VPS / Cloud Server detail' and enumerates the specific data returned, making the verb+resource+scope clear. It also distinguishes itself from the sibling `infomaniak_list_vps` by framing itself as the drill-down companion tool.
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 'Use after `infomaniak_list_vps` to drill into one server,' giving a clear when-to-use instruction and relationship to a sibling. The 'Manager-private' note adds an access-role restriction, which further clarifies appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=false and idempotentHint=false, so the agent knows it's a mutating, non-idempotent action. The description adds value by disclosing the 'two-phase commit with current share-link guard,' which is a meaningful behavioral trait not present in the annotations—it indicates the operation involves multiple steps and has stale-link protection.
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, information-dense sentence. It front-loads the primary action, includes the relevant endpoint, and conveys the key two-phase behavior without any 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 multi-step mutation with an output schema, the description covers the core purpose and the important guard. However, it doesn't describe the exact sequence of the two-phase commit, how the confirmation token is obtained, or what happens if the guard fails, so it's not fully complete for an agent that may need to handle those steps.
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 describes drive_id, file_id, and invitation (75% coverage). The description adds crucial context to the undocumented confirmation_token by implying it is part of the two-phase commit flow, helping the agent understand when and why to provide it. The endpoint in the description also reinforces how drive_id and file_id connect.
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 names the operation ('Invite recipients to a kDrive share link') and specifies the exact REST endpoint, making it unambiguous and distinctly different from sibling share-link tools (create, update, remove). It also introduces the 'two-phase commit' nuance, which 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: this tool invites recipients to an existing kDrive share link. While it doesn't explicitly say 'use this instead of X' or list exclusions, the 'current share-link guard' implies it requires an existing share link, and the sibling tool set makes the alternative actions obvious.
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?
Beyond annotations (readOnlyHint=false, idempotentHint=true), the description reveals a two-phase commit workflow and a current-user guard, adding behavioral context not present in annotations. It does not detail the exact commit flow or error cases, but the added traits are valuable.
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 compact sentences, front-loaded with action and resource, then a critical behavioral note. No redundant wording; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and sibling tools, the description adequately covers the core purpose and the two-phase commit hint. It could elaborate on how to initiate and complete the two-phase process, but it is sufficient for an agent to likely infer the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 3 of 4 parameters; confirmation_token is undocumented. The description's 'Two-phase commit' phrase indirectly clarifies that confirmation_token is for the second phase, adding meaning absent from the schema. This partially compensates for the missing parameter description.
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?
States a specific action ('Set or remove kDrive manager rights') on a specific resource (a kDrive user), and names the exact PATCH endpoint. This distinguishes it from sibling tools like update_drive_user or delete_drive_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'Two-phase commit with current user guard,' which signals important usage context (likely needing confirmation_token and guarding against self-demotion). However, it does not explicitly name alternatives or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the existing annotations (destructive, idempotent, non-read-only) by revealing the two-phase commit workflow, the PATCH operation, and the conditional application. This is crucial behavioral context that an agent would need to invoke the tool correctly.
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 core action front-loaded and the two-phase commit explained succinctly. Every word earns its place and it does not repeat annotation or schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a two-phase commit that is also destructive, the description explains the essential workflow, the state check condition, and the existence of a diff/token. The output schema presumably covers return details, and annotations cover safety, making this description complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive descriptions for all four parameters (100% schema description coverage). The description adds a bit of context by explaining the confirmation_token's role in the two-phase flow, but it does not add meaning for the other parameters beyond what the schema already states.
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 'Block this sender.' which clearly states the action and resource. The second sentence provides further context by describing the two-phase commit against the mailbox sender lists, distinguishing it from sibling tools like unblock_sender and authorize_sender.
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 two-phase commit protocol is clearly explained: first call returns a diff and confirmation token, second call applies the PATCH only if the lists have not changed. This gives concrete usage steps and a condition for applying. However, it does not explicitly mention alternatives or when to use this over unblock/authorize tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructive and idempotent hints, but the description adds critical context: two-phase commit, confirmation token, and fresh prefetch to only delete still-pending invitations. This goes beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then process. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The two-phase commit is a complex behavior, and the description succinctly explains both phases. Output schema exists, so return values need not be described. Annotations cover safety. The description is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all params with descriptions; the description adds meaning by explaining the token's role in the second phase and the flow from first to second call. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel pending account invitations for a user' with a specific verb and resource, and the two-phase commit detail distinguishes it from simpler invitation management 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 explains the two-step process but does not explicitly state when to use this tool over alternatives like infomaniak_manage_account_invitation_access or infomaniak_delete_account_invitation. Usage is implied for cancelling a user's pending invitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: two-phase commit (requires a plan+apply flow) and the fact that going through the private API is required because the public API silently fails. This goes well beyond the readOnly/destructive hints.
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 purpose, and every sentence provides unique, non-redundant information. The warning about the public API is concise and highly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be described. The description covers the critical non-obvious aspects (two-phase commit, private API) and is sufficiently complete for an agent to invoke the tool correctly. The schema covers parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents all parameters thoroughly (100% coverage), including the confirmation_token's role in the apply phase and the naming rules. The description mentions two-phase commit but does not add new parameter-level details 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 'Create a new MariaDB database on a web hosting' with a specific verb and resource. It also mentions the two-phase commit behavior and the private API, distinguishing it from sibling tools like list_databases or delete_database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by stating it creates a database and warns that the public API silently no-ops, making this private-API tool necessary. It does not explicitly state alternatives or when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by specifying the exact destructive impact ('database content (tables, rows) is wiped') and irreversibility ('cannot be recovered without an Infomaniak backup'). It also discloses the two-phase commit behavior, adding meaningful context to the destructiveHint and readOnlyHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences) and front-loaded with the purpose, followed by the critical warning. Every word adds value: the action, the two-phase process, the access restriction, and the destructive consequence.
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 complexity (two-phase commit, destructive, three parameters), the description covers all necessary aspects: the process, the warning, and the access requirement. An output schema exists, so return values need not be explained. The description is complete for an agent to decide when and how to invoke the 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 already provides 100% coverage with detailed descriptions for all three parameters, including guidance on discovering hosting_id and the correct format for database_name. The description adds little beyond the schema, just mentioning two-phase commit which is already reflected in the confirmation_token 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 action with a specific verb ('Delete') and resource ('MariaDB database'). It distinguishes this tool from sibling delete tools like delete_site or delete_mailbox by specifying the exact resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context for usage: 'Two-phase commit' informs the agent that a two-step confirmation process is required, and 'manager-private API' indicates restricted access. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it falls 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it discloses the two-phase commit nature and explicitly states 'Existing files are not deleted,' which is crucial for a destructive action. This goes beyond the basic readOnlyHint=false and destructiveHint=true annotations, giving the agent a clear picture of side effects and safety boundaries.
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: three short sentences, each carrying essential information. The main action is front-loaded in the first sentence, followed by critical behavioral notes. No unnecessary words or repetition, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% param coverage), output schema presence, and annotations covering destructive/idempotent/readOnly hints, the description fills remaining gaps: the two-phase commit workflow and file preservation. It provides enough context for an agent to select and correctly invoke the tool, including understanding the need for a token and the non-destructive nature regarding files.
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 itself does not add parameter-level details; all parameter semantics are already in the schema (e.g., confirmation_token purpose, login format). The description's mention of two-phase commit relates to the confirmation_token but is already elaborated in the schema, so no additional value beyond the structured fields.
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: 'Revoke a hosting user (FTP / SSH access).' This is a specific verb and resource, and it distinguishes from siblings like infomaniak_create_hosting_user and infomaniak_list_hosting_users. It also adds the key nuance of two-phase commit and file preservation, clarifying the scope of the action.
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 usage context (revoking access) and even hints at the two-phase commit procedure. However, it does not explicitly name alternatives or when not to use this tool, such as pointing to infomaniak_create_hosting_user for creating users. The two-phase commit is mentioned in the description but fully detailed in the schema, which slightly reduces the guidance value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description discloses that deletion also 'wipes the site directory on the FTP backend after a short grace period' and that the first call is a non-destructive preview. This is significant behavioral context not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and efficiently adds essential procedure and warning without padding.
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?
Despite being a destructive, two-phase operation, the description covers the action, the phase flow, and the consequence (directory wipe with grace period). Output schema exists, so return values need not be described. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions for all three parameters are already detailed (e.g., confirmation_token explains phase usage). The tool description repeats the token flow but adds no new parameter-level semantics, so it relies on schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Delete a site from an Infomaniak web hosting.' It also clarifies the two-phase commit nature, distinguishing it from single-call tools like infomaniak_delete_site_alias or infomaniak_delete_database.
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 explains the two-phase procedure: first call returns a plan with token, second call with same params + token performs the delete. This gives clear when-to-call context. It does not explicitly name alternative tools or exclusion criteria, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false; the description adds the critical two-phase commit behavior, explaining that the first call plans and the second with token actually creates. This is valuable beyond structured fields.
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, second explains the phased behavior. Zero 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 non-idempotent, mutating tool with a two-phase protocol, the description captures the essential workflow. The zone prerequisite is mentioned in the description and reinforced in schema; output format is covered by output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with rich descriptions. Description adds the cross-phase constraint that all params must be identical except the token, which clarifies how confirmation_token interacts with other 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?
Description uses specific verb 'Create' with resource 'DNS record' and scope 'Infomaniak-managed zone'. The two-phase commit detail distinguishes this create tool from update/delete/list siblings.
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: use to create a DNS record on a managed zone, and outlines the two-phase procedure. Does not name sibling alternatives explicitly, but the verb and resource make the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a crucial behavioral trait: the two-phase commit process. It explains that the first call previews changes and returns a token, while the second call applies them. This goes well beyond the annotations (which only indicate readOnly=false, destructive=true, idempotent=true) and adds critical context for the agent to understand the tool's state-changing workflow.
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 exceptionally concise: two sentences, front-loaded with the tool's purpose, followed by the two-phase mechanism. Every word earns its place with no redundancy or filler.
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 mutation tool with two-phase commit, 7 parameters, and an output schema, the description captures the essential workflow and the meaning of the confirmation_token. The existence of an output schema covers return values, and the required parameters (zone, record_id) are self-evident from the schema. The explanation is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain the confirmation_token's role by mentioning 'same params + token' in the two-phase commit, which is valuable. However, other parameters (ttl, type, source, target) are not elaborated; the description only generically says 'one or more fields' rather than listing them. This is adequate but not comprehensive.
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 precisely: 'Update one or more fields of a DNS record.' This clearly identifies the tool's purpose with a specific verb and resource, and distinguishes it from sibling tools like infomaniak_dns_create_record and infomaniak_dns_delete_record. The mention of 'one or more fields' adds scope.
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 conveys clear usage context: it is for updating existing DNS records, and the two-phase commit explains the process. However, it does not explicitly name alternatives or state when not to use it, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which covers the safety profile. The description adds valuable behavioral context beyond that: it returns a specific ID set and the full site object, and it 'short-circuits on the first match,' explaining the performance behavior. It does not disclose edge cases like no-match behavior, but it is transparent enough given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the core purpose and return value, then provides usage guidance and performance rationale. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the input schema is fully described, the description covers the remaining context: when to use the tool, what it returns, and how it compares to alternatives. It is complete 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 baseline is 3. The description adds the high-level purpose and return fields, but the parameter semantics (domain type, optional account_id restriction) are already documented in the schema. No additional meaning is provided that is not in the input 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 and resource: 'Locate a domain (e.g. broz.be) in the Infomaniak account tree.' It clearly states what it returns and explicitly distinguishes itself from sibling tools by positioning it as a prerequisite for tools requiring hosting_id and site_id, and by contrasting it with the more expensive list_hostings + list_sites approach.
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 gives explicit usage guidance: 'Use this BEFORE any tool that requires hosting_id + site_id ... when you only know the domain name.' It also names the alternative (calling list_hostings + list_sites) and explains the efficiency advantage, making the right invocation context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond those: it reveals that the tool acts on the currently authenticated user/account, requires the SASESSION cookie, and is manager-private, plus what current_account_id means. This enriches transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the core purpose and then pack useful details (returned fields, usage guidance, auth requirement) into tight phrasing. No filler or redundancy; every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to enumerate return types. It covers the purpose, usage context, and auth prerequisite, making it complete for a zero-parameter identity tool with strong annotations.
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 and 100% schema coverage, so the baseline is 4. The description has no parameter semantics to add because there are none; it instead describes the rich output surface, which is appropriate for a no-arg profile tool.
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: 'Get the identity of the currently-authenticated Infomaniak user.' It enumerates returned fields (name, email, language, country, timezone, current_account_id, security posture) and explicitly frames its role as confirming which user/account the MCP acts on behalf of, distinguishing it from sibling tools like get_my_security or list_organizations.
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 an explicit usage directive: 'Use this first to confirm which user + account the MCP is acting on behalf of.' It also states a prerequisite (requires SASESSION cookie, manager-private). It does not discuss when not to use or name alternatives, so it stops short of full exclusion 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?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by specifying the exact fields covered and noting it is 'Manager-private,' which conveys an access constraint. This is appropriate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses a compact list to convey the detailed output. Every sentence earns its place: the first explains what it returns, the second gives usage scenarios and access scope. No filler.
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 with an output schema, the description provides sufficient context. It clarifies the scope (current user), the content (comprehensive security fields), and appropriate usage. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by definition. The baseline for no parameters is 4, and the description does not need to explain parameters. It adds no parameter-specific details, which is fine.
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 and specifically states what the tool does: it provides a security posture report for the current user, listing concrete data points (2FA, recovery email, trusted devices, etc.). This distinguishes it from sibling tools like get_my_profile or audit_account by scoping to security-specific current-user data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly suggests usage as 'a periodic security review or pre-action sanity check,' giving clear context. However, it does not name alternative tools or describe when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds behavioral context by explaining that an empty result signifies no active AI subscription and includes a direct subscription URL. This goes beyond the schema and annotations, providing meaningful interpretive guidance.
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 only two sentences, with the action front-loaded in the first sentence and a useful conditional next step in the second. Every word adds value; no fluff 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 parameterless list tool with annotations and an output schema, the description is complete. It covers what the tool returns, how to interpret an empty result, and the follow-up action. No additional details about return format are necessary given the output schema exists.
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 correctly omits param details as there are none. No further semantic explanation 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's function: 'List the Infomaniak AI products the account owns.' This is a specific verb+resource combination that distinguishes it from sibling tools like list_ai_models and list_ai_product_models. It also provides additional meaning about the result interpretation, making the purpose unmistakable.
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 includes clear context on when to use the tool: to check which AI products are owned, and what to do if the list is empty (subscribe via the provided link). However, it does not explicitly contrast with alternatives like list_ai_models or list_ai_product_models, so it misses the 'when-not-to-use' aspect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds valuable context beyond annotations by specifying that the listing is limited to organizations the token has 'technical access to', clarifying the scope of 'all'. This is meaningful additional behavioral insight, though it doesn't mention pagination or rate limits. With annotations carrying the bulk of the safety profile, a 4 is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function and scope. No unnecessary words or repeated information. It is ideal in size and front-loaded with the verb and resource.
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 listing tool with comprehensive annotations (readOnly, openWorld, idempotent) and an output schema, the description is complete. It clearly states what is listed and the access scope. The openWorldHint covers potential pagination, and the output schema handles return values. No gaps remain.
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 for the description to explain. Per the rubric, 0 params gives a baseline of 4. The description appropriately focuses on the tool's purpose and scope rather than 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's function: 'Lists all Infomaniak organizations (accounts) the current token has technical access to.' It uses a specific verb ('Lists') and resource ('organizations/accounts'), and adds a scope qualifier ('current token has technical access to') that distinguishes it from other listing tools that might list different resource types.
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 the tool: to list all organizations accessible by the current token. It doesn't explicitly mention alternatives or exclusions, but for a simple listing tool with no parameters, the context is sufficiently clear. A score of 4 is appropriate: clear context, no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint and readOnlyHint: false, but the description adds essential behavioral detail beyond those flags: the two-phase commit protocol, the downtime implication of stop, and the side effect of build triggering a job with a tailable log_stream. It also notes the manager-private restriction, enriching the agent's understanding of access and consequences.
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 dense sentences, front-loaded with the core verb+resource, then efficiently adds the high-stakes workflow details. Every sentence contributes critical information—actions, two-phase flow, downtime warning, build/log_stream behavior, and access scope—with no filler or repetition.
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 complexity (two-phase commit, multiple actions, destructive stop, build side effects) and the availability of an output schema, the description covers everything an agent needs to select and invoke it correctly: what action to take, the required plan/apply sequence, downtime consequences, and log_stream availability. The action enum in the schema fills in remaining per-action details like 'graceful restart' and 'runs build_command', so the description is complete enough for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description partially compensates by explaining the confirmation_token workflow (first call returns plan + token, second call requires token + same args) and the action's lifecycle meaning. However, the description does not clarify hosting_id or vhost_route_id, leaving those required identifiers dependent on their self-explanatory names rather than any added semantic guidance.
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 'Start, stop, restart, or build a Node.js application,' a specific action verb plus resource that clearly distinguishes this from sibling tools like list/get/status. It also names the exact operation set and key behaviors (two-phase commit, log_stream), 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 gives clear usage context: it explains the two-phase commit flow, warns that stop causes downtime, and notes that build returns a log_stream. It does not explicitly compare against sibling read/status tools, but the action-oriented framing and lifecycle guidance make appropriate use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: it discloses the return format (base64 JPEG data URL), the caching behavior with `refresh=true`, and the access restriction ('Manager-private'). Annotations already mark it read-only and idempotent, so this additional context is valuable and does not contradict them.
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 long, front-loaded with the primary action, and includes only essential information: purpose, use case, and refresh parameter behavior. Every sentence adds value with no redundant phrasing.
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?
The description covers the tool's purpose, output format, caching behavior, and access restriction. With an output schema present and simple parameters (no nested objects), this is sufficiently complete for an agent to invoke the tool correctly. The low parameter description coverage is mitigated by the tool's straightforward nature.
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 covers only `refresh` with a description; `hosting_id` and `vhost_route_id` lack descriptions. The tool description mentions the app but does not clarify these required identifiers. However, their names are fairly self-explanatory in the Infomaniak context, and `refresh` behavior is well-described in both the schema and description, providing some compensation for the low 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 a screenshot of the running Node.js app as a base64 JPEG data URL.' This is a specific verb+resource combination that uniquely distinguishes it from sibling tools like infomaniak_nodejs_app_logs or infomaniak_nodejs_app_status. No ambiguity.
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 for when to use it: 'Useful to visually confirm the app is alive without HTTP-probing.' It also explains the `refresh` parameter use case. However, it does not explicitly list alternatives or exclusions, though the context implies it is distinct from other Node.js tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining the two-phase commit behavior and the optimistic concurrency condition ('if the mailbox sender lists have not changed'). This is critical for safe invocation, especially given destructiveHint=true. No contradiction with annotations; it complements them substantially.
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 that leads with the core purpose ('Remove this authorized sender') and then efficiently packs the entire two-phase commit mechanism. No filler or redundancy; every clause earns its place.
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?
The description explains both phases of the operation, the requirement for confirmation_token, and the safety condition on the apply phase. Combined with the existing output schema and thorough parameter descriptions, it fully equips an agent to invoke the tool correctly across both calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: every parameter has a rich description in the schema (e.g., mailbox_name format, mail_hosting_id discovery, confirmation_token necessity). The tool description itself does not add parameter details, but the schema already handles this. 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 primary action: 'Remove this authorized sender.' It names the specific resource (authorized sender in mailbox sender lists) and the verb (remove), and the two-phase commit detail distinguishes it from simpler tools like block/unblock. It is much more specific than a generic 'unauthorize'.
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 context on how to use the tool (two-phase commit sequence) but does not explicitly mention alternatives such as infomaniak_authorize_sender or infomaniak_block_sender. The name and wording imply when to use it, but no exclusions are stated. This qualifies as 'clear context, no exclusions,' so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark destructiveHint=true and idempotentHint=false; the description discloses the two-phase commit workflow, confirmation token, and inventory check, which are critical behavioral traits beyond the annotations. This is valuable context for the 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?
Two sentences, no filler. Front-loads the purpose and immediately follows with the essential workflow.
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?
Combined with the input schema (which provides parameter details and discovery pointers) and output schema, the description sufficiently explains the tool's complexity. The two-phase mechanism is fully described, though it doesn't specify error handling or prerequisites beyond the schema.
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 covers 86% of parameters with descriptions. The description adds crucial semantics for confirmation_token by explaining it's returned from the first call and used in the second call, which the schema lacks. This adds beyond 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 begins with 'Create a mailbox Sieve filter' – a specific verb and resource, clearly distinguishing it from sibling tools like update/delete/list filters. The two-phase commit detail further clarifies the tool's specific behavior.
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 procedural guidance on how to use the tool (two-phase commit, token and inventory check), but does not explicitly compare with alternatives like upsert_mailbox_filter_script or update_mailbox_filter. Since it gives context but no exclusions, score 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive=true, but the description adds context about a two-phase commit, a trashed-item guard, and irreversibility, which are not conveyed by the structured fields. This supplements rather than contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action and packs in critical caveats without 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?
The tool involves a destructive, two-phase operation, but the description covers the key risks, scope, and guard. The presence of an output schema and strong annotations fills in return-value and safety details, so the description is sufficient for a competent agent, though it could elaborate on the confirmation_token flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover file_id and drive_id with meaningful context, and the description's 'two-phase commit' hints at the purpose of the confirmation_token parameter, which lacks a schema description. This adds value beyond the raw schema, though it stops short of explaining the token's exact role.
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 ('permanently remove') and resource ('one file or folder from kDrive trash'), clearly differentiating from siblings like infomaniak_empty_drive_trash and infomaniak_restore_drive_trash_item.
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 makes the single-item scope explicit and adds the warning 'not undoable,' which implies this is only for intended deletions rather than restore/empty alternatives. However, it does not explicitly name alternatives or exclusions, so usage guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, destructive=true), the description adds critical behavioral details: the two-phase commit, current-state diff, confirmation token, and the conditional application ('if the mailbox sender lists have not changed'). This is rich and consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, then the two-phase detail. 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 complex tool with a two-phase commit, the description fully explains the protocol, and with an output schema present, it need not detail return values. It covers the essential context without unnecessary elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning to the confirmation_token parameter by explaining it is used in the second call to apply the PATCH, which goes beyond the schema's basic description.
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 action ('Authorize this sender') and explains the two-phase commit mechanism, clearly distinguishing it from sibling tools like block_sender or unauthorize_sender by mentioning the PATCH and mailbox sender lists.
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 two-phase call sequence is explicitly described ('first call returns... second call with the token applies...'), providing clear usage context. However, it does not mention alternatives or when not to use this tool, so it misses the full 'when/when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, etc.), the description reveals significant behavioral context: it is a manager-private endpoint requiring SASESSION + CSRF cookies, it typically returns one entry because each hosting runs a single app, and it returns vhost_route_id and FQDNs. These details are not present in the annotations and materially affect invocation and output 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 three sentences, front-loaded with the core purpose, then key behavioral nuances (typical single result, return value, auth requirement). Every sentence earns its place, and there is no filler or redundant restatement of the tool name or schema.
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 list tool with one parameter and an output schema, the description is fully complete. It covers purpose, typical cardinality, the critical return value (vhost_route_id), and the authentication requirement. An agent has sufficient context to select and invoke this tool correctly without further clarification.
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, describing hosting_id as 'Node.js hosting id (service_id 57)' with an exclusive minimum. The description does not add further meaning to the parameter itself, so a baseline score of 3 is appropriate—the schema does the heavy lifting and the description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List Node.js applications running on a hosting_3 container.' It clearly states the tool's scope and differentiates it from sibling tools by noting it returns the vhost_route_id needed for every other Node.js tool. The purpose is immediately obvious 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions this tool as a prerequisite for all other Node.js tools by stating it returns the vhost_route_id needed for them. It also provides an important usage condition—auth mode (INFOMANIAK_AUTH_MODE=auto) for the manager-private endpoint. This gives the agent clear guidance on when and how to invoke it.
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:

[![infomaniak-admin-mcp MCP server](https://glama.ai/mcp/servers/henrikogaard/infomaniak-admin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/henrikogaard/infomaniak-admin-mcp)

Score Badge

Copy to your README.md:

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

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