neurogenesis

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

Annotations declare readOnlyHint=false and idempotentHint=false, meaning the call may change state, but the description calls it a 'recommendation' and never explains what side effect occurs or whether the learned weights are updated by the call itself. The only behavioral context added is the ranking mechanism, which does not resolve the read-vs-write ambiguity the annotations raise.

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 ranking basis is stated up front. It is efficient but borders on under-specification rather than earning full marks for 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?

An output schema exists so return values need not be described, but with 0% parameter documentation and no annotation-level explanation of the non-read-only behavior, one line is not enough for a 3-parameter tool in a dense routing/graph sibling set.

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

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

Schema description coverage is 0% across three parameters, so the description must compensate and largely does not. 'from a given node' loosely maps to from_node, but agent_id and limit are never mentioned, and nothing explains what a node represents or how limit interacts with ranking.

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 resource (next cognitive steps from a given node) and the ranking basis (learned edge weight and trust), which is more than a restatement of the name. It stops short of differentiating itself from the obvious sibling route_task, so an agent must infer the recommend-vs-execute distinction.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of route_task or record_route_outcome, which are the natural alternatives in this sibling set. The agent is left to infer that this is a planning/consultation call rather than an execution call.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds two pieces of real context beyond them — that it is free and that estimates remain separate from observations — but says nothing about pagination, ordering, or the default window covered by the report.

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 has no filler, but it is a fragmented noun-phrase list rather than a front-loaded statement of action and purpose, so the agent's first read does not answer 'what does this do?'

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 needn't be described, and annotations cover the safety profile. Still missing for a correct call: the meaning of `limit`, the reporting window, and when this report is the right choice over sibling ledger/state tools.

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

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

Schema description coverage is 0% for the single `limit` parameter, and the description never mentions it. It does not say whether limit bounds records, rows, or report sections, so the description fails to compensate for the undocumented 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?

The description is a column list ('decision/outcome receipts, route modes, compute avoided, predicted savings, ...') rather than a verb+resource statement, so the agent must infer that this tool returns/reports those metrics. It is distinguishable from siblings like get_ledger only by the specific metric vocabulary, not by an explicit statement of what is produced.

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 call this versus get_ledger, export_state, or record_route_outcome, nor any mention of prerequisites. The only usage-adjacent signal is the phrase 'Free read', which hints at cost but not selection criteria.

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=false, destructive=false, idempotent=false, so safety is covered. The description adds the return shape ('agent_id + initial graph summary') but says nothing about persistence, validation failure modes, or why an optional request_id exists on a non-idempotent tool — a gap worth noting for a creation operation.

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

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

Two compact sentences with the required genome structure front-loaded and the return value trailing. The brace/notation shorthand is efficient, though borderline cryptic for an agent parsing prose.

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 needn't be spelled out, and required genome keys are listed. However, for a nested object with additionalProperties allowed and 0% schema coverage, the description should say more about the expected shape of fitness_metrics, initial_nodes, and request_id before an agent can call this 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 coverage is 0% and the genome is a free-form nested object, so the description carries the full burden — and it does enumerate required members (agent_name, purpose, initial_nodes, fitness_metrics) with cardinality constraints (unique, >=1) plus optional ones (growth_rules, safety_axioms). It falls short only in giving no types or formats and never explaining request_id.

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 ('Create a developmental agent from a digital genome'), which is clearly distinct from sibling operations like get_agent, list_agents, and delete_agent. The domain jargon ('developmental agent', 'genome') is unexplained, but the operation 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?

No indication of when to use this versus alternatives, no prerequisites, and no mention of what happens before or after creation (e.g., whether describe_agent or get_agent should follow). The agent must infer placement in a workflow entirely on its own.

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 and idempotentHint=false, so the safety profile is covered structurally. The description adds only modest context by specifying "developmental agent" and "this mount"; it does not explain irreversibility, side effects, or what request_id does.

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. Every word contributes to identifying the operation and its scope.

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?

Although an output schema exists, the description is too sparse for a destructive tool with two parameters. It does not explain irreversible effects, when deletion is appropriate, or how request_id affects retry 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 0%, so the description must compensate for undocumented parameters. It implies that an agent identifier is needed, but it does not explain agent_id or the optional request_id, leaving the second parameter's role unclear.

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: "Remove a developmental agent." It also scopes the action to "this mount," which distinguishes it from sibling operations such as create_agent, get_agent, and list_agents.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives, nor does it state prerequisites or exclusions. Deletion is implied by "Remove," but the agent must infer the operational context.

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 safety is covered externally. The description adds nothing beyond those annotations—no statement of what the output describes, whether it reflects static or runtime state, or any side considerations. With an output schema present the return shape is covered, but the description contributes no behavioral context of its own.

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. It is perhaps too terse for the ambiguity involved, but as a matter of conciseness there is nothing to cut.

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?

Annotations and an output schema carry most of the load, and there are no parameters to explain, so the description is not dangerously incomplete. Still, for an introspection tool an agent would benefit from knowing it describes the calling agent and when to invoke it, which 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?

The tool takes zero parameters, so the baseline of 4 applies. The phrase 'input contract' loosely signals the payload describes inputs, which is consistent with the empty 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 verb and a resource ('Return capabilities and input contract'), so the basic action is inferable. However, 'capabilities' and 'input contract' are abstract and it's never made explicit that this describes the calling agent itself or the server, leaving the object of the description ambiguous. Siblings (certify, green_route, etc.) are unrelated, so there is no differentiation burden, but the purpose is still only vaguely pinned down.

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 indication of when an agent should call this versus proceeding directly to the sibling tools, and no mention of prerequisites or typical triggers. The agent must guess that this is a discovery/introspection call.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the genuinely useful fact that the payload is portable and can be recreated outside the current host, including on self-hosted verdigraph-neurogenesis. It does not say what the state document contains or whether any ownership/auth constraints apply.

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 the key concept (portable state document) is front-loaded, but as a sentence fragment it omits the action verb and leaves the parenthetical to carry important round-trip semantics. Brevity here comes at the cost of specification rather than being earned.

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

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

An output schema exists, so the return shape need not be explained. Still, for a tool whose whole purpose is producing a migratable artifact, the description omits what is captured in the state, whether secrets are included, and any preconditions — gaps an agent would want closed before exporting.

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

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

Schema description coverage is 0% for the single required agent_id parameter, and the description never mentions it. The agent must infer from the name alone whether this is the target agent, the exporting caller, or something else — the description does not compensate for the schema 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?

The description names the artifact produced (a 'portable state document for an agent') and pairs it with its inverse, import_state, which helps separate it from that sibling. But it never uses a verb form ('export'), and it gives no signal to distinguish this from describe_agent or get_agent, which also surface agent information.

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

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

There is no when-to-use guidance — nothing says when an agent should export state versus calling get_agent or describe_agent. The only contextual cue is the implicit round-trip with import_state, which the agent must infer from the parenthetical.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description earns credit by disclosing the composition of the returned state, including that graph edges carry weights and trust values — non-obvious detail an agent cannot infer 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?

A single compact sentence that front-loads the most important fact ('full current state') and then enumerates contents. It is a fragment rather than a full sentence, but 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?

An output schema exists, so return-value structure needn't be explained, and annotations cover safety. Still missing for a state-fetch tool: error behavior for invalid/unknown agent_id and any hint about payload size or cost relative to describe_agent.

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 agent_id — its source, format, or behavior when the ID is unknown. With a single required parameter the gap is not fatal, but the description does nothing to compensate for the undocumented 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 enumerates the payload (genome, cognitive graph with weighted/trusted edges, summary counts), which makes the tool's output recognizable. However, it never states the verb or resource explicitly ('retrieve an agent's full state'), and it gives no basis for choosing between get_agent, describe_agent, and export_state, all of which plausibly sound similar.

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 versus describe_agent (lighter-weight inspection) or export_state (serialization). No prerequisites, no exclusions, and no mention of what to do if the agent doesn't exist.

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 behavior, so the safety profile is covered. The description still adds real value: 'append-only' tells the agent the record is immutable history, and 'returned verbatim' signals no summarization or rewriting of event reasons. It stops short of explaining ordering or pagination behavior.

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

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

A single front-loaded sentence that identifies the resource and its scope before the aside. The trailing parenthetical ('NG3 — returned verbatim') is partly cryptic but does carry the verbatim guarantee. No wasted framing.

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-value explanation is unnecessary, and annotations cover safety. However, with two undocumented parameters and a misleading 'every' against a default limit of 100, the definition leaves real gaps for an agent trying to call it 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 0%, so neither agent_id nor limit is documented anywhere. The phrase 'every ... event' actively misleads about the limit parameter's default of 100, which caps the result set. The description needs to carry parameter meaning here and does not.

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 the resource precisely: an append-only developmental ledger containing growth, pruning, and evaluation events with their reasons. The verb is only implied by the tool name, and no sibling tool is named for contrast, but an agent can tell what it retrieves. The 'NG3' token is opaque jargon that adds no clarity.

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 reach for this tool versus alternatives such as describe_agent or compute_efficiency_report, which likely surface overlapping state. No prerequisites, no scoping conditions, and no exclusions are given. Usage must be inferred entirely from the one-line purpose.

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=false, idempotentHint=false and closed-world, so the agent knows this is a non-idempotent write. The description adds the export/import pairing but says nothing about whether an agent is created anew or replaced, whether repeated calls duplicate agents, or whether the request_id is an idempotency key — meaningful gaps given idempotentHint=false.

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, front-loaded with the verb and resource, with no filler. It is arguably too terse rather than bloated, but 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 a nested, free-form object parameter, a mutation annotation profile, and an unexplained request_id, the description should do more work. An output schema exists so return values need not be covered, but the input contract and side effects are underspecified for a state-restoring 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% and 'state' is an untyped object with additionalProperties, so the schema gives the agent almost nothing. The description only restates that it comes from an export_state document and never explains the structure of 'state' or the purpose of 'request_id', leaving both 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 ('recreate') and resource ('an agent') and ties it to the export_state document, which separates it from create_agent in spirit. It doesn't explicitly say what happens to any existing agent, but the core action 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?

The phrase 'from an export_state document' implies this is the counterpart to export_state and only usable with such a document. However, it never says when to use this versus create_agent, nor what preconditions (existing agent name collision, permission) apply.

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 without the description. The description adds that results are scoped to 'this mount' and include summary counts, which is useful context, but nothing about pagination, result limits, or behavior when no agents exist.

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 no filler, front-loading the resource and scope before the return detail. Nothing in it is redundant with the schema 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?

With zero parameters, rich annotations, and an output schema that documents the return shape, the description only needs to convey scope and purpose, which it does. The one remaining gap is routing guidance relative to get_agent/describe_agent, which a listing tool of this simplicity could still afford to state.

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; the baseline for a no-parameter tool applies. The mention of 'this mount' hints that scope is environment-derived rather than passed as an argument.

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 resource (developmental agents) and the scope constraint (on this mount) plus the return content (summary counts), which separates it from get_agent/describe_agent, which address a single agent. It is a noun phrase rather than a verb+resource sentence, 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: an agent can infer this is the enumeration entry point when the per-agent siblings don't apply, but the description never says 'use this when you need an overview, use get_agent for one agent' or states any prerequisites. No explicit when/when-not 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?

Goes well beyond the annotations: append-only, hash-bound, single-write-per-decision, and the important disclosure that omitted cost/latency/energy are recorded as explicitly unknown rather than inferred. Consistent with idempotentHint=false, but it stops short of stating the failure mode on a duplicate write.

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 tight sentences, front-loaded with the core action, then the optional-field semantics, then the uniqueness constraint. Nothing redundant and nothing padded.

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 output schema and annotations cover the return shape and safety profile, so those gaps are acceptable. But for a 7-parameter mutation tool with 0% schema description coverage, leaving the meaning/valid range of the required success_score and the role of request_id undocumented is a material 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 description coverage is 0%, so the description must carry the load, and it does explain the optional actual_cost_usd / actual_latency_ms / actual_energy_wh semantics and the null-means-unknown rule. It leaves decision_id, request_id, notes and especially the scale/range of success_score entirely unexplained.

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

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

Names a specific verb and resource ('attach one observed outcome to a Wu Wei decision'), which is clearly distinct from siblings like route_task and submit_evaluation. It doesn't explicitly name the sibling that produces the decision_id (presumably route_task), so the pairing is inferable 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?

The 'one append-only outcome per decision' constraint implies when the tool applies and when it will refuse, and 'observed outcome' signals post-execution timing. However, it never says where decision_id comes from or what to do instead if an outcome already exists (e.g., no sibling for updating an outcome is named).

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 mutation/non-idempotent/closed-world profile, so the bar is lower. The description adds real context beyond them — that profiles are caller-owned, that routing will not fabricate capacity or energy evidence, and therefore that the caller must supply the evidence — but it says nothing about duplicate registration behavior despite idempotentHint=false, nor about validation failures.

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 dense sentences, front-loaded with the verb and resource, then the taxonomy, then the evidence contract. No filler, though the enumeration in sentence two is long enough that it reads as a list rather than prose.

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 described. However, for a non-idempotent write tool taking an opaque nested object, the description omits the two things an agent most needs: the trigger condition for calling it and the consequence of registering a conflicting or duplicate profile.

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 required 'profile' object is an opaque additionalProperties bag, so the description carries the load — and it does, enumerating the meaningful fields (quality, reliability, capabilities, token costs, latency, locality, energy/power, carbon intensity, cache confidence/age). Only 'request_id' remains undocumented, and the field list is illustrative rather than prescriptive about types or required keys.

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 ('Register') and a well-scoped resource ('a caller-owned Wu Wei execution profile') and enumerates the profile kinds (reuse/cache, rule, local model, tool/workflow, cloud model). This is clearly distinguishable from routing/evaluation siblings like route_task or record_route_outcome, though the description never explicitly contrasts with 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?

There is no statement of when an agent should register a profile versus use route_task or record_route_outcome, nor any prerequisite or ordering guidance (e.g. 'register before routing'). The closing line about routing hints at a downstream relationship but never converts that into an actionable trigger.

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. The description adds substantive context beyond that: it lists hard constraints, notes optional baselines, warns that allow_defer/value/urgency can yield a no-work decision with no claimed result, and says a hash-bound receipt is returned. It does not contradict 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?

Four front-loaded sentences with little waste; each adds purpose, constraints, no-work behavior, or return behavior. The long constraint list and jargon make it dense, but it is not padded.

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 complex (routing over many constraints, nested task object, output schema) and annotations/output schema cover safety and returns. However, the description omits sibling usage guidance and parameter structure for the opaque task object, so it 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% and the required task parameter is an opaque nested object. The description partially compensates by naming constraint dimensions and optional fields (allow_defer/value/urgency), but it never maps them to task properties or explains request_id, leaving invocation structure under-specified.

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 clear verb ('Choose') and resource ('route for a task'), and specifies the optimization goal ('least-burden eligible') plus hard constraints. It does not name or contrast sibling tools such as best_next_steps or record_route_outcome, so it is clear but lacks sibling differentiation.

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 or when-not-to-use guidance, and no alternative tool is named. The no-work decision and optional baselines are behavioral details, not routing guidance, so an agent must infer usage from the purpose sentence.

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 behavioral context beyond the annotations: success strengthens used edges, failure weakens them, growth and pruning follow the genome's rules under safety axioms (NG1), and it returns new developmental-ledger events. This is consistent with destructiveHint=false (weakening is a learning update, not data destruction) and idempotentHint=false (repeated submissions compound), though it doesn't say whether repeat submissions are cumulative or how to undo one.

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, front-loaded with the verb and the payload, then mechanics. The inline brace enumeration is dense but information-efficient; nothing is 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?

An output schema exists, so omitting return-value detail is fine, and the description usefully summarizes it as new ledger events. For a mutation tool with a free-form nested parameter and zero schema coverage, the main gap is the unexplained request_id and the absence of any stated prerequisite or alternative-tool guidance.

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 coverage and a free-form nested object, the description carries the full burden and mostly succeeds: it enumerates the evaluation fields (task_id, task_type, success_score bounded to [0,1], and the optional accuracy/user_satisfaction/cost_efficiency/safety_score/notes/used_nodes/used_edges). agent_id is self-evident, but request_id is never explained, so its purpose (dedup? tracing?) is left to inference.

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 effect: 'Evolve an agent with one task outcome', plus what the outcome does to the graph (strengthen/weaken edges). It is clear what the tool does, but it never distinguishes itself from the closest sibling, record_route_outcome, which plausibly also feeds task outcomes into the system.

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 calls this after a task completes because the payload is a task outcome. There is no explicit when-to-use, no prerequisites (e.g., must route_task have run first), and no statement of how it differs from record_route_outcome when both could apply.

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