Infomaniak AI

infomaniak_read

Read-onlyIdempotent

Perform reviewed read-only queries on Infomaniak account resources, including domains, DNS, and mail diagnostics, within granted scopes.

Instructions

Call a reviewed read within this connection's account/resource grants.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operation": "<operation>"
    },
    "name": "infomaniak_read"
  }
}

Input Schema

Name	Required	Description	Default
`arguments`	No
`operation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 20, 2026

TDQS

C2.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that operations must be 'reviewed' and are bounded by the connection's account/resource grants, which is genuine extra context about authorization scope, but it omits what happens on an ungranted or non-reviewed operation.

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?

A single sentence with no filler, which is structurally clean. However, it is abstract and jargon-heavy ('reviewed read', 'grants') rather than genuinely front-loading the essential information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generic dispatcher with a free-form required 'operation' string and a nested, free-form 'arguments' object at 0% schema coverage and no output schema, the description is far too thin. It should explain how operations are identified and what argument shapes are expected, especially alongside an infomaniak_catalogue sibling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for both parameters, so the description carries the full burden and largely fails: it never explains what values 'operation' takes, how they are discovered, or how 'arguments' should be shaped for each operation. Only the grant-scoping hint gives any signal about valid operation values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description restates the tool's own name ('read') and adds only a vague scope phrase, 'within this connection's account/resource grants.' It never says what resource is being read or how it differs from siblings like infomaniak_search or infomaniak_catalogue. An agent cannot tell what this tool actually retrieves.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of the sibling tools that likely cover overlapping ground (search, catalogue, status). The word 'read' faintly implies a read path, but nothing tells the agent when this is preferable to infomaniak_search.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server