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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), lowering the burden on the description. The line 'Discovery does not grant execution' adds genuinely useful behavioral context about side effects, but pagination behavior and the shape of returned metadata are left unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no filler; the purpose leads and the caveat follows. Every clause carries information.

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

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

With no output schema, the description should ideally sketch what the catalog returns and how pagination works, which it does not. It does establish the discovery-only nature of the operation, which is the most important thing an agent needs, but the 0% parameter coverage leaves gaps.

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

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

Schema description coverage is 0% across four parameters, so the description carries the full burden and mostly fails it. The phrase 'by product/method' loosely maps to the product and method filters, but limit and offset receive no explanation of ordering, defaults, or page-size behavior.

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

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

The description gives a specific verb and resource ('Browse all public API metadata by product/method'), which is clearly a discovery/catalog operation distinct from the search, read, and status siblings. It stops short of naming those siblings or explicitly contrasting the tool with them, so it is clear but not fully differentiated.

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

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

The only guidance is the caveat 'Discovery does not grant execution', which clarifies an outcome but not when to pick this tool over infomaniak_search or infomaniak_read. There are no conditions, prerequisites, or exclusions stated, leaving the agent to infer the use case from the word 'browse'.

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

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the return shape (source, retrieval time, steps/links), the presence of explicit pagination, that no provider token or browser cookies are required, and a guardrail against bypassing denied scopes, pending approvals or locks. With no output schema, this carries useful weight, though it does not explain how pagination terminates or how next_offset relates to expected_sha256.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and resource in the first sentence, followed by return-shape and then policy constraints, with essentially no filler. The final sentence reads as a guardrail more than a behavioral fact about this tool, but it is short and relevant.

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

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

For a read-only fetcher with no output schema, the description supplies the essentials: what is fetched, what is returned, that paging exists, and that no credentials/cookies are involved. The remaining gap is operational detail on pagination continuation, which an agent would otherwise have to infer from the parameter names.

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

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

Schema coverage is only 50%: url and expected_sha256 are documented, while offset and max_chars have no descriptions anywhere except name, default and bounds. The description's mention of "explicit pagination" signals that paging exists but does not define offset/max_chars semantics or the next_offset round-trip, so it only partially compensates for the coverage gap.

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

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

States a concrete verb ("Fetch") and a precise resource ("current official help article or developer API reference"), which an agent can distinguish from the sibling search tool by the verb alone. It stops short of naming infomaniak_docs_search as the discovery counterpart, so differentiation is implied rather than explicit.

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

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

Usage context is implied rather than spelled out: the schema's url field says the URL comes "from search", and the description adds a fallback path ("Use the guide with your own authorized browser/computer tools when an API capability is missing") plus prohibitions on bypassing scopes/approvals/locks. There is no direct when-to-use-this-vs-siblings statement such as 'call docs_search first to obtain the URL'.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the bar is lower. The description still adds genuine value: a hard privacy constraint against customer identifiers, addresses and credentials in queries, plus the caveat that returned docs do not imply permission or execution coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the capability front-loaded and the safety constraint immediately after; no filler. The second sentence packs two distinct ideas, but neither is expendable.

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

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

For a read-only search tool with no output schema, the definition covers corpus scope, query hygiene and the nature of results. Minor omissions remain around result format and the limit/language parameters, but nothing critical to correct invocation is missing.

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

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

Schema coverage is only 25%, but the description partially compensates by mapping the two corpora (help guides vs. live API index) onto the 'source' choice and by constraining what belongs in 'query'. It says nothing about 'limit' or language selection, leaving part of the gap unaddressed.

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

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

The description gives a specific verb and clear resource scope: searching official Infomaniak help guides (Manager/browser tasks) or the live developer API index. This tells an agent what corpus it hits, though it never names the nearest siblings (infomaniak_search, infomaniak_docs_read) to differentiate itself explicitly.

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

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

Usage is implied through 'public feature terms only' and the closing note that results are documentation rather than permission or execution coverage, which steers away from using it for account actions. However, there is no explicit statement of when to prefer it over infomaniak_search or infomaniak_docs_read.

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

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.

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.

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.

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.

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.

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.

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

Annotations already establish the safe read-only, idempotent, open-world profile, so the bar is lower. The description adds genuine behavioral context beyond them: catalogue entries may be missing and reviewed schemas are fetched lazily, which tells the agent results can be partial and a follow-up read may be needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, and the core purpose is front-loaded ahead of the caveats. The second sentence is slightly telegraphic ('load on demand') but earns its place by conveying the lazy-loading behavior.

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

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

No output schema exists, so the description should ideally clarify what a search result contains (operation identifiers usable with infomaniak_read), which it does not. With annotations covering safety and only three simple params, it is minimally adequate but leaves the result shape and workflow linkage underspecified.

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

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

Schema description coverage is 0% across three parameters. The phrase 'catalogue entries may be unavailable' loosely gestures at include_unavailable, but limit and query are entirely unexplained and no formats, defaults, or range guidance are given in the description.

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

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

States a clear verb+resource: 'Discover public API operations' — an agent knows this is a discovery/search tool. It implicitly distinguishes itself from infomaniak_read (which fetches a reviewed schema) but never names siblings explicitly.

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

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

'Reviewed schemas load on demand' hints at a search-then-read workflow, suggesting this is the entry point before infomaniak_read. However, it never states when to use this over infomaniak_catalogue or infomaniak_read, leaving the routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only vague nouns ('connection policy', 'reviewed capabilities') without saying what state is inspected, whether it performs a live connection check, or what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no padding, so nothing needs trimming. Its brevity, however, comes at the cost of substance rather than being earned by density.

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

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

For a no-parameter, read-only diagnostic with no output schema, the description should state what the status payload covers. It hints at three areas but leaves the actual returned information and the meaning of 'coverage' unexplained.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

The verb 'check' and the objects 'catalogue coverage, connection policy and reviewed capabilities' gesture at a diagnostic/status resource, but the phrasing is jargon-heavy and never says plainly what the tool reports or returns. It also does not distinguish itself from siblings infomaniak_catalogue and infomaniak_search, which plausibly overlap with 'catalogue coverage'.

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

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

No indication of when this tool should be chosen over infomaniak_search, infomaniak_catalogue or infomaniak_read, and no preconditions or exclusions are given. The agent must guess at the intended trigger.

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