infomaniak-mcp-agent

Server Quality Checklist

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

Latest release: v0.14.5
Disambiguation5/5
All 51 tools have clearly distinct purposes with detailed descriptions. There is no ambiguity between tools; even the escape hatch is explicitly distinguished from typed tools.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern with the 'infomaniak_' prefix and snake_case. Even utility tools like infomaniak_explain and infomaniak_help adhere to the convention.
Tool Count4/5
51 tools is high but appropriate for a server that covers the full Infomaniak platform (hosting, mail, DNS, databases, AI, kDrive, etc.). The count is justified by the breadth of services, though slightly above typical single-domain servers.
Completeness4/5
The tool set provides comprehensive CRUD coverage for most entities (sites, databases, mailboxes, DNS records). Notable gaps exist (e.g., no update for hosting users or mailboxes), but the escape hatch and broad coverage mitigate this.
Average 4.1/5 across 51 of 51 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on July 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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.
View related servers

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely says 'list', adding no behavioral information beyond what the annotations (readOnlyHint, idempotentHint) already provide. No mention of scope, pagination, or performance implications.
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 sentence, which is concise but overly minimal, missing key contextual information about the parameter and usage. It is not front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and an output schema, so the description is minimally adequate. However, it could be improved by linking to related tools (e.g., list_mail_hostings) and explaining the parameter's purpose.
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% (no description for the required mail_hosting_id parameter), and the tool description does not explain what this parameter represents, its format, or how to obtain it, providing no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'list' and the resource 'every mailbox on a given mail hosting', distinguishing it from sibling tools like infomaniak_get_mailbox_info which targets a single mailbox, and infomaniak_create_mailbox for creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., needing a mail_hosting_id from list_mail_hostings), and no context on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns primary FQDN and preview URL, and notes 'Manager-private' – an access restriction not in annotations. This is useful but limited. 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?
Two sentences, concise and front-loaded with the main purpose. No redundancy, but could include parameter explanations. Still, it's efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (mentioned in context) and annotations covering safety, the description adds return value details and access hint. However, the complete lack of parameter documentation leaves a gap. For a simple read tool it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has two required integer parameters (hosting_id, vhost_route_id) with 0% description coverage in schema. The description does not explain their meaning or purpose, forcing the agent to infer. This severely hinders correct invocation.
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 verb 'List' and the resource 'FQDNs serving a Node.js application'. It specifies the output includes primary FQDN and preview URL. However, it doesn't explicitly differentiate from similar sibling tools like 'infomaniak_list_site_aliases', which might list aliases for sites generally vs Node.js apps. The purpose is mostly clear but 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., infomaniak_list_site_aliases or other Node.js app tools). There are no when-not or context cues. The 'Manager-private' remark hints at restricted access but doesn't guide usage.
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 provide readOnlyHint and idempotentHint, indicating safe, repeatable behavior. The description adds that it lists rules, but does not elaborate on scope or behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and existing output schema, the description is adequate but lacks details about usage context and parameter meaning, which would enhance 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?
Schema description coverage is 0%, and the description does not explain the single parameter mail_hosting_id. No additional meaning is provided beyond the type and 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 clearly states the tool lists 'every server-side redirection rule on a mail hosting', using a specific verb and resource. It distinguishes itself from siblings like infomaniak_create_redirection and infomaniak_delete_redirection.
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, such as prerequisites (e.g., need a mail_hosting_id) or context compared to related tools. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world behavior. The description adds 'with applications attached,' which provides extra context. However, it does not disclose pagination, ordering, or potential incompleteness beyond the openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that efficiently conveys the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown), the description need not detail return values. However, it lacks information on pagination or sorting, and the open-world hint suggests results may be incomplete, which is not mentioned.
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 provides no explanation of the hosting_id parameter (e.g., how to find it, format, or constraints). The description only says 'given web hosting,' which is vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 lists all sites on a given web hosting, and specifies that applications are attached. This distinguishes it from sibling tools like infomaniak_create_site and infomaniak_find_site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs other list/find tools (e.g., infomaniak_find_site, infomaniak_list_hostings). The description implies needing a hosting_id, but does not explain how to obtain it or when to choose this over alternatives.
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, openWorldHint. Description adds value by listing specific fields returned and noting 'Manager-private' access restriction, which goes beyond what annotations provide. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single verbose sentence listing many fields; it is adequately concise but could be more structured (e.g., bullet list) for easier scanning. 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 existence of an output schema, the description sufficiently covers the tool's return content and access context. It explains what fields are included and mentions use cases, but does not address relationship with similar 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 coverage is 50% (only mailbox_name has a description). The description does not add any parameter documentation beyond the schema, leaving the mail_hosting_id parameter undocumented.
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?
Description clearly states it returns 'Full mailbox detail' and lists many specific fields, distinguishing it from the sibling 'infomaniak_get_mailbox_info' by name and scope. However, it does not explicitly contrast with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides usage context ('useful for mailbox audits and onboarding flows'), but does not explicitly state when not to use it or mention alternatives like get_mailbox_info for basic queries.
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 a destructive write (destructiveHint=true, readOnlyHint=false). The description adds behavioral context by mentioning 'two-phase commit' (implying a multi-step process) and that the alias receives emails. However, it does not explain the two-phase mechanism or what the confirmation token is for.
Agents need to know what a tool does to the world before 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 ('Add a new alias to an existing mailbox'), and contains no unnecessary 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?
Given the two-phase commit complexity and 4 parameters, the description is incomplete. The two-phase process is not explained, the confirmation_token parameter is not described, and there is no guidance on the return value (though an output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It mentions 'alias' but does not explain the parameters mail_hosting_id, mailbox_name, alias, or confirmation_token. The token's role in the two-phase commit is hinted but not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 a new alias to an existing mailbox') and distinguishes it from sibling tools like infomaniak_create_mailbox (creates mailbox, not alias) and infomaniak_list_mailboxes (list, not create). The mention of '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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a two-phase process but does not explicitly state when to use this tool, prerequisites (e.g., mailbox must exist), or when not to use it. There is no comparison to alternatives like infomaniak_create_redirection.
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. The description adds that URLs are scoped to 'your account', providing some behavioral context. However, it does not disclose pagination behavior or result format, relying on schema and output 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 a single, front-loaded sentence that efficiently conveys the purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, presence of annotations, and existence of output schema, the description is mostly complete. It covers the core functionality, though it could mention pagination explicitly.
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 description does not explain the two parameters (page, per_page) at all. With schema coverage at 0%, the description should compensate but fails to provide any parameter semantics, leaving the agent to infer from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 short URLs created by the user's account on Infomaniak's url-shortener service, using a specific verb and resource that distinguishes it from other list tools 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 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 to view short URLs, but provides no explicit when-to-use, when-not-to-use, or alternative tools. Since no other sibling tool lists short URLs, the 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds useful behavioral context: JWT-protected log_stream endpoints and Manager-private access, which are not conveyed by annotations. 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?
Description is a single sentence that efficiently conveys the tool's purpose, scope, key output features, and access context. 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?
Despite having an output schema (not shown), the description fails to document parameter semantics, which is a significant gap since both parameters are required. It provides high-level purpose but lacks details needed for correct 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?
Input schema has two required parameters (hosting_id, vhost_route_id) with no descriptions, and schema_description_coverage is 0%. The description does not mention or explain these parameters, leaving the agent to guess their meaning for the job listing 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?
Description clearly states the tool lists recent jobs (builds, restarts) for a Node.js app, including status and JWT-protected log_stream endpoint per job. It distinguishes from siblings like infomaniak_nodejs_app_logs (logs) and infomaniak_nodejs_app_status (current status) by specifying 'recent jobs' and specific job 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?
Description mentions 'Manager-private' indicating access restrictions, but does not provide explicit guidance on when to use this tool versus alternatives like infomaniak_nodejs_app_logs or infomaniak_nodejs_app_status. It implicitly suggests use for viewing historical job records, but lacks clear when-not 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 indicate readOnlyHint, idempotentHint, and openWorldHint, reducing the burden. The description adds value by detailing the specific return fields (provisioning state, type, validity flags, timestamps, etc.), providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose and lists features. It is efficient with no wasted words, though the list of fields makes it slightly long.
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, the description need not explain return values, but it does so helpfully. However, it omits how to obtain the required IDs (e.g., from list hostings/sites) and does not address error cases like missing certificates. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only implies that hosting_id and site_id identify a site on a web hosting, but does not define them clearly or indicate how to obtain them. This is insufficient for a tool with only two 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 it returns the full SSL certificate detail for one site on a web hosting, and lists many specific fields. It distinguishes well from sibling tools like infomaniak_request_certificate and infomaniak_delete_certificate.
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 certificate details but does not explicitly state when to use this tool versus alternatives like infomaniak_list_sites or infomaniak_get_domain. 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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint. The description adds value by specifying what details are fetched (applications, permissions, phpMyAdmin link), which is beyond the annotations. No contradiction found.
Agents need to know what a tool does to the world before 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 of 17 words, with no wasted verbiage. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown), so return values are documented. The description adds context about what is fetched. With two parameters (one described) and annotations, the description is adequate, though slightly more detail on behavior could push it to 5.
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% (user_name has description, hosting_id does not). The tool description does not add meaning to parameters, missing the opportunity to clarify hosting_id or the format of user_name. With low coverage, description should compensate but 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 clearly states the verb 'Fetch' and the resource 'detail of a single MariaDB-level user', and specifies the content (applications, permissions, link to phpMyAdmin). It distinguishes from sibling tools like infomaniak_list_database_users (list) and infomaniak_get_database (get database).
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, nor does it mention prerequisites or when not to use it. The name implies getting a specific user, but explicit usage context is missing.
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 description adds some context about the return structure (password, permissions array, protected flag) but does not reveal additional behavioral traits 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 sentence with a brief follow-up on WordPress, front-loaded with the main purpose. 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?
Given the simple single-parameter tool and presence of annotations and output schema, the description provides sufficient context about the return structure. However, it omits explanation of the parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention the 'hosting_id' parameter at all. It fails to add meaning beyond the schema, which is 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 it lists MariaDB-level user accounts attached to a web hosting, with details about password and permissions. It distinguishes from sibling tools like infomaniak_list_databases and infomaniak_list_hosting_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 does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied from the description of what it does, but no exclusions or context 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?
Annotations already convey read-only, idempotent, and open-world behavior. The description adds value by specifying that the output includes 'environment and SSH flag', providing extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It efficiently conveys the core purpose without repetition or clutter.
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) and the presence of an output schema, the description suffices. It omits details like pagination or filtering, but these are likely covered by the output schema or tool behavior.
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 'hosting_id' parameter (e.g., its source or meaning). Only implicit from the tool name and sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists FTP/SSH users for a web hosting, including environment and SSH flag. It distinguishes itself from sibling tools like 'infomaniak_create_hosting_user' and 'infomaniak_delete_hosting_user' by focusing on read-only listing.
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 other list tools (e.g., 'infomaniak_list_mailboxes'). The description does not mention exclusions or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims enable/disable actions are 'destructive', but annotations set destructiveHint=false. This is a direct contradiction that undermines the AI agent's ability to assess risk. The description also adds value with two-phase commit details, but the contradiction severely impacts transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that conveys all necessary information without verbosity. It could be slightly more structured (e.g., bullet points for actions) but is 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?
The description covers the three actions, two-phase commit, and replacement of older tools. Despite the annotation contradiction, it provides sufficient context for correct usage, including the TTL constraint. The output schema exists, so return value details are not required.
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% and all parameters have descriptions. The description adds context about the two-phase commit flow and the role of confirmation_token, going beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 is for unified DNSSEC management with three specific actions (check, enable, disable), and explicitly distinguishes it from the older v0.9 trio of tools, making the purpose precise and differentiating from 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?
The description explains the two-phase commit for enable/disable and default action as check, providing context on when to use each action. However, it does not explicitly state when NOT to use this tool or mention alternatives beyond the deprecated trio.
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: 'Two-phase commit' implies a confirmation step, 'Manager-private' implies access control, and it clarifies that the main FQDN cannot be removed. No contradiction with annotations (destructiveHint=true, readOnlyHint=false).
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-loading the action and key constraint. However, 'Manager-private' is cryptic and could be clearer. Otherwise, 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 delete alias tool with an output schema and destructive annotation, the description covers the core behavior, effect (vhost no longer responds), and constraints. It lacks explicit prerequisites (e.g., that hosting_id and site_id should come from list tools) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description adds minimal parameter-level detail. While the alias parameter has a detailed schema description, the description does not elaborate on other parameters (e.g., hosting_id, site_id) or the confirmation_token's role in the two-phase commit. The description could compensate more 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 action (remove), the resource (alias FQDN), and the constraint (cannot remove main FQDN). It distinguishes from sibling tools like infomaniak_add_site_aliases and infomaniak_list_site_aliases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Two-phase commit' and 'Manager-private', but does not explicitly state when to use this tool vs alternatives (e.g., when not to use it, or when to use other site alias tools). The usage context is implied but not fully specified.
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, indicating safe repeated reads. The description does not add behavioral context beyond stating it returns the definition. No side effects or auth requirements are mentioned, which is acceptable 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 a single, well-structured sentence that succinctly conveys the tool's purpose and the content of its output. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and clear annotations, the description is largely complete. It captures the essential function and could be improved by noting the format of the returned definition, but it 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 schema covers 100% of the single parameter 'tool' with a description. The tool description does not add additional semantic meaning 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 function: 'Returns the full definition of a specific tool' and lists the components (description, annotations, parameters, output shape). It distinguishes itself from siblings, as it is a meta-tool for obtaining information about other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the description (useful for learning about a tool), but there is no explicit guidance on when to use it versus alternatives or when not to use it. The sibling tools are all action-oriented, so the purpose is clear, but 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 readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, establishing safe read behavior. The description adds value by enumerating the specific configuration fields returned (e.g., Node version, SSL status, disk usage) and the authentication requirement, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the purpose and lists key fields, the second adds authentication context. It is front-loaded with the purpose, concise with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and annotations covering safety, the description provides a good overview of what data is returned and the authentication requirement. It does not discuss error handling or pagination, but for a configuration retrieval tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes both parameters with sufficient detail (e.g., vhost_route_id includes cross-reference to list endpoints). The description does not add any additional parameter meaning, meeting the baseline of 3 for high 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 states 'Get full configuration of a Node.js application' which clearly indicates the verb and resource. It lists specific fields returned (Node version, port, IPs, etc.), but does not explicitly differentiate from sibling tools like infomaniak_nodejs_app_status or infomaniak_nodejs_app_logs, though the scope 'full' implies comprehensiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Manager-private — requires SASESSION + CSRF cookies' which gives authentication context. However, it does not state when to use this tool versus alternatives (e.g., for initial retrieval after listing), nor does it explicitly indicate prerequisites like obtaining hosting_id and vhost_route_id from list endpoints, though the schema parameters provide that 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 indicate readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds value by explicitly stating pagination support, which is a key behavioral trait beyond 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?
The description is two concise sentences—first sentence states the core purpose, second adds pagination support. No unnecessary 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?
Given the presence of an output schema (not shown), the description need not detail return values. It adequately covers the action, scope, and pagination. Minor gap: it doesn't mention that results contain file/folder metadata, but that is likely handled by the output schema. Overall, fairly complete for a straightforward listing 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 only 25% (only parent_id has a description). The description partially compensates by explaining parent_id's role (omit for root), but the meaning of drive_id, per_page, and page is left to parameter names, which are mostly self-explanatory. Overall, the description adds some meaning but does not fully cover all 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 lists files and subfolders of a kDrive root or a specific folder, and that it supports pagination. This differentiates it from sibling tools like infomaniak_list_drives or infomaniak_list_domains, which list 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it, prerequisites, or trade-offs, leaving the agent to infer context from sibling names only.
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, non-destructive, idempotent behavior. Description adds valuable context: 'Cheap call, safe to poll' and auth requirements, providing insight beyond 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?
Three concise sentences with front-loaded purpose: first sentence states goal, second adds usage/behavior, third adds auth. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return format is covered. Description lacks parameter explanations, which is a gap. However, for a simple status check tool, the context is mostly sufficient except for parameter semantics.
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 0% means description must explain parameters, but it does not. The two required parameters (hosting_id, vhost_route_id) are not described. Agent must infer from context or external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear statement: 'Get the live status of a Node.js application — Running or Stopped.' Specific verb and resource with explicit output. Distinguishes from sibling tools like infomaniak_nodejs_app_action (state change) and infomaniak_list_nodejs_apps (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?
Explicitly states 'Cheap call, safe to poll' indicating low cost and suitability for frequent checks. Also mentions auth requirements ('Manager-private — requires SASESSION + CSRF cookies'). No explicit when-not-to-use but contextually 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?
Description adds significant context beyond annotations: it reveals the two-phase commit process, the reversible condition, and that a plan is returned first. Annotations indicate destructiveHint=true and readOnlyHint=false, which align. No contradictions. Could further clarify behavior of confirmation_token, but 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?
Two sentences deliver the core purpose and behavior with zero redundancy. Front-loaded with action, then two-phase detail. 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?
Description explains the two-phase commit and reversibility but omits where history_id originates (likely from infomaniak_history sibling) and how to obtain the confirmation_token. Given the complexity and existence of an output schema, more context about the flow would improve 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%, yet description provides no explicit explanation of the two parameters. 'history_id' is implicitly linked to the action to undo, but 'confirmation_token' is not explained. Description fails to compensate for the 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?
Description clearly states the tool reverses destructive actions from session history, with precise verb 'Reverse' and resource 'destructive action'. It distinguishes from siblings like infomaniak_history, which lists history but does not undo, and from create/delete tools which are constructive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when an action is reversible and mentions a two-phase commit pattern, but does not explicitly state when not to use (e.g., irreversible actions) or provide alternatives like manual restoration. No reference to prerequisites (e.g., history_id from infomaniak_history).
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; description adds the two-phase commit detail and forwarding behavior. No contradiction, but could mention permissions or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant text, front-loaded with the action. Every sentence 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?
Given the output schema exists and parameters are well-documented, the description is adequate but lacks details on the plan step of the two-phase commit, which could confuse the 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?
Schema coverage is 100% so the schema provides full parameter documentation. The description adds minimal extra value beyond the schema, so 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?
Description clearly states 'Create a server-side mail redirection' and explains the forwarding behavior. It distinguishes from siblings like list_redirections and delete_redirection.
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?
Mentions 'Two-phase commit' but does not explain when to use the plan vs apply phase or provide explicit alternatives. Usage context is implied but not fully clarified.
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=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds context about access restriction ('Manager-private') and detailed response fields, going 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose ('Full organization detail') and lists key fields without waste. 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.
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 provides sufficient overview of the returned data. It lists many fields, which complements the schema, but is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, with the account_id already described as 'Account/organization id. Discover via infomaniak_list_organizations.' The tool description does not add further parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full organization details including legal entity, billing, VAT, locale, timezone, logo URLs, support tier, 2FA policy, user role, counts, and tags. This distinguishes it from sibling list tools like infomaniak_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it's for managers ('Manager-private'), but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or which sibling tool to use instead for simpler queries.
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 declare readOnlyHint, idempotentHint, and openWorldHint. The description adds context by specifying what details are included (disk usage, application, permissions, backups). No contradictions; the description complements annotations well.
Agents need to know what a tool does to the world before 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 18 words, front-loading the main action and then listing key attributes. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It lists included details, which is sufficient. The agent can infer required parameters from the schema. Slightly lacking in providing prerequisites or context about when to use this tool over others, but still complete enough.
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 information about parameters beyond what is in the schema. Schema description coverage is 50% (database_name has a description, hosting_id does not). The tool description should compensate but does not, offering no additional meaning 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 ('Get') and resource ('full detail of a specific database'), listing specific attributes (disk usage, application, permissions, backups). This distinguishes it from sibling tools like infomaniak_list_databases (list only) and infomaniak_get_database_user (user 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 usage for retrieving full details of a specific database, but does not explicitly state when to use this tool vs alternatives like infomaniak_list_databases or infomaniak_get_database_user. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: describes destructive nature and reversibility info. Annotations already indicate read-only and idempotent, and description is consistent and informative.
Agents need to know what a tool does to the world before 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 key purpose, no extraneous text. 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?
Covers purpose, session scope, and content (reversibility). With output schema present, return format is not required. Minor gap: no mention of pagination or default limit, but overall sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description for 'limit') and description fails to mention the optional parameter or its constraints. The schema itself defines limit clearly but description adds no value for 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?
Clearly states it lists destructive actions in the current session, most recent first. Differentiates from sibling list tools by specifying 'destructive actions' and mentions undo capability, which is unique.
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?
Implies usage for reviewing destructive actions and enables undo. Does not explicitly state when to use versus alternatives or provide exclusion criteria, but the connection to infomaniak_undo 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 read-only, non-destructive, idempotent behavior. The description adds useful context about the underlying Apache vhost/DocumentRoot setup, which goes beyond the annotations without contradicting 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?
Three sentences with no redundancy or filler. Each sentence adds value: action, context, and constraint. Very 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 that an output schema exists, the description does not need to detail return values. It explains what is listed (FQDNs) and the underlying architecture. It is complete for a listing tool, though the 'Manager-private' tag could be elaborated.
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%, and the parameter descriptions reference discovery tools (infomaniak_list_hostings, infomaniak_find_site), adding practical guidance beyond type definitions. The tool-level description does not add further parameter detail, but the schema itself is well-covered.
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 FQDNs (main + aliases) for a web hosting site, using a specific verb and resource. It distinguishes from sibling tools by mentioning that adding an alias is how you serve more domains, but the phrase 'Manager-private' is vague and not fully explained.
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 purpose and context (serving multiple domains from a single WordPress install), implying when to use this tool. However, it does not explicitly state when not to use it or provide direct alternatives like infomaniak_add_site_aliases or infomaniak_delete_site_alias.
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, openWorldHint=true, so the description doesn't need to restate these. It adds minimal context ('Acronis-based') but no additional behavioral traits 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?
Single sentence, no filler. Efficiently conveys 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 tool's simplicity (one optional param, no required fields, output schema present), the description covers the essential info. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter account_id has a schema description explaining it's optional and defaults to the first account. The description adds value by mentioning discovery via infomaniak_overview, clarifying how to obtain the ID. Schema coverage is 100%, so the description complements rather than repeats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 the action ('List'), the resource ('Swiss Backup subscriptions'), and the context ('on an Infomaniak organization, Acronis-based managed backup'). It distinguishes from sibling list tools targeting other resources like domains, databases, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., infomaniak_overview for broader organization overview). The description does not mention prerequisites 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 declare readOnlyHint, idempotentHint, and openWorldHint. The description adds 'summary of all... you have access to' but does not disclose additional behavior beyond annotations. 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?
Two concise sentences with no filler. The purpose is front-loaded, and the usage guidance is immediate. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and rich annotations, the description is nearly complete. However, the lack of explanation for the optional parameter is a gap, but not critical for an overview 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?
The optional account_id parameter has no description in the schema and is not explained in the description. With 0% schema description coverage, the description should compensate but does not mention the parameter at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 returns a summary of all Infomaniak organizations and products the user has access to, which is specific and differentiates it from sibling tools like list_organizations or list_sites that focus on individual 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?
Explicitly recommends calling this tool first in a session, providing clear timing context. However, it does not mention when not to use it or alternatives, though the purpose makes it 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?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by specifying exactly what is checked (products, domains, etc.), which is not evident from annotations alone. 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 of 12 words, front-loading the purpose and listing key issue categories. Every word is necessary and no 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?
Given the presence of an output schema and detailed parameter descriptions, the description adequately explains the tool's scope. It covers the main categories of issues and is sufficient for an agent to decide when to call 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 coverage is 100% with detailed parameter descriptions. The tool-level description does not add further meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans for 'actionable issues' and enumerates specific categories (expiring, maintenance, locked, operations). This is a specific verb-resource combination that distinguishes it from sibling tools like infomaniak_audit_dns_zones or 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 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 auditing an organization but does not explicitly differentiate from alternatives like infomaniak_overview or other audit tools. No guidance on when not to use it, leaving the agent to infer 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?
Adds value beyond annotations by describing two-phase commit process and that password never appears in plan output. Annotations already indicate destructive hint, but description enriches 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 sentences, front-loaded with purpose, no filler. Efficiently communicates core 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?
Covers main two-phase commit flow and mentions password security. With output schema present, return values are not needed. Lacks mention of prerequisites like valid mail hosting ID.
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 baseline is 3. The description itself does not add parameter meaning beyond what the schema provides, but it does mention password security aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Create a new mailbox on a mail hosting' and distinguishes from sibling tools like delete or list mailboxes. Mentions two-phase commit, adding 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?
Provides guidance on two-phase commit (plan then apply) but does not explicitly state when to use this vs alternatives (e.g., creating an alias) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds context about scope ('every kDrive the account has access to'), which is consistent and slightly enhances 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?
A single, front-loaded sentence that immediately communicates the tool's purpose with no superfluous 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 an output schema and comprehensive annotations, the description is complete for a simple list tool. It might benefit from noting what fields are returned, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description in the schema is thorough, explaining optionality and default behavior. The tool description does not need to repeat this, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List every kDrive the account has access to' uses a specific verb and resource, clearly distinguishing it from siblings like infomaniak_list_drive_files which lists files within a drive.
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_overview. It only implies usage for listing drives, but lacks direct guidance on exclusions or alternatives.
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 valuable behavioral context: the tool returns sensitive data (auth_code) and notes 'Manager-private' (permission requirement). No contradictions. Adds beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but packs many specific data items. It is front-loaded with 'Full domain detail'. Slightly long but efficient; no wasted words. Could be broken into bullet points for readability, but still good.
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 annotations cover safety and output schema exists (not shown but implied), the description is fairly complete: lists return contents, input format, and permission note. It lacks details on pagination or response size, but being read-only with openWorldHint, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameter well. The description repeats that it accepts id or FQDN and adds a discovery hint. This is adequate but does not significantly enhance 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 explicitly lists many specific data fields (auth_code, transfer_status, glue records, etc.) and states 'Full domain detail', clearly differentiating from simpler sibling tools like infomaniak_get_domain. The verb 'get' plus 'full' accurately describes the resource and 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 explains how to specify the domain (id or FQDN) and references infomaniak_list_domains for discovery. Although it doesn't explicitly contrast with simpler alternatives, the naming and content imply when to use this comprehensive version. Clear context for 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 declare read-only, idempotent, open-world. Description adds useful behavioral context: includes disk usage and running operations, which is 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?
Single sentence, 15 words, front-loaded with purpose. Every word carries meaning 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?
With an output schema, the description need not detail return format. It covers scope and additional info (disk usage, operations). Complete for a simple list 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 0%, but the parameter 'hosting_id' is implicitly explained by the description as the web hosting identifier. No extra detail beyond schema, but sufficient given simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specific verb 'list', resource 'MariaDB databases', and scope 'attached to a web hosting'. Also mentions additional data (disk usage, operations). Clearly distinguishes from sibling tools like infomaniak_get_database (single database) and infomaniak_create_database.
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?
Implies usage: when you need all databases for a hosting. Missing explicit guidance on when not to use (e.g., if you need a single database, use get_database) or alternatives.
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, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds value by specifying that the response includes creation and expiration dates, which goes beyond the annotations without contradicting them. No additional behavioral traits (e.g., permissions, pagination) are disclosed, but the annotation coverage is strong.
Agents need to know what a tool does to the world before 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 unnecessary words. It is front-loaded and efficiently communicates the core functionality.
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 a straightforward list operation with an optional parameter and an existing output schema. The description sufficiently explains what the tool does and what it returns, making it 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% for the single optional parameter account_id, which is well-documented in the schema. The description does not add 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 uses a specific verb ('List every domain') and clearly identifies the resource (Infomaniak organization) and additional detail (creation and expiration dates). It distinguishes itself from siblings like infomaniak_get_domain (single domain) and infomaniak_list_organizations (lists organizations, not domains).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all domains in an organization but does not explicitly state when to use this tool versus alternatives such as infomaniak_get_domain for a single domain or infomaniak_audit_dns_zones for DNS details. No exclusions or when-not guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds value by disclosing the timestamps shown (deleted and added) and the audit purpose. The 'Manager-private' note hints at access restrictions.
Agents need to know what a tool does to the world before 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, each delivering essential information: what the tool does, what data it shows, and when to use it. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one required parameter and an output schema, the description covers the purpose and key output fields. However, it omits parameter explanation and doesn't describe the full response structure, leaving minor 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 0%, so the description must compensate. However, it fails to mention the drive_id parameter at all, leaving the agent to infer its meaning from the name and context. 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 the tool lists items in the kDrive trash bin, specifying files and folders. It differentiates from sibling tools like infomaniak_list_drive_files by focusing on trash content and mentioning timestamps for deletion and addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to audit what's pending hard-deletion,' providing a clear use case. Although it does not mention when not to use it or alternatives, the context and sibling list naturally separate trash from active file listing.
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, non-destructive, idempotent behavior. The description adds 'Manager-private' indicating access restrictions, which is additional useful context. 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?
Two sentences, no unnecessary words. Front-loaded with the main action and result structure. Efficient and to the point.
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 summarizes output (teams with counts, tags with products) and mentions access level. Given that an output schema exists, the description provides sufficient context for understanding the tool's purpose and result.
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 only indirectly references the parameter by saying 'of an organization', but does not explain the account_id parameter or its format. With a single required parameter, more explicit description would be helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 lists teams and tags of an organization, specifying the verb and resource. It distinguishes from sibling list tools by focusing on teams and tags, and mentions 'in a single call' for efficiency.
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 that both lists are useful to understand org partitioning and labeling, providing context for when to use. It does not explicitly mention alternatives or when-not, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds value by noting 'Manager-private' and explaining caching behavior (default cached, refresh forces fresh screenshot). 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?
The description is concise with four short sentences. It front-loads the primary purpose. Could be slightly more structured, but it efficiently conveys key points.
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 and annotations are rich, the description covers purpose, behavioral nuance (cached/fresh), and use case. It does not explain prerequisites or error states, but overall it is complete enough for a read-only, low-risk 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 coverage is low (33%): only 'refresh' has a description. The tool description only repeats the refresh behavior without explaining the two required parameters (hosting_id, vhost_route_id). This leaves their meaning and source unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a screenshot of a running Node.js app as a base64 JPEG data URL. It uses a specific verb ('Get') and resource ('screenshot'), and this functionality is distinct from sibling tools like status, logs, or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'visually confirm the app is alive without HTTP-probing.' It also mentions the refresh parameter's behavior. However, it does not explicitly state when not to use this tool or compare it to alternatives like infomaniak_nodejs_app_status.
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 critical behaviors: the two-phase commit process and the decision to use a private API because the public API silently no-ops. This adds context beyond what annotations (destructiveHint=true, idempotentHint=false) provide, helping the agent anticipate side effects and API behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense sentence that packs purpose, behavior, and rationale. It is front-loaded but could be more readable with a slight structural split. Still, it is efficient with 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?
Given the tool's complexity (two-phase commit, private API workaround), the description covers essential context: what it creates, how it operates, and why the alternative API path was chosen. With an output schema present, the agent has enough information to use 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 baseline is 3. The description does not add additional meaning to parameters beyond the schema. However, the schema itself provides adequate details, including hosting_id source and naming constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create'), resource ('a new MariaDB database on a web hosting'), and distinguishes the tool from siblings like delete or get by mentioning the two-phase commit and reliance on a private API. This specificity ensures the agent understands exactly 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 when to use the tool (for creation) but does not explicitly state when not to use it or mention alternatives. The input schema for hosting_id hints at prerequisite tools (infomaniak_find_site, infomaniak_list_hostings), but this is not in the main description, leaving usage guidance incomplete.
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 (mutation) and readOnlyHint=false. The description adds value by explaining the two-phase commit, password policy, and login formatting rules. 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 (three sentences) and front-loaded with the primary purpose. Every sentence adds essential 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 creation, two-phase commit, connection types, and password policy. It does not explain the token parameter or two-phase flow in detail, but an output schema is present, reducing the need to document return values. Adequate for a well-annotated 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%, so the schema independently documents all parameters. The description adds context about the two-phase commit (token) and password policy but does not describe each parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (FTP/SSH user on web hosting), and specifies the connection types. It distinguishes this tool from siblings like 'infomaniak_create_database' or 'infomaniak_create_mailbox' by focusing on user creation for hosting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Two-phase commit', which signals a multi-step process (plan then apply). It distinguishes between 'ftp' and 'ssh' connection types with clear behavioral differences. However, it does not explicitly state prerequisites (e.g., need hosting ID via 'infomaniak_list_hostings') or 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the two-phase commit behavior beyond annotations, including the plan and confirmation_token flow. Annotations already indicate destructive and non-read-only nature, but the added workflow details 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 sentences with front-loaded purpose and efficient description of the two-phase commit. Every sentence is necessary and well-structured.
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?
Covers the two-phase workflow but lacks details on the return value of the first call (the plan) and how to interpret the confirmation_token. Output schema may cover return values, but the description could be more complete for a complex 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 coverage is 0%, but description only mentions parameters generically ('same params + token'). Does not explain the role of hosting_id, fqdn, directory, or environment, failing to add meaning 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?
Clearly states it creates a new site on an Infomaniak web hosting, with specific verb 'creates' and resource 'site'. Distinguishes from siblings like delete_site or find_site.
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?
Describes the two-phase commit process, making clear how to use the tool in two calls. Does not explicitly mention alternatives or when not to use, but the creation context 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 indicate destructiveHint=true. The description adds a clear warning about irrecoverable data loss and mentions the two-phase commit process, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences without redundant information. It front-loads the purpose and immediately follows with behavioral traits (two-phase) and a critical warning.
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, annotations, and existing output schema, the description covers the key workflow (two-phase commit, warning) and parameter origin. It could mention the need to call a plan phase first, but the confirmation_token parameter hints at this.
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?
With 100% schema coverage, baseline is 3. The description adds value by explaining the confirmation_token's origin ('from the first (plan) phase') and notes that database_name includes the hosting prefix, which complements the 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 'Delete a MariaDB database', specifying the verb (delete) and resource (MariaDB database). It distinguishes from sibling delete tools (e.g., delete_site, delete_mailbox) by naming the database type.
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 via 'Two-phase commit, manager-private API' and a warning about data loss, but it does not explicitly state when to use this tool vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining the two-phase commit and that files are preserved. Annotations include destructiveHint=true and idempotentHint=true, and the description does not contradict them, though the two-phase nature might slightly complicate idempotency. Overall, good additional 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 sentences with no waste. The main action is front-loaded, and key details (two-phase, file preservation) are provided succinctly.
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 delete operation, the description covers the two-phase process and file preservation. An output schema exists, so return values are not required. However, it could briefly mention what the first call returns (plan + token), but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds extra meaning: it specifies that 'login' includes the hosting prefix and explains the two-phase use of 'confirmation_token'. This goes beyond the schema's own 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 ('Revoke a hosting user'), the specific resource (FTP/SSH access), and unique details (two-phase commit, files not deleted). It distinguishes from sibling tools like infomaniak_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?
No explicit guidance on when to use this tool versus alternatives (e.g., other delete tools). The two-phase commit implication is present but not detailed, and no when-not-to-use advice is given.
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 mark it as destructive. The description goes beyond by explicitly warning that all stored emails are deleted and by mentioning the two-phase commit process, providing important 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 with no wasted words. It front-loads the action and includes critical warnings 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 description covers the essential aspects (action, two-phase commit, destructive consequence). It could briefly explain the two-phase commit flow, but the parameter description for confirmation_token compensates partially. With output schema existing, completeness 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?
Schema coverage is 100%, so descriptions already cover parameters. The main description adds no new semantic information about parameters beyond what is in the schema, hence a baseline score 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 'Delete a mailbox' and the resource, and includes a warning about deleting stored emails. The two-phase commit detail adds clarity and distinguishes it from other 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 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 compared to alternatives. While parameter descriptions hint at prerequisites (e.g., verify mailbox with list), the main description lacks direct 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?
Adds value beyond annotations by noting the 'Manager-private' nature, which indicates a privilege requirement. Does not contradict readOnlyHint, destructiveHint, idempotentHint, or openWorldHint.
Agents need to know what a tool does to the world before 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: first states the action, second adds context and usage hint. No wasted words, effectively 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 simple interface (one required parameter, output schema present), the description is mostly complete. It could mention error cases or explain 'Manager-private' more explicitly, but overall it provides enough context for an AI 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?
Schema description coverage is 0%, so the description must compensate. The description mentions 'a kDrive' to imply the required drive_id parameter, but does not explain the parameter's format, constraints, or example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List the users with access to a kDrive'), identifies a specific use case ('access audits'), and distinguishes itself from sibling list tools by focusing on users rather than files or other 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?
Provides a clear context for when to use the tool ('access audits') and hints at access restrictions ('Manager-private'), but does not explicitly compare with alternatives like infomaniak_get_drive_full, which might also provide user information.
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, idempotent, and open-world behavior. Description adds the fallback behavior of omitting account_id (defaults to first account), which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: one states purpose, the other gives usage direction. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and annotations cover safety, the description provides sufficient context for a list tool. Minor omission: no mention of pagination or limits, but not critical.
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 already describes account_id with fallback and enumerate hint, and include_nodejs has default. Description reinforces the sequential order (list orgs first but does not add new 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 tool lists web hostings (classic and Node.js) for an Infomaniak organization, distinguishing it from sibling tools that list other resources like databases or mailboxes.
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 advises using infomaniak_list_organizations first to discover account IDs, but does not compare to alternatives or specify 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.
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 tool is clearly safe. The description adds that it lists 'every' mail hosting, implying a complete fetch. No additional behavioral traits (e.g., return format, pagination) are disclosed beyond what annotations cover, but 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 two sentences long, directly stating the purpose and the optional parameter's default behavior. Every sentence is necessary and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and an existing output schema, the description covers the essential points: what is returned (mail hostings) and the parameter semantics. It could mention that the list is complete, but that is implicit from 'list every'.
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 documents account_id with a description, and the description clarifies that it is optional and defaults to the first account the token can access. It also suggests using infomaniak_overview to discover the ID, adding value beyond the raw 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 specifies the verb 'list' and the resource 'mail hosting (a.k.a. email_hosting)', clearly indicating it returns all mail hostings for an organization. This distinguishes it from sibling tools like infomaniak_list_hostings (shared hosting) and infomaniak_list_mailboxes.
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 the tool lists mail hostings and notes that the account_id parameter is optional, defaulting to the first accessible account. It recommends using infomaniak_overview to discover the account ID, providing usage context. It does not explicitly exclude alternatives but the sibling list implies differentiation.
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, idempotentHint=true. The description adds useful behavioral context by listing returned fields, noting it is 'Manager-private' (access restriction), and implying a safe read operation. 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?
Three sentences: first states the action, second enumerates return fields, third gives usage guidance. No unnecessary words, front-loaded, and each sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety and idempotency, the description adequately covers purpose, return content, and workflow context. It does not mention pagination or filtering, but for a simple listing tool with one parameter, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for `account_id`. The description does not add additional parameter semantics beyond what the schema provides, but it does hint at how the parameter is used (to later find a server by id). 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 'List the VPS products of an organization' with a specific verb and resource, and distinguishes itself from the sibling tool `infomaniak_get_vps_full` by explaining the workflow (use this first to get an id). It also adds detail about Jelastic-managed and Manager-private.
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 advises to use this before `infomaniak_get_vps_full` to find a server's id. This provides clear contextual guidance. However, it does not mention when not to use it or any alternatives beyond the one sibling.
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 details beyond the annotations. It explains that the JWT is one-shot, valid for ~1h, the endpoint URL, and how to consume the SSE stream. The annotations already mark it as read-only and non-destructive, and the description does not contradict them. It also adds 'Manager-private' 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 brief and to the point: four sentences covering purpose, returned data, usage instructions, and a snapshot tip. No redundant information. Front-loaded with the core 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?
The tool has an output schema (not shown) but the description doesn't reference it. The description explains the returned credentials and their usage, which is likely sufficient for an agent. However, the lack of parameter explanation is a significant gap, and the description does not address what the output schema contains or how to interpret the response beyond the JWT and endpoint.
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 required integer parameters (hosting_id, vhost_route_id) with no descriptions. The schema coverage is 0%, and the tool description does not explain what these parameters represent or how they affect the tool's behavior. The description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to obtain credentials for consuming the live stdout/stderr stream of a Node.js application. The verb 'Get credentials' and resource 'live stdout/stderr stream' are specific, and the tool is distinct from siblings that handle other aspects of Node.js apps (status, action, aliases, jobs, thumbnail).
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 instructions on how to use the returned credentials (SSE consumption via curl, snapshot by killing curl). It also mentions 'Manager-private.' Though it doesn't explicitly compare with sibling tools, the context makes it clear that this tool is for log streaming, while siblings serve other purposes.
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, openWorldHint. The description adds that it returns consumption and limit, but does not elaborate on additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence. No wasted words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of output schema, the description sufficiently tells what the tool does. Could benefit from hinting at numeric nature of output, but not required.
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?
No parameters exist, so schema coverage is trivially 100%. Description adds no further parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns current consumption and limit of short-URL quota. Distinct from sibling tools that list, create, or delete short URLs.
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 usage context is implied: check quota before creating short URLs. However, no explicit when-to-use 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent behavior. The description adds no behavioral traits beyond the input constraint (root domain). 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?
Two short sentences with no wasted words. The action statement and usage constraint are front-loaded and precise.
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 1 parameter and rich annotations (readOnly, idempotent, openWorld) plus an output schema, the description covers all necessary context: what it does, what input it expects, and how to format it.
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 the 'zone' parameter as root domain. The description reinforces this and adds the explicit 'not a subdomain' rule, providing additional clarity 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 ('List every DNS record') and the resource ('a zone managed by Infomaniak'), distinguishing it from sibling tools like create/delete/update. It also specifies the correct input format (root domain, not subdomain).
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 usage constraint ('Use the root domain, not a subdomain'), but does not explicitly compare with alternatives or state when not to use. However, the purpose is clear enough given the sibling names.
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, idempotent, and open-world behavior. The description adds value by specifying the exact data returned (DNS management status, DNSSEC, IDN, errors), providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with key information, and contains no redundant words. It is appropriately concise for a straightforward tool.
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 the tool has an output schema (not shown but known from context), the description need not detail return values. The description covers the essential aspects, and annotations cover safety. It is complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the single parameter 'domain'. The tool description does not add any additional parameter semantics; 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?
The description clearly specifies the verb 'Get' and the resource 'domain', and lists specific aspects (DNS management status, DNSSEC, IDN, errors). This distinguishes it from sibling tools like infomaniak_list_domains (for listing all domains) and infomaniak_manage_dnssec (for managing DNSSEC).
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 when detailed information about a single domain is needed. Although it does not explicitly mention alternatives, the sibling tools list provides context and the purpose is self-explanatory. Slightly lacking explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. Description adds that the tool uses a private manager API, which provides authentication context beyond 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 concise sentences with no extraneous content. Every sentence adds value: first describes purpose and fields, second provides use case and sibling differentiation.
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 get tool with output schema present, the description covers purpose, fields, use case, and API type. No gaps given the context signals and schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter drive_id with description. Description only mentions discovering it via infomaniak_list_drives, which adds minimal value beyond schema. Baseline 3 for high coverage, slight improvement but not significant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 kDrive detail including specific fields (name, sizes, timestamps, maintenance flag) and explicitly distinguishes from sibling tool infomaniak_list_drives, which uses a public API.
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?
Indicates tool is for storage usage monitoring and notes it is manager-private, contrasting with the public Bearer API of the sibling. While it doesn't explicitly state when not to use, the distinction 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 provide safety profile (readOnly, non-destructive, idempotent). The description adds the 'Manager-private' qualifier, indicating authorization requirements beyond annotations. It accurately describes the return content 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?
Two sentences only: first immediately lists key fields; second gives clear usage hint. Every sentence adds value, 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?
Output schema exists, so return values need no description. The description covers all key fields (DNS health, quotas, admin, etc.) and parameter is well-documented in schema. Complete for a read-only single-resource tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter description already guides discovery via infomaniak_list_mail_hostings. The tool description adds no further semantic value for the parameter, so 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 explicitly states 'Full mail hosting detail' and enumerates specific fields (diagnostic_dns health check, quotas, admin user, etc.), distinguishing it from siblings like infomaniak_get_mailbox_full (single mailbox) and infomaniak_list_mail_hostings (list only).
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 'Use this for mail-config sanity checks' and includes 'Manager-private' hinting at access restrictions. The parameter description advises discovery via infomaniak_list_mail_hostings. However, it does not explicitly exclude alternatives or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds the behavioral trait of being 'Manager-private', which is valuable context for an agent. 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?
Efficient single sentence listing return details, followed by two clear sentences for usage and access constraints. 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?
Comprehensive for a simple read tool: lists all returned data categories, gives usage sequence, and specifies access level. Output schema exists but description goes beyond 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 coverage is 100% with clear description for vps_id. The description does not add semantic value beyond the schema, meeting baseline for high 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 it returns full VPS/Cloud Server detail with a specific list of attributes, and distinguishes itself by advising to use after infomaniak_list_vps to drill into one server, differentiating from 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?
Explicitly says 'Use after infomaniak_list_vps to drill into one server.' and mentions 'Manager-private', providing clear context. No explicit exclusions, but sufficient guidance for typical use.
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 reveals that the tool uses 'lightweight keyword matching', which implies limited accuracy and simple logic. This adds behavioral context, though it could be more detailed about limitations.
Agents need to know what a tool does to the world before 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 action and resource. No redundant words, each sentence serves a 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 simple parameters, the presence of an output schema (not shown), and the straightforward nature of a tool recommender, the description is complete enough. It explains both what the tool does and how (keyword matching).
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 2 parameters with 50% description coverage (intent has description, limit does not). The description adds some context ('keyword matching' implying how intent is used) but does not elaborate on limit's purpose or edge cases. Baseline 3 is appropriate given the schema already covers the required 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 the verb 'suggest', the resource 'which Infomaniak tools', and the method 'lightweight keyword matching'. It distinguishes itself from sibling tools that are specific actions (create, delete, list), making its purpose distinct.
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 when the agent needs to map a natural language intent to a tool, but it does not explicitly state when not to use it or name alternatives. However, the context of sibling tools is clear, and the description provides adequate guidance 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 provide readOnlyHint, idempotentHint, and openWorldHint. The description adds that it lists models, consistent with annotations. No additional behavioral details like pagination or rate limits are provided, but the annotations cover the safety profile sufficiently.
Agents need to know what a tool does to the world before 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 fluff. First sentence states purpose with examples, second sentence gives usage context. 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?
Despite the tool's simplicity (zero parameters, output schema exists), the description provides sufficient context: lists model types, examples, and relevance to the chat endpoint. It is complete for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline is 4. The description does not need to add parameter information; it correctly describes what the tool does without referencing 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 verb 'List', the resource 'public catalogue of LLM/STT/embedding models', and provides specific examples (Mixtral, Llama variants, Whisper). It effectively distinguishes from sibling tools like infomaniak_list_ai_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by stating it is useful for targeting the OpenAI-compatible chat endpoint, implying when to use this tool. However, it does not explicitly state when not to use it or compare against alternatives like infomaniak_list_ai_products.
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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds beyond annotations: 'Manager-private endpoint' and auth requirements, plus typical single-entry behavior. 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?
Three sentences totaling ~40 words. Front-loaded: purpose first, then typical behavior and key output, then auth context. 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?
Given an output schema exists, return values are not required. The description covers the key output (vhost_route_id, FQDNs), hosting type, single-app behavior, and authentication. Complete for a list 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%. The parameter 'hosting_id' is described in schema as 'Node.js hosting id (service_id 57).' The description reinforces this by specifying the hosting type. Baseline 3 is appropriate as 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 'List Node.js applications running on a hosting_3 (Cloud Server Node.js) container.' It specifies the verb (list), resource (Node.js apps), and context (hosting_3). It distinguishes from siblings by noting this tool returns the vhost_route_id needed for other Node.js 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 context: 'Each Infomaniak Node.js hosting runs a single app, so this typically returns one entry.' It also states 'Returns the vhost_route_id needed for every other Node.js tool' which implies this tool is a prerequisite. Authentication requirements are given (SASESSION + CSRF cookies). Missing explicit when-not or alternatives.
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. Description adds context about token access scope, which is useful beyond annotations. No additional behavioral details needed 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?
Single sentence with no wasted words. Clearly communicates the tool's purpose efficiently.
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 (no parameters, output schema present), the description is complete. It covers what the tool does and its access scope. No additional context 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?
Input schema has no parameters (0 params, 100% coverage). Description does not need to add parameter info. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Lists all Infomaniak organizations (accounts) the current token has technical access to.' It specifies the action (list), resource (organizations/accounts), and access scope (token technical access). Distinguishes from sibling list tools which target different resources (domains, drives, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Usage is implied as the standard way to list accessible organizations, but no when-not or comparator with other list 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?
Description adds significant behavioral context beyond annotations: 'Two-phase commit', 'Asynchronous: returns a progress_id', and 'Manager-private'. 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 concise sentences with no redundancy. Key points front-loaded: action, wildcard support, two-phase commit, async nature.
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?
Explains prerequisites (DNS pointing), two-phase commit, and async result. Missing error handling details, but output schema likely covers return format. Sufficient for the 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 coverage is 50%; description clarifies aliases parameter (wildcards, DNS prerequisite) and confirmation_token, but does not add meaning for hosting_id and site_id beyond what 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?
Clear verb-resource pair: 'Bind one or more additional FQDNs to a web hosting site'. Distinguishes from siblings like delete_site_alias and list_site_aliases by specifying it adds 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?
States when to use: adding FQDNs to existing site, no provisioning. Mentions 'Two-phase commit' and async behavior, but lacks explicit when-not-to-use or alternative 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?
Beyond annotations (destructiveHint=true), the description reveals the fallback behavior, the two-phase commit, and that the plan phase exposes current certificate status. This adds valuable context 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?
Two sentences with zero waste. Key information is front-loaded: the action and its immediate effect. The structure is efficient and clear.
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 covers the essential behavioral context (fallback, undo). The presence of an output schema reduces the need to describe return values. Minor omission: no mention of prerequisites like owner permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add additional information about parameters 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 it deletes the SSL certificate of a site and specifies the consequence (fallback to no HTTPS or default cert). It distinguishes itself from siblings like infomaniak_get_certificate and infomaniak_request_certificate by mentioning the two-phase commit and the undo option.
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 outlines the two-phase commit process: omit token to get plan+token, re-pass to execute. It also provides an undo alternative via infomaniak_request_certificate. However, it does not specify when *not* to use this tool, though the destructive nature is implied.
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 annotations: the two-phase commit, token requirement, and preview behavior. Annotations indicate destructiveHint=true and idempotentHint=true, which align with the description. 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?
The description is two sentences long, front-loaded with the main purpose, and every sentence adds value. 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?
Given the tool's complexity (two-phase commit), the description covers the essential flow. The presence of an output schema likely handles return value documentation, so no further details are needed.
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%. The description only adds meaning for the confirmation_token parameter by explaining its role in the two-phase commit. Other parameters (zone, record_id, source, type, target, ttl) receive no additional semantics, leaving the agent to rely solely on parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates one or more fields of a DNS record, distinguishing it from sibling tools like infomaniak_dns_create_record and infomaniak_dns_delete_record. The verb+resource combination leaves 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 explicitly outlines the two-phase commit process: first call to preview changes and get a token, second call to apply. It provides clear procedural guidance but does not explicitly mention when not to use it or 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?
The description adds significant context beyond annotations: it explains the two-phase commit, that stop causes downtime, and that build returns a log_stream. Annotations already declare destructiveHint=true, but the description elaborates on the nature of destruction. No contradiction found.
Agents need to know what a tool does to the world before 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 (three sentences) and well-structured: it states the purpose, explains the two-phase commit, then provides specific notes on stop and build, and ends with 'Manager-private.' Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, enum, output schema exists), the description covers the two-phase commit and key side effects. It assumes the output schema explains return values. The 'Manager-private' note adds context. Minor gap: no mention of what start/restart return, but output schema likely covers that.
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 50%, with action and confirmation_token described. The description adds value by explaining the two-phase commit and the effects of each action (e.g., stop causes downtime, build returns log_stream), complementing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Start, stop, restart, or build a Node.js application.' It uses a specific verb and resource, and the actions are distinct from sibling tools like infomaniak_nodejs_app_status (status) and infomaniak_nodejs_app_logs (logs).
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 (for managing app state) but does not explicitly exclude alternatives. It provides context like 'stop causes downtime' which guides cautious usage. However, it could be clearer about when not to use it, e.g., for viewing status or logs.
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 (destructiveHint=true), the description adds critical behavioral details: the two-phase commit nature, that the plan lists all steps, and that on apply partial completion is reported if anything fails. These are not present in annotations and provide strong 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-loaded with the core purpose, then explains the key workflow behavior. Every sentence is essential and not redundant 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 complexity (8 parameters, 3 required) and presence of an output schema, the description covers the high-level process and failure behavior. It could mention what the plan response contains besides the token, but overall it's complete enough 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?
Schema coverage is 100% and each parameter is already well-described in the schema. The description adds workflow context (e.g., confirmation_token from plan phase) but does not significantly enhance individual parameter meanings beyond what's 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 explicitly states it provisions a complete website end-to-end, including web site, MariaDB database, and DNS A record. It also mentions the two-phase commit workflow, clearly distinguishing it from atomic sibling tools like infomaniak_create_site or infomaniak_create_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 explains the two-phase commit (plan/apply) workflow and that each step is reported in order, giving context on how to use it. However, it does not explicitly state when to use this composite tool over individual siblings, though the 'end-to-end' phrasing implies it's for full provisioning.
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 set destructiveHint=true, readOnlyHint=false. The description adds the key behavioral detail of the two-phase commit process, which is not captured in annotations. It does not contradict annotations. The description could have elaborated on rate limits or authentication requirements, but the two-phase commit insight 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 extremely concise: two sentences. The first clearly states the purpose, and the second explains the critical two-phase commit workflow. 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 6 parameters, 100% schema coverage, and an output schema, the description is sufficient. It notes the plan+token return from the first call, which compensates for the lack of explicit return value explanation. The description could mention idempotency (annotations say false) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3, but the description adds significant meaning: zone explains domain management check, source clarifies '.' for apex, type mandates UPPERCASE, target explains inline priority for MX/SRV, ttl provides defaults, and confirmation_token links to the plan phase. This greatly aids correct parameter 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 'Create a DNS record on an Infomaniak-managed zone' and details the two-phase commit process, distinguishing it from sibling tools like infomaniak_dns_delete_record, infomaniak_dns_list_records, 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 explicitly explains the two-phase commit protocol: 'first call returns a plan + token, second call (same params + token) actually creates the record.' It also hints at prerequisites via the zone parameter description (check managing domain). However, it does not explicitly state when not to use the tool or list alternatives.
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 crucial behavioral detail about the two-phase commit, including the plan preview and token mechanism. This goes beyond annotations without contradicting 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, front-loaded with purpose, then process, then token clarification. Every sentence adds value with no redundancy. 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 an output schema exists, return values need not be detailed. The description covers the two-phase process, parameter specifics, and token usage. It could mention idempotency of the delete phase, but the annotation idempotentHint=true partially covers that. Overall complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds meaning: zone must be a domain with DNS managed by Infomaniak; record_id is numeric from list_records; confirmation_token comes from the plan phase and includes a preview. This enriches 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 a DNS record from an Infomaniak-managed zone' with a specific verb and resource. It distinguishes itself from sibling tools like infomaniak_dns_create_record and infomaniak_dns_update_record by focusing on deletion and the unique two-phase commit process.
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 explains the two-phase commit: first call returns a plan and token, second call executes the deletion. It advises verifying the plan preview before confirming, which provides clear usage context. It lacks an explicit when-not-to-use statement but is still well-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, idempotentHint, and openWorldHint. The description adds valuable behavioral context: the tool hits endpoints in parallel for selected fields, and it is a replacement for three older tools. 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?
Two concise sentences that front-load the purpose and immediately explain the key feature (subset selection via fields). 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 fully covers the tool's purpose, behavior (parallel requests, replacement of old tools), and parameter usage. An output schema exists for return values, so the description need not detail them. Complete for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well documented. The description adds meaning by explaining that the `fields` argument allows picking a subset and that the tool only hits corresponding endpoints in parallel, which goes beyond the schema's default listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 reads mailbox metadata, specifies the exact fields it can retrieve (aliases, signatures, backups) via the `fields` argument, and explicitly mentions it replaces three older tools. This distinguishes it from sibling tools that perform other operations like listing or creating mailboxes.
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 using the tool: retrieve mailbox metadata in one call, with the ability to pick subsets. It explicitly notes it replaces the v0.9 trio, guiding away from older tools. However, it does not include explicit when-not-to-use or alternative scenarios, though the context is still strong.
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=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds valuable behavioral context by enumerating exactly what security data is returned (2FA status, recovery email, validated phone, Yubikey, rescue codes, last login, password age, trusted devices with IP and time). 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 sentences with no wasted words. It front-loads the purpose and lists contents efficiently.
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 no parameters and an existing output schema, the description fully covers what the tool returns and suggests use cases. It is complete and self-contained.
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?
No parameters exist, so baseline is 4. The description does not need to explain 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 a specific verb ('get') and clearly identifies the resource ('security posture report for the current user'). It lists detailed fields (2FA status, recovery email, etc.), making it distinct from sibling tools like infomaniak_get_my_profile and infomaniak_audit_account.
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 'useful as a periodic security review or pre-action sanity check' and notes it is 'Manager-private.' This provides clear context for when to use, though it does not explicitly exclude alternatives like audit_account.
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, idempotentHint, and openWorldHint. The description adds behavioral insight by explaining what an empty list signifies (no subscription) and includes a subscription URL, offering context beyond the annotations. No contradictions 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 consists of two sentences that are both valuable: the first states the purpose clearly, and the second provides actionable guidance for the empty case. No wasted words, efficiently 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?
With zero parameters and an output schema present, the description is fully complete. It explains the tool's action and the meaning of the result (empty list indicates no subscription). No additional information 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 no parameters and schema coverage is 100%. According to guidelines, baseline for 0 parameters is 4. The description does not need to add parameter info, and it doesn't, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the Infomaniak AI products the account owns', providing a specific verb and resource. It distinguishes from sibling tools like infomaniak_list_ai_models by naming 'AI products' rather than 'models', and from other list tools by the 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 explicitly tells the agent what to do if the list is empty: 'the user has not subscribed to any AI plan; subscribe at ...' This provides clear context for the tool's output and a next step. While it doesn't explicitly mention alternatives, the naming and sibling tools imply differentiation.
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 it as destructive (destructiveHint: true). The description adds value by explaining the two-phase commit, async behavior (returns operation_uuid, need to poll), and type-specific constraints.
Agents need to know what a tool does to the world before 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, no fluff. Key information is front-loaded (action and resource), with type details and follow-up action concisely stated.
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, the description covers all necessary behavioral details (two-phase commit, async polling, type-specific requirements) and is complete for a tool of this 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 coverage is 100%, baseline 3. The description adds meaningful context beyond schema: explains the two-phase commit, groups parameters by type, and clarifies default ('free'). This helps the agent understand conditional requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('request, re-issue, renew') and the resource ('SSL certificate for a site on a web hosting'), and distinguishes from sibling tools like 'infomaniak_delete_certificate' and 'infomaniak_get_certificate' by mentioning the latter for progress tracking.
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 describes when to use this tool (for requesting certificates), including the two-phase commit and type-specific requirements. However, it does not explicitly state when not to use it (e.g., for deletion) but the sibling context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (destructiveHint=true), and description adds 'Two-phase commit', a critical behavioral trait not in annotations. Provides additional context about the commit pattern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, front-loaded with purpose. 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?
Complex tool with two-phase commit and preconditions, but description covers key points. Output schema exists, so return values need not be described. Adequately complete for an agent.
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?
With 100% schema coverage, baseline is 3. Description adds value by explaining the confirmation_token's role as 'token from the prior plan response' and reinforces target URI requirement. Enhances understanding 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?
Clearly states 'Create a new short URL pointing to a long target', distinguishing it from sibling list/quota tools. The 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells to use infomaniak_short_urls_quota first for headroom check, providing clear context on when to use this tool and when to check alternatives.
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 declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral details: each domain requires 2 sequential API calls, default max_domains=20 keeps execution under ~30s, and the overall bulk-read nature is explained. 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 extremely concise: two sentences that clearly state the purpose and usage context. Every word adds value, with no filler or repetition of schema details. The front-loaded structure immediately conveys the tool's core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are covered), three optional parameters with full schema descriptions, and detailed annotations, the description is complete. It covers purpose, behavioral traits (API calls, timing), and parameter tuning cues, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline clarity. The description adds meaning beyond the schema by explaining the execution time implication of `max_domains` and providing an example for `filter_contains`. This additional context helps the agent make informed parameter choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Bulk-read' of every domain owned by an account, returning DNS record counts and DNSSEC status. It distinguishes from sibling tools like `infomaniak_list_domains` or `infomaniak_dns_list_records` by focusing on a multi-domain audit with specific metrics.
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 marks the tool as 'useful for spot-checking large fleets', providing clear context for when to use it. However, it does not offer explicit guidance on when not to use it or mention alternatives, leaving some ambiguity for the AI agent.
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 explicitly mentions 'Two-phase commit', which is critical behavioral information beyond annotations. Parameter descriptions further detail the two-step process: omit token for plan, pass token for deletion. Annotations already indicate destructive and idempotent, but the description adds workflow 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 main description is only two short sentences, directly stating purpose and key behavioral trait. No unnecessary words, and the most important information 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?
The main description is brief but combined with parameter descriptions and annotations, the tool definition is quite complete for an agent. The two-phase process is fully explained in the confirmation_token parameter. Minor improvement would be to add the two-phase mention in the main description, but current level is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have detailed, actionable descriptions in the input schema, such as 'Discover via infomaniak_list_mail_hostings' for mail_hosting_id and 'List existing rules with infomaniak_list_redirections' for name. This adds significant meaning beyond type/format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a mail redirection', specifying the action and resource. It distinguishes from sibling tools like 'infomaniak_create_redirection' and 'infomaniak_list_redirections'.
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?
Parameter descriptions provide usage guidance: 'name' advises listing existing redirections first, and 'confirmation_token' explains the two-phase commit workflow. However, the main description lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.
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 indicate destructive and idempotent behavior. The description adds critical details about the two-phase commit, grace period, and FTP deletion, which go beyond annotations and enhance 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?
Two concise sentences that front-load the core purpose and key behaviors. Every word serves a purpose 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?
Given the annotations and output schema, the description provides all necessary context: the two-phase commit, required parameters, and consequences (FTP deletion). 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?
Schema coverage is 100%, so the description adds value by clarifying the confirmation_token's role in the two-phase process. This is useful context beyond 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 tool deletes a site from Infomaniak web hosting, using specific verbs and resources. It distinguishes from siblings like 'infomaniak_create_site' by focusing on deletion.
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 and warns about wiping the FTP directory. It doesn't explicitly mention when not to use or provide alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral context beyond these by noting it is 'significantly cheaper than calling list_hostings + list_sites manually because it short-circuits on the first match.' This provides valuable performance insight without 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 very concise: two sentences that cover purpose, return structure, usage guidance, and performance note. Every part adds value without redundancy. It is front-loaded with the core action and result.
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 and the presence of an output schema, the description is complete. It explains what the tool does, when to use it, what it returns, how parameters work, and why it's efficient. No gaps remain for an AI 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enriches parameter semantics: for 'domain', it accepts root/sub-domains and Punycode; for 'account_id', it explains the optionality and scope of lookup (scanning all accounts vs. restricting). This goes beyond the 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 tool's purpose: to locate a domain in the Infomaniak account tree. It specifies the verb 'locate', the resource 'domain', and lists the returned fields (account_id, hosting_id, etc.). This distinguishes it from sibling tools like list_hostings and list_sites, which are more expensive alternatives.
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 the tool: 'Use this BEFORE any tool that requires hosting_id + site_id (get_certificate, request_certificate, list_databases, etc.) when you only know the domain name.' It also contrasts with manual alternatives, making the usage context very 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?
Discloses behavioral traits beyond annotations: GET runs immediately, POST/PUT/PATCH/DELETE follow a two-phase commit pattern, and manager-private endpoints are inaccessible. 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 'Escape hatch', no redundant words. Each sentence adds critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic escape hatch with an output schema, the description covers purpose, behavioral pattern, and limitations. Could be slightly more explicit about required parameters for different methods, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains the behavioral context for method (GET immediate, others two-phase commit) and implies usage of confirmation_token. However, it doesn't detail the path pattern or query object beyond what 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 it's an 'escape hatch' for any public Infomaniak API endpoint when no dedicated tool exists. It distinguishes itself from sibling tools by specifying it covers undocumented endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'when no dedicated tool exists' and warns that manager-private endpoints are not reachable and to 'use a typed tool instead'. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds authentication requirement (SASESSION cookie), privacy level (Manager-private), and lists returned fields, supplementing the safe 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: first covers purpose and output, second covers usage. 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?
For a zero-parameter read tool with output schema, the description fully explains what it returns and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, schema is empty. Description compensates by enumerating all returned fields, adding meaningful 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?
Description clearly states it retrieves the authenticated user's identity with specific fields listed. Distinct from sibling tools like infomaniak_get_my_security.
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 recommends using this tool first to confirm user and account context. No exclusions but strong usage guidance.
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-mcp-agent MCP server](https://glama.ai/mcp/servers/Mogacode-ma/infomaniak-mcp-agent/badges/card.svg)](https://glama.ai/mcp/servers/Mogacode-ma/infomaniak-mcp-agent)

Score Badge

Copy to your README.md:

[![infomaniak-mcp-agent MCP server](https://glama.ai/mcp/servers/Mogacode-ma/infomaniak-mcp-agent/badges/score.svg)](https://glama.ai/mcp/servers/Mogacode-ma/infomaniak-mcp-agent)

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/Mogacode-ma/infomaniak-mcp-agent'

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