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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the 'Touches: reads only' line is mostly redundant. However, the Bounds line adds real behavioral facts the annotations cannot convey: a three-request cost against Odoo.sh and the not-found behavior for older builds. That is meaningful edge-case disclosure.

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?

Tight and front-loaded, with the Returns/Touches/Bounds labels making it scannable. The labeled fragments are slightly telegraphic, but every sentence 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?

An output schema exists, so the return-value line is optional rather than necessary. The description still covers the read-only nature, the request cost, and the default-build behavior, leaving only parameter identifier formats unaddressed.

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%, so the description carries the load, and it does explain build_id (build number, defaults to latest). Project and branch are only implied by the phrase 'of a branch of a project' with no format or identifier guidance, so a third of the parameter meaning is still missing.

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 specific verb and resource ('Read one build of a branch of a project') and immediately scopes the cardinality to a single build, which implicitly separates it from list_builds. It does not name list_builds or wait_for_build explicitly, so sibling differentiation is left partly to inference.

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 description gives the key conditional: pass a build number or get the latest when none is provided. That is genuine usage guidance for the optional build_id, but there is no statement of when to prefer this over list_builds or wait_for_build, nor any prerequisites.

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 readOnly, idempotent, non-destructive and open-world, and the description reinforces this with 'Touches: reads only'. The genuinely additive content is the 'Bounds' line: two requests to Odoo.sh and a hard cap of 10 firewall entries, which is cost/cardinality context the annotations do not provide. It does not mention auth/permission requirements, so it falls short of a 5.

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

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

The Returns/Touches/Bounds labeling is well-structured and front-loads the resource definition before the supporting facts. The opening sentence is long and slightly overloaded, and 'Touches: reads only' partly restates the readOnly annotation, so it is not maximally tight.

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?

An output schema exists, so explaining the return payload is not strictly required, and annotations carry the safety profile; the description still adds useful operational bounds (request count, 10-entry cap). Only the meaning/format of the `project` input is left unaddressed.

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 the single required `project` parameter, so the description must compensate. It only indirectly hints at the identifier form by saying the result contains 'the project's name', but gives no format, type, or accepted value guidance for the input. Partial compensation at best.

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?

Names a specific verb (Read) and resource (firewall of a project) and scopes it precisely: the public IPv4 addresses/ranges reaching production and staging builds via SSH and PostgreSQL. None of the siblings (get_session, list_projects, list_branches, list_builds, get_build, wait_for_build, read_log) overlap with this resource, so the boundary is unambiguous.

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 description conveys the domain in which the tool is relevant (checking which IPs can reach builds), which implies when an agent would reach for it, but it never states an explicit when-to-use or when-not-to-use condition, nor does it point to any alternative or prerequisite. No sibling covers the same ground, so the omission is mild, but guidance is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the request bound (one call to Odoo.sh, zero when no session exists), which tells the agent about cost and side-effect-free fallback behavior.

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?

Nicely front-loaded with labelled sections (Returns/Touches/Bounds) and each line is short. There is mild redundancy: the opening sentence's 'where it came from and who it belongs to' is restated as 'its source, its user' in the Returns line.

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?

An output schema exists, so enumerating return fields is optional padding rather than required content. With annotations carrying the safety profile and the bounds line carrying the operational cost, the only real gap is the absence of guidance on when this check should be invoked relative to the sibling tools.

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. No parameter claims are made or needed.

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 specific verb (Report) and resource (Odoo.sh session) with the exact fields surfaced: availability, source, user, and seconds until max age. This is clearly separable from the build/branch/project/log siblings, none of which touch session state.

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 only implied — an agent can infer this is a diagnostic/authentication-state check to run before other Odoo.sh operations. There is no explicit when-to-use, no prerequisite statement, and no named alternative or condition for skipping it.

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 readOnly/idempotent/non-destructive, and the description goes well beyond them with cost bounds ('two requests to Odoo.sh') and a hard result cap ('200 at most'), which the schema does not state. It also discloses truncation behavior, giving the agent real operational context.

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

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

Four short labeled sentences (Returns/Touches/Bounds) with the purpose front-loaded and zero filler; every clause carries information an agent can act on.

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 list tool with an output schema, the description covers purpose, input semantics, cost bounds and truncation, which is nearly everything needed. It omits only edge behavior such as what happens when the project name does not match.

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%, so the description must compensate, and it does: it clarifies that 'project' is given by name and that 'limit' defaults to 50 with a 200 maximum (the max is absent from the schema). It stops short of format/case details for the project name, so not a full 5.

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 states a specific verb (List) and resource (the branches of a project) plus scope (with the stage each sits in), which cleanly separates it from siblings like list_projects and list_builds even though they are not named.

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 only implied: it tells the caller a project name is required, which suggests use when you know the project, but there is no explicit when-to-use, when-not, or alternative routing. Since no sibling lists branches, the routing risk is low, keeping this at a minimum-viable 3.

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 readOnly/idempotent/non-destructive/openWorld, so the 'Touches: reads only' line is redundant. What earns credit is the cost model ('three requests to Odoo.sh') and especially the caveat that the backend has only been observed to return 4 builds, so older data is out of reach regardless of `truncated`.

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?

Labeled sections ('Returns:', 'Touches:', 'Bounds:') front-load the primary action and then answer expected agent questions in order. Dense but every clause carries information; only the 'reads only' line is wasted against the annotations.

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?

An output schema exists, so return values need not be spelled out, yet the description still flags `truncated` and its unreliable semantics — the single most important thing an agent must not misread. Cost, bounds and the reachability limit are all covered for a moderate-complexity read tool.

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%, so the description carries the burden, and it does add real meaning: `limit` defaults to 4 and caps at 20, which the schema does not state. Project and branch are only implied ('a branch of a project') with no identifier format guidance, which is the remaining 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 specific verb and resource plus scope and ordering: 'List the latest builds of a branch of a project, newest first, with their status, result and commit.' This cleanly distinguishes it from sibling reads like list_projects, list_branches and get_build.

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 by the scope rather than stated; there is no explicit guidance on when to pick this over get_build or wait_for_build. It does add one genuinely useful decision cue — that older builds are unreachable even when `truncated` says otherwise — which nudges it above a bare 2.

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 and openWorldHint, so 'reads only' is largely redundant. However, the 'Bounds' line adds genuinely new behavior: a single request to Odoo.sh and a hard cap of 200 items (default 50), which the annotations do not express.

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 purpose, then clearly labelled Returns / Touches / Bounds blocks. Every sentence carries information; nothing is padded or restated for its own sake.

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 an output schema present, the description need not enumerate return fields, yet it still names the key fields and the `truncated` flag. Combined with the sequencing rule and request bounds, nothing an agent needs to invoke this tool 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 0% for the single `limit` parameter, so the description must carry the semantics. It does: 'limit items, 50 by default and 200 at most' supplies both the default and the upper bound, with only the units/meaning of 'items' left implicit.

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 specific verb and resource ('List the Odoo.sh projects the user can reach') and implicitly scopes it against siblings like list_branches and list_builds, which operate on a project rather than the project list. An agent can distinguish this tool without opening any schema.

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?

Gives an explicit ordering rule: 'Call it first: every other tool takes a project by its name.' This tells the agent exactly when this tool is required relative to every sibling tool, which is the only routing decision that matters for a discovery/list call.

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 annotations (readOnly/idempotent/non-destructive already cover safety), the description adds real operational context: request bounds (seven, or ten without `kind`), line limits (default 100, max 500), the one-mebibyte read window, the 65536-byte JSON cap, and truncation signaling. It also carries a prompt-injection warning that `untrusted_lines` are third-party output to be treated as data, which the annotations cannot convey.

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?

The content is dense but front-loaded with the core purpose, then organized into clear Return, Touch, and Bounds blocks. Every clause carries information, though the prose is wordier than strictly necessary for the bounds figures.

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 filtered-read tool with 6 params, 0% schema coverage, and an output schema, the description fills every gap an agent needs: default log selection, filtering semantics, hard limits, truncation, and the security caveat on returned lines. Nothing required to call it correctly 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 description coverage is 0%, so the description must compensate, and it does for the non-obvious parameters: `kind` defaults to install/odoo, `contains` matches literally rather than as a pattern, and `lines` defaults to 100 with a 500 cap. `project`, `branch`, and `build_id` semantics are largely self-evident and only lightly addressed.

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 states a specific verb and resource ('Read the last lines of a log of a build of a branch of a project') and immediately scopes it to a specific build number or the latest. It also defines the default log selection (install if present, otherwise odoo) and the `contains` filter, so an agent can distinguish this read tool from `get_build` and `wait_for_build` without opening the schema.

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?

It clearly explains selection conditions: without `kind` you get install-then-odoo, `build_id` selects a specific build versus latest, and `contains` filters literally (explicitly not a pattern). No sibling is named as an alternative, which keeps it from a 5, but usage conditions are otherwise explicit.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description still adds substantial behavior: timeout defaults and hard cap (30/50, longer when Odoo.sh is slow), request budget (six requests, one socket, one request every 3 seconds while waiting on a commit), and the `timeout_capped` outcome. This is well 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.

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

Purpose is front-loaded and there is no filler, but the opening sentence is a dense run-on ('the build of that number, or the latest one... the build of that commit, once the branch has one') that forces re-reading. The value is there; the structure could be substantially tightened.

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?

An output schema exists, so return fields need not be restated, yet the description usefully adds the polling/interruption contract (finished=false, next_step, timeout_capped). Bounds and rate-limit behavior are covered. Minor gaps around the project/branch parameters and the build_id-vs-latest ambiguity keep it from a 5.

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%, so the description must carry parameter meaning, and it largely does: `timeout` (30 default, 50 max), `commit` (first 7-64 digits of a hash, selected once the branch has a build), and `build_id` (a specific build number or the latest). `project` and `branch` are left undifferentiated, keeping it from a 5.

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 states a specific verb and resource up front: waiting for a build of a branch/project to finish, bounded by a timeout, with commit/build_id variants. It is clearly distinguishable from the read-only siblings get_build/list_builds by its blocking/polling semantics, though it never names an alternative tool.

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?

It gives a concrete usage scenario ('give it right after a push, when the latest build is still the previous one') and clarifies the polling contract: an unfinished build is not an error, `finished` is false, and `next_step` instructs the agent to call again. It stops short of explicitly contrasting with get_build or stating 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.