Chainstack

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

The description does real work beyond the annotations: it discloses a mandatory draft-show-confirm workflow, that the message posts to an external contact form, that org name/ID is attached when an API key exists, and a concrete prohibition list on sensitive content. The only gap is that it never says whether the user gets a transcript or confirmation back — but an output schema exists, so that is partly covered elsewhere.

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?

Well front-loaded: purpose, then pre-call checklist, then message guidance, then exclusions. It is long and repeats some message-composition guidance already present in the message parameter description, but the headings make it scannable and most lines carry actionable instruction.

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 non-idempotent, externally-posting tool with destructiveHint=true, the description supplies exactly the missing context: consent requirement, forbidden payload contents, audience routing, and escalation alternatives. Combined with a full output schema and 100% parameter coverage, nothing an agent needs to call this safely is absent.

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 100%, so the baseline is 3. The description still adds value by telling the agent to draft from conversation context, shows a bad-vs-good message example that improves message quality, and explains the side effect of the API-key path on submitted payload — information the schema does not convey.

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 ("Submit a message to Chainstack's sales and support team") and anchors it to a known channel (chainstack.com/contact/). It is unambiguously distinct from read-only siblings like get_chainstack_pricing, get_platform_status, and search_docs, which it explicitly routes away from.

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?

Enumerates the triggering intents (pricing, quotes, upgrades, Enterprise customizations, problem reports) and then gives explicit exclusions with named alternatives: support portal + status page for incidents, ideas site for product requests, GitHub issues for MCP server bugs. Little 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?

Annotations already declare the basic profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds the genuine workflow dependency on get_deployment_options and the Global-only constraint. It omits meaningful behavior for an open-world, non-idempotent provisioning call: whether it is billable, how long provisioning takes, and whether a duplicate call creates a second node.

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?

It is short and front-loads the action, but the get_deployment_options prerequisite is stated twice in near-identical form, and the parenthetical about node_tier "Global" introduces an attribute not present in the schema, adding confusion rather than precision.

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 a full output schema and 100% parameter coverage, the description only needs to cover workflow and validity constraints, which it does. Missing only the cost/provisioning-time framing that an agent weighing a paid, non-idempotent deployment would benefit from.

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 100%, so every parameter already carries its own description including the ID formats. The description's "Global option" note mirrors what the cloud parameter description already says, so it adds little beyond the schema. It also references a "node_tier" concept that does not exist as a parameter.

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?

"Deploy a new blockchain node" gives a specific verb and resource, which cleanly separates it from delete_node, update_node, get_node and list_nodes in the sibling set. It does not, however, explicitly state the create-vs-update boundary in words.

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 an explicit prerequisite ordering ("Call get_deployment_options first for valid IDs") and a constraint on which option class to pick (a Global option). There is no exclusion guidance — e.g. "use update_node to modify an existing node" — so the when-not side is left implicit.

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: new rules are inactive by default, blocked requests get HTTP 403 within ~10 seconds, both rule kinds must pass when both are active, origin rules block any request lacking an Origin header, and identical rules are deduplicated by returning the existing one. It also reassures that the Chainstack API itself is never locked out.

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?

Information is front-loaded (what it does, default state, enforcement effect) and each paragraph serves a purpose. The confirmation and origin-header warnings are valuable but add length that 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?

An output schema exists so return values need not be explained, and the description fully covers the mutation's risks, defaults, enforcement semantics, and dedup behavior. An agent has everything needed to call it correctly and to warn the user first.

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 100%, so the baseline is 3, but the description adds real meaning by explaining the runtime effect of the ip vs origin rule_type choice and the consequence of setting activate. Syntax constraints (no CIDR, wildcard forms) remain the schema's job, which is appropriate.

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: 'Add an IP or Origin allowlist rule to a Global node.' It also distinguishes itself from siblings like update_node_access_rule and set_node_access_rules_status by establishing that this creates new (initially deactivated) rules rather than altering existing ones.

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 operational guidance: rules start deactivated, activation requires user confirmation of the allowlist, and origin rules are only appropriate for browser-only access. It does not explicitly name which sibling to use to modify or deactivate rules, but the surrounding context makes the boundary clear.

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=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is known. The description adds zero behavioral context beyond that — nothing about permissions, side effects, name uniqueness, or whether creation is scoped to an organization.

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 waste, but it is under-specified rather than genuinely concise — there is no second sentence of substance to trim.

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?

Output schema and annotations are present, so return values and safety needn't be spelled out. However, for a creation/mutation tool, the description omits the scoping context an agent needs (organization/workspace, required auth, uniqueness constraints), leaving it inadequate for correct invocation.

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 100% for both parameters (name, description), so the schema already carries parameter meaning. The description adds no format, length, uniqueness, or default information, so the baseline 3 applies.

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

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

"Create a new project" is a near-verbatim restatement of the tool name (create_project) and title (Create project), adding no distinguishing detail. Unlike siblings such as create_node or delete_project, nothing is said about what a project is or what creation entails.

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 guidance, no prerequisites, no mention of alternatives (e.g., update_project for existing projects, or whether an organization context is required). The agent must infer everything from the tool name.

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, idempotentHint=true, and readOnlyHint=false, so the safety profile is largely covered. The description adds 'irreversible,' which usefully reinforces permanence, but it does not explain cascading effects, permission requirements, or dependency handling.

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 waste. 'Delete a node' is immediate, and '(irreversible)' is the only extra detail, which earns its place.

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?

The tool is simple and has annotations covering its destructive/idempotent nature plus an output schema, so much context is already structured. However, for a destructive node deletion, the description omits potentially important operational context such as associated access-rule cleanup or confirmation 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 description coverage is 100%, and node_id is already documented with an example in the input schema. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Delete a node.' It distinguishes the target from sibling tools like delete_node_access_rule by naming 'node,' though it does not explicitly call out that sibling.

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 no guidance on when to use this versus get_node or update_node, nor does it describe prerequisites, confirmation requirements, or alternatives to deletion. The only usage signal is the parenthetical '(irreversible),' which implies caution but not 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?

Goes well beyond the annotations: it declares the operation irreversible, explains the security consequence of removing an active rule, and warns that with no active rules the node accepts requests from any IP and origin. That last point is a non-obvious, high-risk behavioral trait an agent would not get from destructiveHint alone.

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?

Three short sentences with the highest-risk fact (irreversibility) first and the security fallback last. No filler and no repetition of the 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?

Output schema exists and the description correctly notes the result reports what's enforced afterwards, and the annotations carry the safety profile. Minor gaps only: no mention of authorization requirements or whether deleting the final rule warrants confirmation.

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 100%, so node_id and rule_id are already documented in the schema, including the pointer to list_node_access_rules for obtaining rule_id. The description adds nothing further about parameters, which is acceptable at full coverage.

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

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

States a specific verb and resource plus scope ('from a node') and flags irreversibility up front. It does not name sibling operations (update_node_access_rule, set_node_access_rules_status), so differentiation is inferred from the verb 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?

Usage is implied by the consequence sentence — you delete a rule to change who can reach the node — but there is no explicit when-to-use versus update_node_access_rule or set_node_access_rules_status, nor any stated prerequisites.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the description's "irreversible" largely restates structured data. It adds no detail on the side effects an agent would actually care about — whether child nodes or access rules are cascade-deleted, and whether this requires elevated permissions.

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 short sentence with the destructive warning front-loaded and zero padding. Nothing could be trimmed 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?

An output schema exists and the single parameter is fully documented, so the description needn't explain returns. For a destructive, open-world mutation, though, it should mention the blast radius (child resources) or permission requirements to be fully sufficient.

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 100%, and the project_id property even carries an example format (PR-123-456-789). The description contributes nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ("Delete a project"), which is enough to distinguish it from delete_node or update_project among the siblings. It stops short of any explicit sibling routing, but the resource noun does the disambiguation work.

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 guidance on when to use this versus update_project or delete_node, no prerequisites such as ownership permissions, and no note on whether the project must be empty first. The parenthetical "(irreversible)" is a warning, not a usage condition.

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

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

Annotations already declare read-only/idempotent, and the description adds genuinely new operational facts: no API key, no caching (so results are never stale), best-effort behavior with `warnings` on partial source failure, and list-price caveats surfaced in `disclaimers`. It also flags the scope limit that per-method RU billing is absent from these sources.

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 purpose and the quoting trigger, then scope limits, then return fields — a sound ordering with no filler sentences. It runs long, and the parenthetical list of eight EVM archive-state methods is more enumeration than most agents need at selection time, though it does serve the routing purpose.

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?

A zero-param read tool with an output schema still gets explicit field-by-field guidance on how to use `region_legend` for display and how to treat `warnings`. The known gap (method-level RU rules) is called out with the correct next tool, leaving no ambiguity about where its coverage ends.

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?

There are zero input parameters, so the baseline is 4 and there is nothing to disambiguate. The description instead spends its effort on output semantics, which the schema already 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?

States a specific verb and resource ('Fetch Chainstack's public pricing') plus the return shape ('normalized snapshot'). It explicitly distinguishes itself from doc-lookup siblings by naming `search_docs` and `get_doc_page` as the path for method-level RU rules.

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 concrete trigger ('answer pricing questions before quoting the user') and enumerates the question classes it covers. It also names the exclusion and the alternative tools for that excluded case, so an agent knows when not to call it.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds the workflow dependency: the returned blockchain/cloud IDs are the valid inputs for create_node, which is behavioral context not present in structured fields. It stops short of describing catalog size, caching, or how often options change.

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

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

Two short sentences with no filler: the resource is stated first, and the workflow instruction follows. Every sentence earns its place and nothing is buried.

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

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

With an output schema present and annotations covering safety and closed-world behavior, the description supplies exactly the missing piece – why to call it and in what order relative to create_node. Nothing an agent needs in order to invoke it correctly is absent.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The statement that the call yields blockchain and cloud IDs adds orientation to the (parameterless) return content rather than to any input.

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 ('List') plus a precisely scoped resource ('blockchain/cloud/network combinations for node deployment'), which no other sibling covers. An agent can distinguish it from list_nodes, list_projects, and get_platform_status 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?

It explicitly names the downstream sibling ('Call before create_node') and states the purpose of the call (to obtain valid blockchain and cloud IDs). It does not state exclusions or what to do if the call is skipped, but the pre-call ordering 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the notion that the payload is the 'complete page,' with no disclosure of page size, truncation, or behavior on an invalid path. Adequate but adds little beyond annotations.

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

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

Two sentences, zero filler, with the action front-loaded and the usage rule second. Every sentence carries distinct 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 one-parameter read tool with a full output schema and rich annotations, the description covers purpose and routing adequately. It omits what happens on a non-existent or ambiguous page path, which would be the only remaining gap an agent might care about.

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 100% and the `page` property description already explains provenance from search results and normalization of leading slash, .mdx extension, and URL prefix. The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb (get) and resource (documentation page content) with the qualifier 'full', which distinguishes it from snippet-returning siblings. It also names search_docs explicitly, so an agent can separate the two tools without inspecting either schema.

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

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

Gives an explicit ordering rule ('use after search_docs') and the condition that selects this tool ('when a snippet isn't enough'), which implicitly defines when search_docs suffices instead. Nothing about when to choose this versus the sibling 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by telling the agent what the returned detail contains (endpoints and cloud info). It does not mention failure behavior, e.g. what happens when the node_id is unknown.

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, and no filler. It is lean to the point of being slightly terse, but nothing 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?

This is a simple single-parameter getter, an output schema exists so return values need not be re-explained, and annotations carry the read-only safety profile. The description is therefore nearly sufficient, with only minor gaps around error conditions or whether endpoint data is always present.

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 single node_id parameter is fully documented in the schema, including an example format (ND-123-456-789), so schema coverage is 100%. The description adds no additional meaning about the parameter, which matches the baseline for complete schema coverage.

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 specific verb (get) and resource (node) and scopes the result ('full details including endpoints and cloud info'), which separates it informally from list_nodes and the create/update/delete siblings. It does not explicitly name a sibling to contrast against, which keeps it from 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: needing full detail on one specific node (identified by node_id) is the obvious trigger versus list_nodes. The description never states when to choose this over list_nodes or get_organization, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is fully covered. The description adds one useful behavioral fact beyond the annotations — that only name and ID are returned, so an agent should not expect full org metadata — which is real value, though it stops short of confirming singular-vs-multiple scope.

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 short sentence with zero filler, front-loading both the action and the payload. Nothing in it 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?

With zero parameters, a full output schema documenting the return shape, and annotations covering the safety profile, there is little left for the description to carry, and what it does state is accurate. The only gap is whether this returns the single current organization or is scoped some other way, which is 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The mention of expected return fields is a bonus rather than a parameter concern.

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

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

States a concrete verb and resource ('Get organization') and specifies the exact fields returned ('name and ID'), so an agent knows this is a single-resource lookup rather than a listing. It does not differentiate from sibling getters like get_project or get_node, but the resource name itself is unambiguous.

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

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

Usage is only implied: the zero-parameter shape makes it obvious this retrieves the calling context's organization, with no prerequisites. There is no explicit statement of when to prefer it over get_project or list_projects, but for a trivial identity lookup the inference is small.

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, non-destructive and openWorldHint=false, so safety is covered. The description adds the scope of results (incidents and maintenances) but nothing about freshness, caching, or pagination of incident lists; an output schema exists so return shape need not be repeated.

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 listing exactly what the tool returns, with no filler or repetition of the 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 a complete annotation set, a fully documented single parameter, and an output schema, only the usage routing and any freshness caveats are missing. Adequate for an agent to invoke correctly, but not maximally informative.

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 100% and the single 'network' parameter is fully documented there, including that omitting it returns overall status and incidents only. The description adds no signal about the filter, so baseline 3 applies.

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

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

States a specific verb ('check') and resource ('platform status') plus what is returned: active incidents and maintenances. It is clearly distinct from the node/project CRUD siblings, though it does not explicitly contrast itself with any named alternative.

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 guidance on when to call this versus siblings such as get_node or get_organization, and no preconditions or exclusions. The agent must infer that this is a global health check rather than a per-resource query.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond that structured data – no mention of error behavior, missing-project handling, or what 'details' encompasses. It essentially restates the title.

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 short sentence with zero padding and the core action front-loaded. It is properly sized, though the brevity comes at the cost of information rather than being optimally dense.

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

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

With an output schema and rich annotations, the description need not explain returns or safety. Still, for a lookup tool in a crowded sibling set, it should at minimum route the agent away from list_projects and update_project; that guidance is absent.

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 100% and the single project_id parameter is documented in the schema with a format example (PR-123-456-789). The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (Get) and resource (project), so the basic action is unambiguous. However, 'details' is vague, and the description does nothing to distinguish it from siblings like get_node, get_organization, or 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?

There is no statement of when to use this tool versus list_projects (browsing) or update_project (mutating). No prerequisites or exclusions are given; the agent must infer usage from the 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?

It adds substantive behavior beyond the annotations, notably that a node with no active rules accepts requests from any IP and origin. It also discloses the Global-node-only constraint and gives actionable troubleshooting for a 403 scenario. These are important operational traits that the annotations alone do 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?

The description is front-loaded with the core action and scope, then adds two short sentences covering default behavior and troubleshooting. Every sentence contributes useful information with 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?

Given the full schema description coverage, the read-only annotations, and the presence of an output schema, the description covers the remaining gaps well: node scope, default allow behavior, and escalation guidance. An agent has enough information to call this tool correctly.

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 100%, so node_id, status, and rule_type are already documented in the input schema. The description mentions IP and Origin rules and Global nodes, which adds mild semantic context, but it does not explain the status or rule_type filters beyond what the schema already provides.

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: 'List a node's access rules.' It also adds the scope 'IP and Origin allowlists, Global nodes only,' which sharply distinguishes this read-only listing tool from sibling mutation tools such as create, update, delete, and set_node_access_rules_status.

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 provides clear usage context, including that the tool applies only to Global nodes and that a 403 despite correct configuration should be escalated via contact_chainstack. It does not explicitly contrast when to use this listing tool versus get_node or the mutation siblings, but the context is still clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only the notion that status and connection endpoints are included; it says nothing about result volume, org-wide scope, or whether endpoint data is sensitive.

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 short sentence with zero filler, with the resource and returned fields front-loaded. Nothing 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 an output schema present, annotations covering safety, and full schema docs on the sole parameter, the description is sufficient to invoke correctly. Minor gap: it never hints at the project scoping option or potential result size, but nothing critical is missing.

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

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

Schema description coverage is 100% and the single optional project_id parameter is fully documented in the schema, including the org-wide default. The description adds no additional meaning beyond that, so baseline 3 applies.

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

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

States a specific verb and resource ('List nodes') and adds what the listing surfaces ('status and connection endpoints'), which tells an agent what it gets back. It does not distinguish itself from related siblings such as get_node (single node) or list_node_access_rules, 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?

Listing usage is implied by the verb, but there is no explicit guidance on when to choose this over get_node for a single node or how it relates to list_projects. No exclusions or prerequisites are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds domain context ('Projects are containers for nodes') but says nothing about pagination, result volume, or ordering on a tool flagged openWorldHint.

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

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

Two short sentences with the primary action front-loaded and no filler. The second sentence carries genuine domain value rather than restating the name.

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

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

An output schema exists to explain return values and annotations cover the safety profile, so the description only needs to establish intent and scope, which it does. The only residual gap is the absence of any routing hint toward get_project or list_nodes.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema already closes additionalProperties, and the description correctly implies an unfiltered full listing.

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 ('List all projects') with the 'all' scope making it distinguishable from get_project. It stops short of naming sibling alternatives like get_project or list_nodes, so differentiation relies on the agent scanning the sibling list.

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 explicit when-to-use guidance, no prerequisites, and no mention of get_project for retrieving a single project. Usage is only implied by the verb 'list' and the 'all' scope.

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: it discloses that the amount is computed as a delta to a per-network cap, names the specific failure mode (insufficient-balance), documents the 429 cooldown behavior with scope (per organization, per address, per network) and that the error carries the next-available time. It also pre-empts a false-retry pitfall by stating a success is final even if the balance hasn't refreshed, which is behavior the structured fields cannot express.

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

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

Front-loaded with purpose, then failures, then cooldown, then retry guidance — a sensible order with no filler. It is longer than average and includes agent-directed phrasing advice ("describe as top up not give"), which is useful but borders on verbose for a two-parameter tool.

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?

Covers everything an agent needs to call and interpret this tool correctly: cap semantics, refusal conditions, cooldown scope, and retry behavior. Return values are backed by an output schema, and the description still points at `amountSent` and `transaction` for the cases where interpretation matters.

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 100%, so the address format and network enum are already well documented. The description adds meaning the schema does not: the per-network maximum concept tied to `network` (e.g. 0.5 ETH on sepolia) and the returned `amountSent` delta, which explains what the inputs actually produce.

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 ("Top up a testnet address from Chainstack's faucet") and immediately clarifies the non-obvious semantics that the amount is a top-up-to-cap, not a fixed payout. No sibling tool does faucet funding, so it is unambiguous against the listed alternatives.

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 frames the use case (funding testnet addresses) and the conditions under which the call is refused: address already above cap, or a repeat within the 24-hour per-network cooldown. It does not name alternatives or say explicitly when not to use it in favor of another tool, but the constraint context is strong enough that an agent knows when this applies.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description adds only topical scope (what content is indexed), not behavioral traits like result limits, ranking, or what happens with an empty/no-match query.

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 the tool and its indexed domains with no filler. Nothing is redundant or buried.

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 one fully documented parameter, rich annotations, and an output schema handling return values, the definition is nearly sufficient. The one meaningful gap is the missing handoff to get_doc_page, which an agent would need to know to complete a search-then-read workflow.

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 100% and the single query parameter already carries an example-driven description ("deploy ethereum node", "eth_call"). The tool description adds nothing beyond the schema about query syntax or formatting, so the baseline 3 applies.

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

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

States a specific verb (search) and resource (Chainstack docs) and enumerates the content domains covered — RPC methods, node infrastructure, Web3 APIs, deployment guides, code examples. An agent can tell this is a documentation retrieval tool. However, it never distinguishes itself from the sibling get_doc_page, so the boundary between the two retrieval tools remains implicit.

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 guidance on when to use this versus the sibling get_doc_page, which is the natural follow-up tool for fetching a full page once a search result is found. No prerequisites, no note on query phrasing strategy or result count. Usage is only inferrable from the name and verb.

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 by disclosing the ~10 second propagation delay, the HTTP 403 failure mode, that IP and Origin rules are conjunctive, and that deactivation opens the node to any IP and origin. This is exactly the consequence information an agent needs before a destructiveHint=true call.

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 one-line action sentence, followed by consequences in decreasing importance. Dense and mostly waste-free, though the IP/Origin explanation 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?

Output schema and annotations are present and the description covers the destructive blast radius, timing, and failure behavior. For a 2-parameter toggle there is nothing an agent needs that 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 100% so the baseline is 3, but the description adds real semantics: it explains what "activated" enforces and what "deactivated" opens up, not just the enum labels. node_id semantics are left to the schema, which already documents the ND- format.

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 pair and resource ("Activate or deactivate every access rule on a node at once") with explicit scope. The phrase "every access rule ... at once" cleanly separates it from the per-rule siblings create_node_access_rule / update_node_access_rule without needing to name 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?

Gives a concrete precondition before invoking: "First confirm with the user that the IP rules cover every IP that calls the node", plus a warning that origin rules block header-less clients. It does not explicitly route to the single-rule alternative for narrower changes, so it stops 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?

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is known without the description. The description adds no behavioral context of its own — no note on whether the old name is recoverable, whether referrers break, or whether permissions are needed for a destructive 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?

A single short sentence with zero waste and the action front-loaded, but it is under-specified rather than efficient — the same two words could have carried a constraint or an alternative at no cost.

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

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

An output schema exists so return values need not be explained, and the schema fully documents the two parameters. Still, for a destructive, idempotent, open-world mutation the description should say what the rename affects or requires; it leaves that entirely to annotations and inference.

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 100%, including the node ID format example and the meaning of name, so the baseline is 3. The description adds no extra meaning about name uniqueness, length limits, or allowed characters.

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?

"Rename a node" gives a specific verb and resource and implicitly narrows the generic name update_node to name-only mutation, which distinguishes it from update_node_access_rule or update_project. However, it adds essentially nothing beyond the title "Rename node," so it reads as a restatement rather than an explanation.

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 guidance on when to use this versus siblings: nothing says whether renaming is preferred over re-creating via create_node/delete_node, and no prerequisites or constraints are mentioned. The agent must infer the context entirely.

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, so the description's real value is the blast-radius detail: the first origin rule blocks every request lacking an Origin header (servers, scripts, curl) even from allowed IPs, and deactivating a rule can strand clients that only it allowed. That is precisely the kind of consequence an annotation cannot express. It stops short of noting reversibility or that the change takes effect immediately.

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 mutation is stated first, then the immutability constraint, then the two risk warnings in descending order of danger. Three tight sentences with no filler; every clause earns its place.

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 rich annotations and an output schema present, the description only needs to cover risk and routing, which it does well. The remaining gap is partial-update semantics – whether omitting both optional fields is a no-op or an error – which an agent would want on a 4-parameter mutation.

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 100%: value's type-dependent format, the activated/deactivated enum, and both ID formats are documented in the schema itself. The description adds only the indirect hint that value format depends on rule type; it says nothing about whether both value and status may be supplied in one call or what happens when both are null.

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 ('change an access rule's value, or activate or deactivate it') and implicitly routes the type-change case to delete_node_access_rule / create_node_access_rule. It does not distinguish itself from set_node_access_rules_status, the bulk-status sibling, so an agent could still hesitate between single-rule and bulk operations.

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 explicit when-to-use (change value, toggle status) and when-not (the rule type is immutable – delete and recreate), plus a required prerequisite ('confirm with the user that the IP rules cover every IP'). The activation warning spells out the exact situation in which invoking this tool wrongly cuts off traffic.

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=false, destructiveHint=true, idempotentHint=true and openWorldHint, so the safety profile is covered elsewhere. The description adds nothing beyond them: it does not say what gets overwritten, whether null/omitted fields leave values unchanged or clear them, or whether the change is reversible — notable gaps given destructiveHint=true.

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 short sentence with the resource and mutable fields front-loaded and zero redundancy. It is efficient, though its brevity tips into under-specification rather than tight completeness.

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

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

An output schema exists and annotations cover the safety profile, so the description needn't explain return values. However, for a destructive mutation whose two optional params default to null, the agent is left without guidance on whether omitting a field preserves or clears it.

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 100%, so the ID format (PR-123-456-789) and the name/description fields are already documented. The description only restates the two updatable fields and adds no semantics about partial updates or null handling, so the baseline 3 applies.

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

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

The description names a specific verb and resource ("Update a project") and scopes it to name and description, which distinguishes it from create_project, delete_project and get_project in the sibling list. It is clear but does not explicitly point to those alternatives.

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 for modifying an existing project's name or description. There is no statement about when to prefer it over create_project or update_node, no prerequisites (project_id must exist), and no note on which fields are mutable.

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