wavefunction-search

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

Annotations already establish that this is a non-read-only, non-idempotent, non-destructive operation. The description adds only 'weighted by stake' but does not explain what a commitment is, whether stake is consumed, what side effects occur, or what the agent should expect.

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 single sentence is short but relies on opaque metaphor instead of actionable information. Conciseness is not the problem; under-specification is, and the sentence does not earn its place by clarifying behavior.

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

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

An output schema exists, so return values need less explanation, but the description still leaves the tool's purpose, usage context, and parameter meanings undocumented for a two-parameter mutation tool.

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

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

Schema description coverage is 0%, so the description must compensate, but it only vaguely ties 'stake' to stake_amount and says nothing about user_id. It does not clarify units, meaning, or impact of either 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 uses a quantum metaphor ('Collapse the user's wavefunction') rather than stating a concrete action or resource. 'Actionable commitment' hints at an outcome, but an agent cannot tell exactly what this tool creates or how it differs from siblings like intake or find_matches.

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

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

There is no guidance on when to use this tool, when not to use it, prerequisites, or which sibling to choose instead. The metaphor implies a conceptual step but provides no operational 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 readOnlyHint, idempotentHint, non-destructive and closed-world behavior, so the safety profile is covered. The description adds that the response covers capabilities and the input contract, but does not discuss auth, limits, or return shape, though an output schema exists.

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 one front-loaded sentence with no filler. For a zero-argument introspection tool, this is appropriately minimal.

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?

Low complexity, zero parameters, rich annotations, and an output schema mean little description is needed. It states the return content, though it could do more to signal when an agent should call it instead of the operational sibling tools.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The baseline score of 4 applies.

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

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

The description gives a specific verb ('Return') and resources ('capabilities and input contract'), making the introspection role clear. It does not explicitly contrast with the sibling green-certificate tools, so it stops short of full 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 guidance, no prerequisites, and no named alternative; the introspection purpose is only implied by the description and tool name. An agent must infer that this is the discovery or service-description 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?

While annotations cover the safety profile, the description adds crucial functional behavior, namely that the matching process is based on 'constitutional alignment' and 'ranking by alignment score.' This provides the AI with necessary operational context beyond static hints.

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, highly dense, and relevant sentence. It avoids jargon where possible and packs maximum functional information into minimum space.

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 high-level complexity of linking abstract 'collapsed intentions' to 'constitutionally-aligned agents,' the description provides an adequate conceptual framework for the tool. It clearly defines the scope and criteria of the matching operation.

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

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

The schema coverage is 0%, meaning the description is expected to define parameter semantics. It fails to add any semantic meaning or constraints to the 'user_id' parameter itself, relying solely on the context of the overall function for definition. Since 0 parameters were meaningfully annotated, the baseline score of 3 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?

The description uses strong verbs ('Match') and clearly identifies the target resource (constitutionally-aligned agents/collectives) and the mechanism (user's collapsed intention and alignment score). It distinguishes this from sibling tools by focusing on the outcome of matching.

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

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

The description implies that 'collapsed intention' must exist beforehand, suggesting a usage dependency on other tools like 'collapse'. However, it does not explicitly state this prerequisite or name alternatives, keeping it at a median guidance score.

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 declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is already given, but the description adds no behavioral context: it never says whether intake persists or registers state, what the required user_id is used for, or whether repeated calls with the same dialogue produce different results. The only added value is a hint at the response content (explicit intentions + confidence), which the output schema already covers.

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 core operation stated first and the input shape second; nothing is padded. The brevity is only a problem because content is missing, not because wording 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 values need not be explained, but for a non-read-only tool with two required parameters at zero schema coverage the definition leaves too much open. The unexplained user_id, the opaque "wavefunction" output, and the absence of any usage context make it inadequate relative to the tool's apparent role in a multi-step pipeline.

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 two required parameters, so the description must carry the burden. It partially does so for dialogue by sketching the expected item shape (role, content), but user_id is completely undocumented and the dialogue array's actual item schema (a map of string properties) is not reconciled with the shorthand shown.

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 concrete verb ("distill") and input resource (user dialogue), but the output concept "intention wavefunction" is unexplained jargon, so an agent cannot form a precise picture of the result. It also does nothing to separate the tool from siblings like find_matches or collapse, which likely operate on the same extracted-intent artifacts.

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 this tool should be called, what precedes or follows it in a workflow, or which sibling to prefer. The reader is left to infer the entire call context from the phrase "intake".

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 disclose that this is a non-read-only, non-idempotent, non-destructive, closed-world write operation. The description adds useful context about what is registered into the match index, but it does not explain duplicate handling, overwrite semantics, or indexing side effects, which matter for a non-idempotent registration tool.

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 wasted wording. It delivers the core action and data scope immediately.

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 annotations cover safety semantics and an output schema exists, the definition remains too thin for a six-parameter mutation tool. It lacks usage context, duplicate or overwrite behavior, and sufficient parameter meaning to guide 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?

The description lists mission, domain profile, constitutional alignment scores, and capacity, giving some meaning beyond the bare schema. However, with 0% schema description coverage across six parameters, it omits collective_id and name entirely and gives no format or structure detail for the object-valued fields.

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 (Register) and resource (agent/collective) and explains the destination (match index), so the core action is clear. It does not explicitly distinguish this tool from siblings such as find_matches or intake, 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?

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. An agent could infer registration precedes matching, but that is not stated.

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