Eurobase

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

Adds substantial context beyond the annotations: name doubles as hostname, environment is non-secret only and requires env:write, the conflict check happens before any project is created, and the call returns once the deployment is accepted rather than after the build. It also explains idempotency replay/resume vs. refusal on mismatched input, which the idempotentHint alone does not 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?

One dense paragraph, front-loaded with the create-attach-deploy sequence and followed by constraint and idempotency details. Every sentence carries information, though the run-on length slightly hurts scanability.

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 and the description covers the return point ('returns once the deployment is accepted, before the build runs') plus most parameter and failure semantics. The remaining gap is rootDirectory and any indication of what the returned project/deployment object contains.

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?

With 0% schema description coverage the description carries the load and covers name format, branch defaulting to the repo default, environment value restrictions, and organizationId provenance. rootDirectory is never mentioned, leaving one of the seven parameters undocumented anywhere.

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+resource pair ('Creates a project') and immediately disambiguates the side effects: attaches a repository/branch and starts the first deployment. This clearly separates it from eurobase_deploy, eurobase_redeploy and eurobase_list_projects.

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 concrete conditions and prerequisites: organization IDs come from eurobase_whoami, secrets must be set in the dashboard, and a repo/branch already bound to another project is refused before creation. It does not name sibling alternatives like eurobase_deploy for an existing project, so the routing guidance is strong but not exhaustive.

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?

The annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, and the description adds real context on top: the new release replaces the active one after rollout, the call returns before the deployment is live (async acceptance), and idempotencyKey replays return the same deployment. It does not explain what 'permitted' means operationally or what happens on a failed rollout.

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 tight sentences, each carrying distinct information: source selection, replacement semantics, return timing, and idempotency. No restatement of the name or title, and the key scoping facts are front-loaded.

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 mutation tool with four parameters and no output schema, the description covers the important asymmetry an agent needs: it returns before the deployment is live, so status must be checked via eurobase_get_deployment or eurobase_list_deployment_events. The remaining gap is precondition detail around what 'permitted' means and failure behavior.

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%, so the description must carry the load, and it does explain the branch/commitSha semantics (default is the latest commit of the configured branch) and the replay guarantee tied to idempotencyKey. projectId is only implied via 'a permitted project,' leaving its format and permission semantics to the pattern constraint in the schema.

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 opens with a specific verb+resource pair ('Builds and deploys a permitted project from its GitHub repository') and clarifies the source selection (configured branch, explicit branch, or commitSha). It is clearly a deploy action, but it never names how it differs from nearby siblings such as eurobase_redeploy, eurobase_rollback, or eurobase_promote.

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 the source-selection sentence and the word 'permitted,' but there is no explicit guidance on when to choose this over eurobase_redeploy or eurobase_rollback. The agent must infer the boundary from sibling names rather than the text.

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 readOnly, idempotent, closed-world and non-destructive behavior. The description adds real context beyond them: the diagnosis is deterministic and derived from recorded evidence (not a live probe), and recovery suggestions are inert and execute nothing — a valuable warning for an agent tempted to act on them.

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, no waste, with the core purpose and the most dangerous misreading (that suggestions execute) front-loaded.

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?

There is no output schema, so the description should convey what the diagnosis returns; it mentions recovery suggestions but not the diagnosis content itself (status, failure reasons, evidence fields). For a two-required-param read tool with rich annotations this is adequate but incomplete.

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 adds nothing about projectId or deploymentId. The schema's regex patterns at least reveal the prj_/dep_ prefixes, but neither field's semantics or relationship is explained anywhere.

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 (read/diagnose) and resource (deployment), and the phrase 'from recorded deployment evidence' distinguishes it from a live probe. It does not name a sibling such as eurobase_get_deployment or eurobase_list_deployment_logs, so the 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?

No when-to-use or when-not guidance, and no alternatives are named. An agent can infer this is for diagnosing a deployment after a failure, but nothing says whether to prefer it over get_deployment or the log/event listing tools.

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, closed-world, so the description is not needed for the safety profile. It adds real, non-duplicated context: the returned data is a recorded snapshot rather than a live probe, which tells the agent about data freshness and that a stale or stopped deployment may still report state here. Return contents and error behavior are not described.

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 the read scope first and the behavioral exclusion second. No filler, nothing repeated from the title or 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?

For a two-required-parameter getter with no output schema, the description should at least signal what 'recorded deployment state' contains (status fields, the evidence timestamps, maybe build metadata). It conveys the freshness caveat but leaves return shape and ID scoping unspecified.

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% and the description says nothing about projectId or deploymentId, so it does not compensate for the coverage gap. The only help is structural: the patterns (^prj_..., ^dep_...) tell an agent which ID form each slot takes, but the parent/child relationship between project and deployment is left unstated.

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 ('Read') and resource ('recorded deployment state and evidence timestamps'), which is more precise than a plain 'get'. It does not name the sibling it is distinct from (e.g. eurobase_diagnose_deployment), so the boundary must be inferred from 'does not probe the runtime'.

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 clause 'does not probe the runtime' implies that live/health diagnostics belong to a sibling such as eurobase_diagnose_deployment, but no alternative is named and no when-to-use condition is stated explicitly. The usage signal is present only by negation.

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 cover read-only, idempotent, non-destructive, closed-world behavior, yet the description still adds real value: source code is never returned, and the data is recorded state that does not probe the route. That last clause prevents an agent from misreading the result as a live health check. It omits error/not-found behavior for unpermitted projects.

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 filler; the permission scope, returned payload, and the source-code exclusion all earn their place. The colon-chained list is slightly dense but remains scannable.

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 carries the return shape by enumerating what is included and explicitly what is not (source code), plus the rollback verdict and targetDeploymentId. Missing only failure-mode or permission-error behavior for a tool gated on permitted projects.

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 the burden. It implies projectId must be a project the caller is permitted to access, and that functionId selects the single function, but it adds no ID format or scoping detail beyond what the regex patterns in the schema already enforce.

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 Function of a permitted project') and enumerates the fields returned: definition, status, route/product URL, deployments, and rollback eligibility. This clearly distinguishes it from the list-style siblings such as eurobase_list_functions and from eurobase_get_deployment.

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?

Signals the read-one-function context and explicitly cross-references eurobase_rollback_function as the tool this output informs, which helps an agent choose the next call. It stops short of stating when not to use this tool (e.g. use eurobase_list_functions to enumerate).

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 closed-world, so the safety profile is covered. The description adds one genuinely new behavioral fact — "permitted" implies per-account authorization scoping and that unpermitted IDs will fail — but says nothing about error behavior or what a returned project 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?

One sentence, front-loaded with the verb and resource, zero redundant content. Nothing could be removed without losing 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?

For a single-parameter read with full annotation coverage and no output schema, the description is nearly sufficient. The remaining gap is that an agent gets no sense of what a project object contains, though the definition's simplicity makes this a minor omission.

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% and the single parameter's format lives only in the JSON Schema pattern (^prj_...). The description compensates partially with "exact project ID", clarifying that lookup is an exact-match, not fuzzy or prefix, match.

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?

Specific verb ("Read") plus resource ("one permitted project") and the key qualifier that lookup is by exact ID. It implicitly contrasts with eurobase_list_projects ("one" vs. many) but never names the sibling, so it stops short of a 5.

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: "by its exact project ID" tells the agent it must already hold an ID, which suggests list_projects is the way to discover one, but no when/when-not or alternative is stated explicitly.

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, so safety is covered; the description goes further by disclosing that only *retained* logs are counted (retention window affects results), that the default window is 24h, that from/to is a half-open [from,to) interval, and that counts are log rows rather than request totals. It does not discuss what happens for an inaccessible or unknown project, or any limits on result cardinality.

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 dense sentences, front-loaded with the verb and scope, and the 'not request totals or runtime health' disambiguation earns its place. The opening sentence is long and packs the return fields and the time-window options together, which slightly reduces scannability, but there is no filler.

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?

There is no output schema, yet the description enumerates what comes back (counts by level, category, asset type, status class; newest/oldest observation; p95 latency), which is exactly the burden it must carry. Combined with the time-window rules and the retention caveat, an agent has enough to call it correctly and interpret the result for this read-only aggregation 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 full burden and does add real meaning: timeRange has a stated default (24h), from/to are described as an alternative exact window with half-open semantics, and level/category are explained as narrowing filters over what is counted. projectId gets no explanation, and the mention of 'asset type' and 'HTTP status class' could be misread as input parameters when they are only output groupings.

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 opens with a specific verb and resource ('Count the retained logs of a permitted project') and immediately enumerates the aggregation dimensions (level, category, asset type, HTTP status class) plus the returned metrics (newest/oldest observation, p95 latency). The closing clause 'not request totals or runtime health' actively separates it from usage/health siblings, and 'count' vs the sibling 'list_project_logs' is unmistakable.

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 clear usage context: aggregate counts over a relative timeRange or an exact [from,to) window, with level/category as narrowing filters. It also signals when NOT to use it ('not request totals or runtime health'), implicitly routing to the usage and health siblings. It never names the raw-row alternative (list_project_logs) explicitly, so the exclusion is inferred rather than stated.

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?

With annotations already declaring readOnlyHint and idempotentHint, the description adds meaningful behavioral context: the daily quota is a shared organization aggregate rather than project or historical usage, unavailable data is not zero, and reading quota does not reserve capacity or authorize deployment. These are valuable caveats beyond the structured annotations, though authentication, rate limits, and response shape are still not covered.

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 description is front-loaded with the core operation, followed by practical caveats about the month, quota aggregation, and unavailable data. The sentences are mostly efficient, though the reference to 'the same evidence as Eurobase Usage' is somewhat vague and the caveats could be tightened slightly.

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 two-parameter read-only usage tool with rich annotations and no output schema, the description provides enough behavioral context to call it correctly, especially around quota semantics and missing data. It stops short of describing the return shape or exact cost/usage fields, which would help compensate for the absence of an output schema.

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 for both parameters. It explains that 'month' is YYYY-MM with the current month as default, which adds useful meaning beyond the schema pattern. For 'projectId' it only implies that the selected project is identified, leaving the required project identifier largely undocumented beyond the schema's format pattern.

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 uses a specific verb and resource: 'Read the selected project monthly usage and cost state.' It clearly scopes the operation to project-level billing/usage and separates the daily deployment quota from project usage. It does not explicitly name or distinguish itself from sibling tools such as eurobase_get_project, so it falls short of a 5.

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 implies when to use the tool by explaining that it reads monthly usage and cost state, and it clarifies the default month behavior. However, it does not explicitly state when to choose this tool over alternatives like eurobase_get_project or eurobase_whoami, nor does it provide clear when-not guidance.

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 closed-world, so the safety profile is fully covered. The description only adds that the lookup is by exact ID on stored records; it says nothing about failure behavior when the ID is absent or about return shape.

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 that identifies resource, cardinality, and lookup key with no padding. Nothing in it is wasted.

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 and annotated safety hints, the main gap is the undocumented projectId requirement and the absence of any note on what happens when the URL ID is not found. Adequate but noticeably incomplete for a two-parameter lookup.

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 only clarifies urlId is an exact URL identifier rather than a URL string. projectId, a required parameter, is never mentioned, leaving half the inputs undocumented.

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 recorded project URL') and scopes it to a single record, which implicitly separates it from the sibling list_urls. It does not name any sibling explicitly, so differentiation is left 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?

'Read one ... by its exact URL ID' implies the single-record lookup case versus listing, and 'recorded' hints the record must already exist. There is no explicit when-to-use/when-not statement or named alternative.

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 closed-world, so the safety and idempotency profile is fully covered by structured data. The description only adds the negative scope statement; it says nothing about auth needs, rate limits, or what "availability" looks like on the wire.

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, positive statement first then the exclusion, with no filler. Every clause carries information an agent would otherwise have to infer.

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 parameters and rich annotations, the definition covers the essentials: scope, and what the tool does not cover. Since no output schema exists, a brief note on what "availability" returns (status flag vs. detail payload) would close the last gap.

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 the baseline of 4 applies. There is no parameter semantics to add and the description correctly does not invent any.

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 API availability") and immediately excludes the domain covered by the surrounding project/runtime tools. An agent can tell this is a global liveness check rather than a per-project inspection 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?

The sentence "Does not inspect a project or runtime" is an effective when-not clause that steers the agent toward the project/deployment siblings for anything scoped. It stops short of naming a specific alternative or saying when it should be called (e.g., before a first operation), so it sits just below explicit routing guidance.

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, and non-destructive behavior, while the description adds useful traits: chronological ordering by observedAt, the meaning of truncation, and the content of event text. It still omits pagination/cursor expectations and permission or rate-limit context, so it is strong but not complete.

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 definition is three short sentences, front-loads the core read operation, and every sentence adds relevant ordering, truncation, or content context. There is no filler.

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 three-parameter tool with no schema parameter descriptions and no output schema, the description leaves essential invocation semantics and return-shape details uncovered. It adds useful behavioral context around truncation and event text, but not enough to fully guide correct use.

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% and the description never mentions projectId, deploymentId, or limit. 'Latest bounded' hints at a bound but does not explain the limit parameter or the required identifiers.

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 names a read operation and resource ('lifecycle events') and adds ordering, but 'bounded lifecycle events' is jargon and it never explicitly states the deployment/project scope. It also does not distinguish this from sibling tools such as eurobase_list_deployment_logs or eurobase_diagnose_deployment.

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 explicit when-to-use guidance, prerequisite, or alternative named. An agent must infer from the tool name that this is for deployment events rather than logs, diagnosis, or deployment details.

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 the safe read-only, idempotent, closed-world profile, so the description is free to add real value — and it does: retention-window limits, the mutual exclusion of tail and cursor, ordering semantics (observedAt for tail vs delivery order for cursor pages), and the caveat that empty results indicate no retained matches rather than runtime health. What is missing is default page size behavior and how much data a request can return.

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?

One dense paragraph, front-loaded with what the tool reads and filtered by, followed by pagination and semantics. Every clause carries information; the only cost is that the tail/cursor/pagination clauses run together as a single long sentence that is harder to parse than it needs to be.

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 9-parameter, no-output-schema, zero-coverage read tool, the description covers filtering, pagination modes and result semantics well, but leaves the agent without limit/default-paging knowledge or any sense of the response shape. It is adequate to call correctly in the common case but not complete.

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 9 parameters, so the description must carry the load: it explains level, category, from/to format (UTC, exactly three fractional digits, half-open interval) and the tail/cursor constraint. But limit (1–100) and the projectId/deploymentId scoping are never mentioned, leaving roughly a third of the parameters documented only by their type and bounds.

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 opens with a specific verb and resource ('Read retained logs') and scopes it with the exact filters available (level, build/runtime category, time window). The deployment scoping comes from the tool name rather than the sentence, and no sibling (project logs, function logs, deployment events) is named to disambiguate when to reach for this one instead.

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?

Useful operational rules are given (tail=true cannot be combined with a cursor; cursor pages follow delivery order; empty means no retained matches). However there is no guidance on when this tool should be chosen over eurobase_list_project_logs, eurobase_list_function_logs or eurobase_list_deployment_events, and the 'optional ... (both required)' phrasing for from/to leaves the caller guessing whether the pair is mandatory.

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 that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful context by noting pagination ('one page'), retention ('retained deployment history'), and authorization ('permitted project'). It does not disclose ordering, default page size, cursor behavior, or retention limits.

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 description is a single front-loaded sentence with no filler or repetition. Its brevity is effective from a structure standpoint, even though more detail is needed elsewhere.

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 paginated list tool with no output schema and 0% schema description coverage, the description is too thin. It does not explain what a page contains, ordering, default and maximum page size, how to continue with cursor, or what retention actually means.

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 full burden for three parameters, but it only implies pagination through 'one page'. It does not explain the limit maximum of 100, how cursor should be reused, or why projectId is required, beyond the vague 'permitted project' wording.

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: reading one page of deployment history. It also scopes the operation to a permitted project. However, it does not distinguish this from sibling tools such as eurobase_get_deployment or eurobase_list_deployment_events and eurobase_list_deployment_logs.

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 guidance on when to use this tool rather than alternatives, no stated prerequisites, and no exclusions. The phrase 'for a permitted project' hints at authorization scoping, but it does not tell an agent how to decide between this and related deployment or log tools.

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 adds genuinely new context: results are paginated ('one page'), secrets are redacted (no values, ciphertext or fingerprints), and only current state is covered, not historical deployments. It still omits any note on permissions or how to advance pages.

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 sentences, front-loaded with the core action and scope, with exclusions following. Minor redundancy in the trailing 'Names are user-defined text', which adds little beyond noting there is no naming convention.

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 must describe the return shape; it does so only partially (names plus unspecified 'metadata', values redacted) and says nothing about response envelope or cursor advancement. Adequate to call the tool safely, but not sufficient for an agent to handle pagination confidently.

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 for projectId, limit and cursor. It only hints at pagination via 'one page' and at authorization via 'permitted project'; it never explains the limit cap of 100 or the meaning/format of the opaque cursor, leaving the two optional parameters effectively undocumented.

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 one page of current environment variable names and metadata') and bounds the return set by excluding values, ciphertext and fingerprints. It is clearly distinguishable from the mutation siblings set_env/unset_env, though it never names them or another read tool for comparison.

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 sentence 'This does not show the configuration of a historical deployment' implies a when-not condition, but it does not name the alternative tool (e.g. get_deployment) or spell out when an agent should prefer this listing. Usage is inferable rather than instructed.

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, so the safety profile is covered. The description adds the pagination behavior ('one page... newest first') and hints that error output is included, but says nothing about page-size defaults or how cursors behave.

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 first sentence is front-loaded and efficient. The second sentence ('Error text is recorded build and runtime output.') is grammatically unclear and its value is uncertain, weakening the structure.

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?

There is no output schema, and the description does not describe the returned deployment records, field contents, or how to continue paging with the cursor. For a 4-parameter paginated listing tool, this leaves meaningful 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%, so the description must compensate, yet it only implies pagination via 'one page'. It explains nothing about limit, cursor semantics, or the required projectId/functionId identifier expectations.

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 page of a Function's deployment history') plus ordering ('newest first'), which clearly signals a paginated function-scoped list. It does not explicitly differentiate from the project-level sibling eurobase_list_deployments, leaving some ambiguity.

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 guidance on when to choose this over eurobase_list_deployments, eurobase_list_deployment_events, or eurobase_diagnose_deployment, nor on prerequisites. The agent must infer the scope distinction from the tool name alone.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's added value is the behavioural detail: a 24h default window, chronological ordering, a hard row cap, an explicit 'there is no cursor' statement ruling out pagination, and the meaning of truncated=true. It also flags failure summaries as recorded runtime output, hinting at their provenance.

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 dense sentences, front-loaded with what is returned, followed by scoping default, ordering, and edge-case semantics. No filler; the only mild cost is the density of the enumeration in sentence one.

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 carries the return-shape burden and does so reasonably by naming the result fields and the truncated flag. It leaves minor ambiguity about whether chronological order is oldest-first with newest trimmed, which an agent might want spelled out.

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 has to compensate, and it partly does: it supplies a default of 24h for timeRange (not present in the schema) and explains limit as a row cap with chronological ordering. It says nothing about projectId/functionId, but their prefixed-ID patterns make them self-evident, so the gap is minor.

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?

Specific verb+resource (read Function invocations) with an explicit enumeration of the returned fields: outcome, HTTP status, durations, failure summary. It clearly distinguishes invocation records from the log-listing siblings by emphasising per-invocation outcomes, 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?

Usage is implied by the content it returns (use it to inspect per-invocation success/failure and latency), and the 24h default plus the truncated flag give context on scope. However, there is no explicit when-to-use/when-not and no routing guidance versus eurobase_list_function_logs or eurobase_list_function_deployments.

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 read-only, idempotent, non-destructive behavior, yet the description still adds substantial beyond-schema context: the 24h default window, chronological ordering, the meaning of truncated=true, the absence of a cursor, and the crucial point that an empty result means no retained matches rather than a healthy runtime. That is exactly the behavioral disclosure an agent needs and cannot get from structured fields.

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

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

Five short sentences, front-loaded with the core action and default, then the interpretation rules an agent most often gets wrong (truncation, no cursor, empty results). No filler or repetition of schema/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?

With no output schema, the description does the right job of explaining return semantics (truncated, empty, chronological, log contents are application output). Remaining gaps are minor: no indication of the fields present on each log row or the direction of 'chronological' when 'latest' is combined with a limit.

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. It supplies the timeRange default (24h), the row cap implied by 'at most limit rows', and mentions level as a narrowing filter, but it says nothing about projectId or functionId beyond their names, and gives no format details for timeRange or level beyond the enum in the schema. Partial compensation only.

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: reads retained Function logs scoped by timeRange and limit, in chronological order. It is distinguishable from eurobase_list_project_logs and eurobase_list_deployment_logs by the Function scope, though it never names those siblings explicitly to reinforce the difference.

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: the truncation guidance ('narrow timeRange or level') and the 'not runtime health' warning suggest a troubleshooting context, but there is no explicit when-to-use versus eurobase_get_project_log_summary, eurobase_list_project_logs, or eurobase_health. An agent must infer the routing itself.

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, closed-world, so the description adds real value beyond them: it states source code is never returned (a security/data-scope constraint) and that names are user-defined text. It also implies access scoping via 'permitted project'. Pagination behavior past the first page is not described.

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 efficient sentence front-loads the action and scope, then appends only the two facts that cannot be inferred from structured fields (no source code, free-text names). Nothing is redundant.

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 correctly enumerates the returned fields, which is the key gap it needed to fill. Remaining gaps are how to page forward (next cursor) and what happens for a project with no functions or insufficient permission — minor for a read-only list operation.

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 all three parameters, so the description must carry the burden. 'One page' implies limit/cursor pagination and 'permitted project' implies projectId, but neither the cursor semantics nor the 1–50 limit range nor the projectId format are clarified.

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 — listing Functions scoped to a permitted project — and enumerates the fields returned (trigger, auth mode, status, route, latest deployment). It implies a singular getter is the alternative (eurobase_get_function exists) but never names or distinguishes it 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 only implied: 'one page of Functions of a permitted project' suggests this is the enumeration entry point when you don't yet have a function identifier. No when-not guidance and no named alternatives among siblings such as eurobase_get_function or eurobase_list_function_deployments.

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 cover read-only, idempotent, closed-world semantics, yet the description still adds material facts: results come from a stale snapshot, default page size of 50, full-name ordering, the accountStatus connection indicator, and the authorization requirement. It also warns that repository names are user-defined text, which is useful untrusted-content 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?

Purpose and scope are front-loaded, and every clause carries new information (fields, limit, ordering, query behavior, accountStatus, prerequisites). The middle section is a long run-on sequence, which slightly hurts scannability, but there is no filler.

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 enumerates the returned fields (full name, name, default branch, private flag, accountStatus) and the ordering and page size, which is what an agent needs to plan around the response. Combined with the prerequisite and snapshot caveat, nothing essential is missing for a two-parameter 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?

With 0% schema description coverage the description must carry the load, and it does: limit is 'at most limit (50 by default)' clarifying the default the schema omits, and query is documented as substring matching on the full name rather than a prefix/exact match. It does not mention the min/max constraints (1, 50, 100 chars), but those are visible in the schema itself.

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 with precise scope: repositories accessible to GitHub installations connected to this Eurobase account, read from the recorded snapshot. It goes further than the title by naming the returned fields and the snapshot source, so an agent knows exactly what it gets.

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 clear situational context: the data comes from the dashboard snapshot rather than live GitHub, and connection/access are managed by the user in the dashboard, which tells the agent not to attempt remediation here. It also states the grant prerequisite. It stops short of explicitly routing the agent (e.g., 'use before eurobase_create_project'), but no sibling tool offers an alternative source for GitHub repos.

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 annotations, it discloses retention bounds, the 50-row cap, chronological ordering, cursor semantics for paging older, and that null means no older matches. It also warns that empty means no retained matches rather than runtime health, and that log contents, request paths and user-agent families are client/application input — a useful untrusted-data signal.

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 and windowing rules are front-loaded in the first sentence, and every clause carries information. The back half becomes a long run-on enumerating returned row fields, which is dense but justified given there is no output schema.

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 an 8-parameter tool with no output schema and no schema descriptions, the definition still covers filtering, time windows, pagination, row shape, defaults, and result interpretation. An agent has essentially everything needed to call it correctly and read the response.

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?

With 0% schema description coverage the description has to carry the load, and it does: timeRange default, from/to both required with exact three-digit fractional UTC format and non-combination with timeRange, limit default 50 and max rows, and cursor as the next-older-page token. Gaps remain on projectId expectations and on what each category value actually covers.

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?

Opens with a specific verb+resource ("Read the latest retained logs") and enumerates the covered sources (app, deployments, Functions, storage, HTTP access), which implicitly distinguishes it from the narrower deployment/function log siblings. It never names an alternative tool, so the differentiation is inferred rather than stated.

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 concrete usage context: default 24h window, the mutually exclusive exact [from,to) mode with both bounds required, and an explicit "There is no live follow" exclusion. What's missing is routing guidance to eurobase_list_deployment_logs / eurobase_list_function_logs / eurobase_get_project_log_summary when the agent wants a narrower or summarized view.

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=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond that — results are limited to projects permitted by the connection — but says nothing about default page size, whether a next cursor is returned, or ordering.

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

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

A single front-loaded sentence with no filler; the scoping constraint follows the verb-resource pair. Nothing here is redundant with the annotations or title.

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 and no parameter descriptions, the description must carry the pagination contract, and it does not: an agent cannot tell what a page contains, where the continuation token comes from, or what the default limit is. Access scoping is noted, but the mechanics needed to call it correctly are 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%: neither 'limit' (1-100) nor 'cursor' (string, 1-4096 chars) is documented anywhere. 'One page' hints that pagination exists, but the description never explains that limit caps page size or that cursor must be the token echoed from a prior response, so the compensating value is minimal.

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 ... projects') plus a scope qualifier ('one page', 'permitted by the connection'), which separates it from eurobase_get_project and eurobase_create_project. It does not explicitly name those siblings as alternatives, keeping it short of a 5.

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 the enumeration tool for projects, but the description never says when to use it versus eurobase_get_project or eurobase_get_project_usage, nor any prerequisite (e.g., connection must hold a token).

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?

The annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered elsewhere. The description's one real contribution is clarifying that data is recorded rather than live-fetched, which partly overlaps openWorldHint=false and adds little beyond it.

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 compact sentence with the capability front-loaded and the disambiguation as a trailing clause. No waste.

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 simple one-parameter read tool with rich annotations, this is close to sufficient. Without an output schema, though, the description could have said the result is a list of URL/state pairs, and it leaves the sole parameter undocumented.

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% and the description never mentions projectId, its required status, or the prj_ prefix format. The JSON pattern partially self-documents the format, but the description adds nothing to compensate 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 specific verb+resource ('Read recorded project URLs and access state') and explicitly separates itself from a fetching operation, which helps against the sibling eurobase_get_url. It stops just short of 5 because 'access state' is left undefined, so the exact payload is still vague.

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 negative clause 'does not fetch URLs' implies this is the record-lookup counterpart to a live-fetch tool, but it never names eurobase_get_url or states when to prefer one over the other. Usage is inferable rather than guided.

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 destructiveHint=true and idempotentHint=true, but the description adds what actually gets replaced (the active release, after a successful rollout) and clarifies the async contract: it returns on acceptance, before the deployment is live. The idempotencyKey replay rule is useful nuance beyond idempotentHint. It stops short of stating permission/auth model or reversibility (rollback), so 4 rather than 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?

Four short sentences, front-loaded with the action and its constraints, then behavior, then return timing, then idempotency. No filler and nothing redundant with the schema.

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 destructive, async, no-output-schema mutation, the description covers preconditions, side effect, return timing, and idempotency — the essentials. It could add what to do after acceptance (poll get_deployment or list_deployments) and whether the change is reversible, but nothing needed to invoke 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 coverage is 0%, so the description must compensate, and it does for the two non-obvious parameters: deploymentId is constrained to a finished, non-active deployment, and idempotencyKey is given concrete replay semantics. projectId is left unstated but is self-evident from the name and the prj_ pattern.

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 (promotes) and resource (deploymentId) and pins down the exact scope: a finished deployment, of a permitted project, that is not the active one. The phrase 'without rebuilding' implicitly distinguishes it from eurobase_redeploy, so an agent can pick between them without opening schemas.

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?

Preconditions are explicit: the deployment must be finished, the project must permit it, and it must not already be active. Combined with 'publishing its retained build output without rebuilding' and 'replaces the active release', the agent can infer redeploy vs promote vs rollback. It does not name a sibling tool outright, so no full 5.

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 flag destructiveHint=true and idempotentHint=true, and the description adds substantive context beyond them: the call returns before the deployment is live, a failed rollout leaves the previous version serving, source code is never returned, and reusing an idempotencyKey with different input is refused. These are exactly the behavioral traits an agent needs before invoking a destructive, asynchronous mutation.

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 core action and mode split, then layered with source, auth, rollout, and idempotency details in a logical order. It is dense and long-ish, but nearly every clause carries unique operational information; only the triggerType omission and mild density keep it below top marks.

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 usefully explains the return timing ('Returns once the deployment is accepted, before it is live') and that Function source code is never returned. What the response actually contains (function and deployment identifiers) is only implied, and triggerType is never mentioned, so a small gap remains for an 8-parameter mutation 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 load and does so well: it explains the semantics of name vs functionId, the meaning of entryPath, the 32-file/128 KiB sourceFiles limit, and the authMode enum with its default. It leaves projectId's 'permitted project' constraint and the single-value triggerType enum unaddressed, which keeps 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?

States a specific verb and resource ('Publishes HTTP Function code ... starts its deployment') and immediately distinguishes the two modes: creates when given `name`, replaces code when given `functionId`. This differentiates it from siblings like eurobase_redeploy, eurobase_rollback_function, and eurobase_deploy without requiring the schema to be opened.

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 clear selection logic between the create path (name) and replace path (functionId), plus default behavior for authMode on new vs existing Functions. It does not explicitly route the agent to alternatives such as eurobase_redeploy or eurobase_rollback_function when those might be the better choice, so it falls short of full when/when-not guidance.

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

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

Goes well beyond the annotations: returns once the purge is recorded, each host applies it on the project's next request, purged entries re-render on that request, and it discloses the shared rate limit (10/s, bursts of 100) with RATE_LIMITED plus retryAfterSeconds and no-op-on-refusal behavior. The note that 'repeating a purge purges again' clarifies the idempotentHint nuance without contradicting it (resulting state is the same).

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 reach, then modes, then behavior and limits. Dense but every sentence carries information; the multi-clause semicolon sentences are slightly heavy but not wasteful.

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, and the description notes only that it returns once the purge is recorded rather than describing the response shape. Nonetheless it covers the caller's decision-relevant context (modes, exclusivity, deferral to next request, rate limits, errors) thoroughly for a 4-parameter mutation 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?

With 0% schema description coverage, the description carries the load: it defines tags as Cache-Tag header values or Next.js revalidateTag tags (max 128), paths as Next.js revalidatePath-style purges (max 64), and everything as all cached entries of the project. It does not restate the path pattern (must start with /) or tag length limits, so it doesn't fully compensate for the 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 (purges) and precise resource (cached responses and data of a permitted project's apps on every Eurobase app host). No sibling performs cache purging, and the three purge modes are enumerated so an agent can distinguish behavior immediately.

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?

Clearly explains the three mutually exclusive modes (tags, paths, everything) and the constraint that everything cannot be combined with tags or paths. It lacks explicit 'when to choose tags vs paths' guidance or when-not-to-use context, but the mode semantics are strong.

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 destructive/idempotent/openWorld, and the description adds context beyond them: the new release replaces the active one only after a successful rollout, the call returns at acceptance (async) before the deployment is live, and retries with the same key are safe. It stops short of stating required permissions or what happens on a failed rollout.

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 tight sentences, front-loaded with the core action and followed by the consequential effects. Slight awkwardness in 'a deployment of a permitted project' but nothing wasted.

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 3-required-param mutation with no output schema, it covers replacement semantics, async return timing, and idempotency — exactly what an agent needs to call it safely. The gaps are the unexplained projectId and the failure/permission behavior.

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%, so the description must compensate: it explains that deploymentId identifies the commit to rebuild and that idempotencyKey deduplicates retries, which is real added value. However projectId is never explained, nor is the 'permitted project' access constraint or the expected ID formats.

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: it rebuilds the commit behind an existing deployment as a NEW deployment, which separates it from eurobase_deploy (new build) and from eurobase_promote/rollback. It never names those siblings, so the differentiation is inferable 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 is only implied by 'Rebuilds the commit of deploymentId' — an agent can infer this is for re-shipping an already-built commit rather than deploying fresh source. There is no explicit when-to-use/when-not or pointer to deploy/rollback/promote for adjacent cases.

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?

Adds real context beyond the annotations: no rebuild occurs, the active release is replaced (matching the destructiveHint), and the call returns as soon as the rollback is accepted rather than after it goes live — an important async detail not encoded in any structured field. The idempotency sentence elaborates rather than merely repeating idempotentHint. Missing only failure/blast-radius detail, e.g. what happens to in-flight traffic.

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 tight sentences, front-loaded with the core action and mechanism, then the release-replacement effect, then the timing/idempotency contract. No filler and every clause carries operational meaning.

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 3-required-param mutating tool with no output schema, the description covers what happens (release replaced), when it returns (before live), and replay behavior — enough to call it correctly. The remaining gap is what the accepted response actually contains, though 'returns the same deployment' hints at a deployment object.

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 the load. It well explains deploymentId's validity constraint (must be a successful deployment with retained output) and idempotencyKey's replay semantics, but says nothing about projectId beyond the vague 'permitted project', and doesn't state whether deploymentId must be a prior release of that same project.

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 the specific verb and resource (rolls a project back) and disambiguates mechanism precisely: 'republishing the build output of deploymentId... without rebuilding' versus re-building. This clearly separates it from siblings like eurobase_redeploy and eurobase_rollback_function, which act on different resources.

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?

Implied preconditions are present ('a permitted project', 'a successful deployment whose output is still retained', 'after a successful rollout'), which tells the agent when the call is valid. However, there is no explicit comparison to the sibling eurobase_redeploy or eurobase_promote to tell the agent which recovery path to pick, so routing is left 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?

Adds substantial behavior beyond the annotations: the retained artifact replaces the active version after a successful rollout while the current version keeps serving on failure, and the call returns on acceptance rather than on liveness. It also explains idempotency-key semantics — same key returns the same rollback, a different target is refused — which the idempotentHint alone does not 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?

Verb and target come first, followed by the eligibility constraint, then failure/rollout semantics and idempotency. Every sentence conveys distinct operational information; nothing is padding.

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 destructive, asynchronous mutation with no output schema, it discloses eligibility, atomicity, and acceptance timing. The only missing piece is how to confirm the rollback went live (e.g. which sibling to poll), a small gap against an otherwise complete definition.

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: it defines deploymentId precisely (the prior successful deployment, sourced from get_function's rollback.targetDeploymentId) and specifies idempotencyKey replay behavior including refusal on target mismatch. projectId and functionId are left to their self-evident names and patterns ('permitted project'), which is a minor residual 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 ('Rolls an HTTP Function ... back to deploymentId') and constrains the target, which distinguishes it from the project-level eurobase_rollback, eurobase_redeploy and eurobase_promote siblings without needing their schemas.

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 eligibility rule (the target must be the successful deployment active immediately before the current one) and routes the agent to eurobase_get_function for rollback.targetDeploymentId, including the eligible flag and the reason when ineligible. It stops short of explicitly contrasting with redeploy/promote, but the prerequisite is unambiguous.

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?

Adds substantial context beyond the annotations: an explicit refusal path with error code ENV_CHANGE_REFUSED for secrets, the side effect of triggering a redeploy (surfaced as `redeploy`), the warning that public values can appear in published assets, and the no-op behavior on identical value. These consequences and the failure mode are exactly what an agent needs before invoking a destructive, open-world mutation.

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 and scope are front-loaded in the first clause, and each following sentence carries a distinct behavioral fact (redeploy trigger, build-time caveat, secret refusal, idempotency). It is dense but noticeably long for a three-parameter setter; the final idempotency sentence could be folded into the redeploy sentence.

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, and the description compensates by explaining that a redeploy outcome is returned, plus failure behavior for secrets. With only three required parameters and rich annotation coverage, the remaining gap is the unexplained `projectId` semantics and absence of any mention of listing/removing counterparts.

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 only partly does: it clarifies that `value` is public/non-secret, size-relevant in that build-time values need a new deploy, and that re-setting the same value is a no-op. It never explains `projectId` (the 'permitted project' phrase is only suggestive) or the key naming pattern enforced by the schema.

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 ('Sets one public (non-secret) environment variable of a permitted project') plus the effect scope (app build and runtime, create-or-replace). The parenthetical '(non-secret)' immediately separates it from secret management, and the create/replace semantics distinguish it from eurobase_unset_env.

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 clear conditions: redeploy starts when the live release reads variables at activation, otherwise the value applies at next deployment, and build-time values need a new deploy. It also names the escape hatch for secrets (change them in the Eurobase dashboard). It stops short of explicitly routing to siblings like eurobase_list_env or eurobase_unset_env, so a 4 rather than a 5.

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?

Goes well beyond the annotations: discloses that removal triggers a redeploy when the release reads variables at activation (surfaced as 'redeploy'), that otherwise it applies at next deployment, the exact refusal code for secret-backed variables, and that removing a nonexistent variable is a silent success. This is consistent with destructiveHint=true and idempotentHint=true rather than 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.

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

Front-loads the verb and resource in sentence one, then layers the deployment consequences and edge cases. Every sentence carries real information, though the redeploy nuance is a slightly dense parenthetical.

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 correctly explains that a 'redeploy' indicator is returned and covers the refusal and no-op cases. Enough for correct invocation, with only the parameter-level detail left implicit.

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 the load; it only implies that the variable is identified by key within a project, without explaining the key naming pattern or projectId format already captured by the schema patterns. Baseline for a 2-param tool with simple string schemas.

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 (removes) plus resource (one public environment variable) and scope (of a permitted project), which cleanly separates it from eurobase_set_env and eurobase_list_env. The 'public' qualifier immediately signals the boundary against secrets.

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 a clear when-not: secrets are refused with ENV_CHANGE_REFUSED and must be removed via the Eurobase dashboard, which routes the agent to an alternative path. It does not explicitly name set_env/list_env as siblings, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is fully covered. The description adds the meaningful behavioral point that the result includes grant permissions rather than just an identity, but says nothing about return shape or whether permissions are scoped per environment.

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 wasted words. It is arguably slightly too terse for the only identity tool in the set, but structure is efficient.

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?

There is no output schema, so the description carries the burden of hinting what comes back; 'account and grant permissions' is a partial answer but not enough for an agent to know whether it gets an email, a token scope list, or org membership. For a zero-parameter tool the gap is modest but real.

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 the schema baseline of 4 applies. The description correctly frames the tool as taking no input by describing a pure read of the connected account.

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 the connected account') and adds the useful scope detail of 'its current grant permissions'. It is clearly distinguishable from the project/deployment/list siblings, though it does not explicitly contrast itself with any of them.

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 'whoami' semantics imply when to use it (identity/auth checks), but the description never says so explicitly and gives no exclusions or alternatives. With zero parameters there is little risk of misuse, so implied guidance is tolerable.

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