VaultCrux Platform

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

No annotations provided and description does not disclose behavioral traits such as side effects, authentication requirements, or state changes upon acceptance. The description only states the action and routing preference, lacking important operational details.

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 short and structured: first sentence states purpose, then a block of guidance. It is mostly concise, though the guidance could be considered verbose relative to the main 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?

Given the tool has one parameter and no output schema, the description covers the purpose and usage guidance adequately. However, it lacks information about return values, side effects, or error conditions, leaving some gaps for the 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 coverage is 100% for the single parameter 'package_id', which is described in the schema as 'The handoff package ID to accept.' The tool description adds no additional semantic meaning beyond the schema, meeting the baseline.

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 clearly states 'Accept an incoming handoff package,' specifying the verb 'accept' and the resource 'handoff package'. This distinguishes it from sibling tools like 'create_handoff_package'.

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 explicitly advises to prefer 'cuecrux_session' for routing and explains why, while noting backward compatibility. This provides clear when-to-use and when-not-to-use 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?

No annotations are provided, and the description does not disclose behavioral traits such as side effects, authentication requirements, rate limits, or any other important behavioral details. It only describes the query function.

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 relatively concise, with the first sentence stating the core functionality. The second paragraph about cuecrux_session is somewhat lengthy but relevant for guidance. No superfluous 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?

The description lacks details about return values, pagination behavior, or what a receipt looks like. Without an output schema, the agent is left uninformed about what the tool returns, making the tool definition 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?

The input schema covers 100% of parameters with descriptions, so the description adds no extra meaning. The description merely mentions filters without additional semantic value, resulting in a baseline score.

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 clearly states the tool searches action journal receipts with specific filters (time range, outcome, tool name). It is specific enough to convey the purpose, though it doesn't explicitly differentiate from sibling query tools like query_vault or get_journal.

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 explicit guidance: prefer cuecrux_session for routing, and this tool is for backward compatibility. This clearly tells when to use this tool vs. alternatives.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states it adds an annotation, but does not mention side effects, reversibility, required permissions, or how annotations are stored or visible. For a mutation tool, this is insufficient behavioral context.

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

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

The description is concise at four sentences. The first sentence states the purpose, and the following sentences provide necessary usage guidance. While it could be slightly more condensed, it is well-structured and front-loaded.

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

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

Given the tool's simplicity, the description covers purpose and usage guidelines but lacks details on behavioral aspects and return values. The absence of an output schema means the description should explain what happens after annotation, but it does not. This leaves gaps in understanding the tool's complete 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%, so the schema already describes all three parameters. The description does not add any additional meaning beyond the schema. According to the guidelines, this yields a baseline score of 3.

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 clearly states the tool's purpose: 'Add an annotation to the current session.' This provides a specific verb and resource. It also distinguishes itself from the sibling tool `cuecrux_session` by explaining that this tool is for backward compatibility, while the preferred tool routes to the correct channel.

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 explicitly advises to prefer `cuecrux_session` over this tool, explaining that it returns a typed capability plan that handles routing. It states that a single call per session is sufficient and that this tool remains for backward compatibility. This provides clear when-to-use and when-not-to-use 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?

No annotations provided, so description carries full burden. It does not mention that the tool is read-only or any other behavioral traits (e.g., permissions, side effects). However, the tool's purpose is simple listing, and lack of detail is a minor gap.

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?

First sentence is concise and front-loaded. The additional cuecrux_session guidance, while valuable, is slightly lengthy but still justified.

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 tool's simplicity (one optional param, no output schema), the description covers the core purpose and provides session routing context. Lacks details on return format or prerequisites, but adequate for the complexity level.

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 the single 'limit' parameter, which already documents its meaning. The description adds no additional semantic information beyond what the schema 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?

Description clearly states 'List available credit bundles for purchase.' with specific verb and resource. Differentiates from sibling 'purchase_bundle' by being a read-only list operation.

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?

Explicitly advises to prefer 'cuecrux_session' first, indicating this tool is for backward compatibility. Provides clear context on when to use this tool versus the session-based routing approach.

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?

No annotations are present, so the description must carry the burden of behavioral disclosure. It only mentions backward compatibility and the 'collapsed surface' concept, but fails to detail side effects, required permissions, idempotency, or error conditions. This is insufficient for a mutation tool with no 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?

The description is only two sentences for the core purpose, plus a block about cuecrux_session. The latter, while relevant to guidance, is somewhat tangential for the tool's own definition. Overall it is concise but the second paragraph could be integrated more tightly.

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

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

For a simple mutation with 2 parameters, no output schema, and no annotations, the description provides enough to understand the function. However, it omits details like role constraints or how the seat is identified, and the strong redirection to cuecrux_session might imply this tool is not the primary path. Adequate but not thorough.

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 parameter descriptions are already present. The description adds no new semantic information about seat_id or role beyond what the schema provides. Baseline 3 is appropriate as no value is added.

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

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

The description opens with a clear verb+resource statement: 'Change the role assigned to an existing organisation seat.' This distinguishes it from siblings like invite_seat or revoke_seat. The purpose is unambiguous.

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

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

The description explicitly tells the agent to prefer cuecrux_session and explains why ('returns a typed capability plan that routes this tool...'), providing a clear when-to-use vs. alternative. It also notes backward compatibility, leaving no ambiguity about intended usage.

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?

No annotations are present, so the description carries the full burden. It only states the action without describing side effects, permissions, rate limits, or response structure. Insufficient for an agent to understand behavioral implications.

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 concise sentences front-loading purpose and usage guidance. No filler or repetition; every sentence adds value relative to the tool's role.

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?

Missing details about return value (no output schema), required authentication, and parameter semantics. With no annotations and sparse description, the definition is incomplete for an agent to invoke the tool correctly without external knowledge.

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 has 0% description coverage and the description offers no additional meaning for any of the three required parameters (body, work_id, author_passport). The agent relies solely on parameter names, which is inadequate.

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?

Clearly states verb ('Post a comment'), resource ('on a work item'), and intent ('leave context for the next agent or human'). Distinct from siblings which handle creation, state updates, or queries.

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?

Explicitly recommends cuecrux_session as preferred routing and notes this tool remains for backward compatibility. Provides clear when-to-use vs. alternative 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?

No annotations provided, so description carries full burden. Only states purpose and routing preference. Does not disclose effects, side effects, permissions, rate limits, or what happens upon creation.

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 sentences, each earning its place: purpose, preferred alternative, and backward compatibility note. Front-loaded with key action.

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?

Missing output schema and behavioral details. For a creation tool, should explain what the response contains, any side effects, or post-creation state. Incomplete given tool complexity and lack of annotations.

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% with descriptions for all 4 parameters. Description adds no additional meaning beyond schema, so 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?

Clearly states 'Create a multi-agent coalition to address a knowledge gap.' Specifies verb and resource. However, it does not explicitly differentiate from sibling 'join_coalition' but name implies creation.

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?

Explicitly prefers 'cuecrux_session' over direct use, stating it should be the first call. Provides backward compatibility context. Does not mention when to use this tool directly or contrast with 'join_coalition'.

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?

No annotations provided, so description carries full burden. It only mentions backward compatibility but lacks details on side effects, prerequisites, permissions, or return behavior. Incomplete behavioral disclosure.

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

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

Three sentences, front-loaded with purpose, no wasted words. Every sentence adds value.

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

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

No output schema, no annotations. The description does not explain what a handoff package is, how it is used, or what the response contains. Despite good usage guidance, it leaves many contextual gaps.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add any further meaning beyond the schema's minimal descriptions of 'scope' and 'session_id.' No elaboration provided.

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?

First sentence clearly states the tool's purpose: 'Create a handoff package for multi-agent session transfer.' It uses a specific verb and resource, and distinguishes from sibling tools like accept_handoff_package.

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?

Explicitly advises preferring cuecrux_session over this tool, stating that this is for backward compatibility. Provides clear when-to-use guidance and 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?

No annotations are provided, so the description must carry the full burden. It only discloses the default state and the recommendation to use `cuecrux_session`. It does not mention creation side effects, idempotency, required permissions, or error handling, leaving major behavioral traits undisclosed.

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 two sentences, front-loaded with the main purpose. The first sentence is concise; the second is longer but provides important usage context. It is not overly verbose, but the second sentence could be slightly more terse. Overall, it is well-structured.

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 9 parameters, no output schema, and no annotations, the description should offer comprehensive context. However, it only covers the default state and the session preference. It lacks information on return values, error cases, parameter semantics, and preconditions, making it incomplete for an AI to use 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?

The input schema has 9 parameters with 0% schema description coverage. The description only mentions that 'state' defaults to 'planned'. It does not explain the meaning or purpose of 'body', 'title', 'linked_pr', 'tenant_id', 'project_id', 'linked_issue', 'assignee_passport', or 'created_by_passport', leaving the agent without sufficient parameter-level guidance.

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 clearly states the tool creates a new work item under a project, with a default state of 'planned'. The verb 'create' and resource 'work item' are unambiguous. While there are many sibling tools, the description implicitly distinguishes by describing a core creation action, which is different from update or query tools.

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 explicitly advises preferring `cuecrux_session` for routing, providing a clear usage alternative. It mentions this tool remains directly callable for backward compatibility, which implies when to use it directly. However, it does not contrast with other sibling tools like 'update_work_state' or 'comment_on_work', so some guidance is missing.

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

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

With no annotations provided, the description carries full burden. It explains the returned plan, routing through channels, identical behavior across deployments, HTTP/2 vs MCP fallback, and protocol version. It does not mention error handling or side effects, but the core behavioral traits are well disclosed.

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 relatively long and covers many details, but it is front-loaded with the main purpose. While every sentence adds value, the length reduces conciseness. A tighter version could be more efficient.

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

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

Given the tool's complexity (nested parameters, no output schema), the description covers purpose, usage, behavioral traits, and parameter context. It explains the return type (typed capability plan) and routing behavior, which is sufficient for an agent to use the tool effectively.

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 baseline is 3. The description does not add parameter-specific details beyond what the schema already provides; it focuses on overall behavior. Thus, it meets but does not exceed the baseline.

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 starts with a specific verb and resource ('Opens a CueCrux session and returns a typed capability plan'), clearly stating the tool's function. It explicitly distinguishes from siblings by advising not to browse the legacy per-service tool list once a plan channel covers the capability.

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 explicit guidance: 'Call this first, once.' It explains when to use this tool versus alternatives (legacy per-service tools) and covers different deployment scenarios (local vs hosted, v1 vs v2 plan shapes). This makes it clear when and why to invoke this tool.

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?

No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authorization needs, or rate limits. This is a significant gap for a tool that likely modifies data.

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 mostly concise with two sentences and a paragraph, but the paragraph about cuecrux_session could be more streamlined. It is well-structured and front-loaded with 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?

Given no output schema, the description lacks information about return values, required conditions, or error handling. It feels incomplete for a tool that performs an action.

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 baseline is 3. The description does not add additional meaning beyond the schema; it only restates the tool's purpose without elaborating on parameters.

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 clearly states the verb 'declar' and resource 'willingness to pay for a feature or category', with the purpose of prioritizing the product roadmap. It is distinct from sibling tools.

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 explicitly recommends using 'cuecrux_session' first and notes that this tool is directly callable for backward compatibility, providing clear usage 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?

With no annotations provided, the description must disclose behavioral traits. It merely restates the compare function and routing advice, but does not mention side effects, permissions, rate limits, or any internal behavior. The description adds little beyond the basic purpose.

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

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

The first paragraph is concise. The second paragraph contains important usage guidance but is slightly verbose; it could be tightened without losing meaning. Overall, it is reasonably structured and front-loaded.

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

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

The description lacks details about the output format (how differences are highlighted) and any prerequisites or error conditions. For a comparison tool, such context is important to understand the result. This makes the description 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 coverage is 100%, so the input schema already describes the two parameters as 'First receipt ID.' and 'Second receipt ID.' The description adds no additional semantic context or constraints beyond what the schema provides. Baseline 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 first sentence clearly states the tool compares two provenance receipts and highlights differences, which is a specific verb-resource combination. However, it does not explicitly distinguish from sibling tools like get_proof_receipt or pin_receipt, leaving some ambiguity about the exact scope.

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 explicitly advises to prefer `cuecrux_session` over direct calls, and states that this tool remains directly callable for backward compatibility. It provides clear when-to-use (as fallback) and when-not-to (prefer cuecrux_session), with an alternative 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?

No annotations are provided, so the description must convey behavioral traits. It describes the tool as explaining how an answer was derived, implying a read-only operation, but does not detail permissions, rate limits, or side effects. It adds context about its relation to cuecrux_session but lacks full behavioral disclosure.

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

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

The description is efficient, front-loading the purpose then providing critical usage guidance. It could be slightly more concise, but every sentence adds value and it avoids unnecessary fluff.

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 lacks an output schema, so the description should explain what the tool returns. It does not describe the response format, error conditions (e.g., if no last answer exists), or prerequisites. The guidance about cuecrux_session is helpful but leaves gaps in completeness.

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 baseline is 3. The description does not add new information about the single optional parameter beyond what is already in the JSON schema ('The answer ID to explain (defaults to last answer)').

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 clearly states 'Explain how the last answer was derived.' It identifies the specific verb (explain) and resource (last answer), and distinguishes itself from siblings by noting that cuecrux_session should be preferred, making its role as a backward-compatible interface clear.

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 explicit guidance: 'Prefer cuecrux_session as your first and only direct MCP call... This tool remains directly callable for backward compatibility; the collapsed surface is the intended surface.' It tells the agent when to use which tool and what the intended workflow is.

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?

No annotations are provided, and the description only says 'scan', implying read-only but not explicitly stating whether it modifies anything, its cost, rate limits, or side effects. It lacks essential behavioral disclosure.

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

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

The description is short, but most of it is a diversion to cuecrux_session rather than focusing on the tool itself. It could be more direct about its own functionality.

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 description lacks details about output format, what contradictions look like, or how the knowledge sources are defined. With nested parameters and no output schema, more context is needed for effective use.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema's minimal descriptions, meeting the baseline for high 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 states 'Scan for contradictions across knowledge sources', providing a verb and resource, but it's vague about what 'contradictions' entails and the scope of 'knowledge sources'. The bulk of the text redirects to another tool, muddling the purpose.

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 explicitly advises to 'Prefer cuecrux_session as your first and only direct MCP call' and states this tool is for backward compatibility, giving clear direction on when to avoid it and a 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?

No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, destructive, or any side effects. The focus is on usage routing, not on 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?

The description is concise, with the core purpose in the first sentence. The second sentence is lengthy but provides important meta-instruction. Could be more streamlined, but overall efficient.

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

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

The tool has low complexity with only two parameters and no output schema. However, the description omits behavioral details and does not hint at the return value or output format. It is incomplete for an agent to fully understand the tool's effects.

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 schema already documents both parameters (domain, artefacts). The description adds no additional meaning or context about the parameters beyond what the schema 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 first sentence clearly states the tool forecasts obsolescence of artefacts. However, it does not differentiate from sibling tools that may perform similar predictions or analyses. The purpose is clear but lacks explicit 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?

Explicitly instructs to prefer cuecrux_session as the primary call for routing, and clarifies that this tool is for backward compatibility. Provides clear when-to-use and when-not-to-use 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?

No annotations provided, so the description must disclose behavioral traits. It only says 'Get the currently active policy' and mentions backward compatibility, but lacks details on side effects, permissions, or any safety implications. Minimal transparency.

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 purpose, but includes several sentences promoting cuecrux_session that are not directly about this tool. Could be more concise while retaining guidance.

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 parameter and no output schema, the description lacks details on return values, behavior when called directly vs. through session, and potential constraints. Heavily steers away from using the tool, making it incomplete for standalone understanding.

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 baseline is 3. The description does not add any extra meaning to the 'policy_name' parameter beyond what the schema provides. No additional context.

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 starts with 'Get the currently active policy,' which clearly states the verb and resource. However, the lengthy advice about preferring cuecrux_session may obscure the core purpose. Still, it is clear enough.

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?

Explicitly instructs to prefer cuecrux_session for routing, and states this tool is for backward compatibility. This provides strong guidance on when to use an alternative vs. this tool directly.

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?

No annotations are provided, so the description must carry the full burden. It only states it lists beliefs with filters and is for backward compatibility, but lacks details on side effects, auth needs, rate limits, or return behavior beyond listing.

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

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

The first sentence is concise, but the second paragraph is lengthy and contains guidance that could be more succinct, introducing jargon like 'collapsed surface'.

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

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

No output schema exists, yet the description does not describe return format, ordering, pagination behavior, or result fields, leaving significant gaps for a listing 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 100%, so the schema already documents the parameters. The description adds no additional meaning or context beyond what's in the schema, meeting the baseline but not exceeding it.

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 clearly states 'List registered beliefs with optional filters', providing a specific verb and resource. It distinguishes from siblings by advising to use cuecrux_session instead, indicating this tool is for backward compatibility.

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 explicitly recommends cuecrux_session as the primary tool and explains why, providing clear guidance on when to use this tool (backward compatibility) versus the 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?

No annotations exist, so the description must disclose behaviors. It only mentions estimation of impact, with no information about side effects, permissions, rate limits, or output format. Minimal transparency.

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 core description is short, but the usage guidelines paragraph makes the overall description lengthy and not front-loaded. Could be more concise and better structured.

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

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

No output schema and no annotations. The description lacks context about return values, how to interpret 'blast radius', or the nature of the analysis. Leaves the agent underinformed.

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% with basic parameter descriptions. The tool description adds no extra semantics beyond the schema. 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 states a specific verb ('estimate') and resource ('impact radius') but does not clarify what 'impact radius' means precisely or differentiate from siblings like 'get_break_analysis' or 'get_counterfactual_summary'.

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?

Explicitly recommends preferring 'cuecrux_session' as the primary workflow and notes this tool is for backward compatibility. Provides clear when-to-use vs when-not-to-use 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?

No annotations provided, so the description carries full burden. It discloses backward compatibility but omits side effects, authorization needs, and output format.

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 short but front-loads usage guidance about a different tool, which may distract from the primary purpose. Could be more concise.

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 no output schema and 3 optional parameters with potentially ambiguous distinction, the description lacks sufficient detail on output and parameter selection criteria.

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%; the description adds no additional parameter meaning beyond the schema. Baseline score 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 clearly states the tool's purpose: analyzing breakage from invalidating answers or receipts. However, it does not differentiate from the similar sibling 'get_blast_radius'.

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?

Explicitly advises preferring 'cuecrux_session' and notes this tool is for backward compatibility, providing strong when-to-use and when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only or destructive, any permissions needed, or what happens if parameters are invalid. The only behavioral hint is about backward compatibility, which is insufficient for safe invocation.

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 purpose and then provides routing guidance. It is clear but slightly verbose in repeating the cuecrux_session advice. Could be tightened by merging sentences, but it remains readable and efficient overall.

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

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

No output schema exists, yet the description does not describe the return value or format of the counterfactual summary. For a tool generating a summary, this is a significant gap. Parameters are simple, but the agent lacks expectation of what the output looks like.

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% with brief descriptions for both parameters. The description adds no additional meaning or context about how 'answer_id' and 'receipt_id' relate or their expected formats. Baseline 3 is appropriate since schema handles basic semantics, but no extra value is provided.

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 clearly states the tool generates a counterfactual summary for an answer. The verb 'Generate' and resource 'counterfactual summary' are specific, but it does not differentiate from siblings like 'explain_last_answer' or 'get_break_analysis', which may have overlapping functionality.

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 explicitly advises to prefer 'cuecrux_session' over direct use, stating it returns a routing plan. It clarifies that this tool is for backward compatibility and the intended surface is through the session call. This provides excellent guidance on when to use this tool vs. alternatives.

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?

No annotations exist, so the description must convey behavioral traits. It indicates a read-like operation but does not explicitly state it is read-only, nor does it mention any side effects, authentication needs, or rate limits. Basic transparency is present but not detailed.

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 includes a lengthy paragraph about cuecrux_session and routing, which is tangential to the tool's core purpose. This makes the description unnecessarily verbose and unfocused, violating conciseness.

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 simplicity (0 params, no output schema), the description adequately outlines what is retrieved. However, it lacks explanation of terms like receipt verification or passport data, and does not connect to sibling tools or preconditions. It is sufficient but not thorough.

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?

Input schema has zero parameters with 100% coverage, so the baseline is 3. The description adds meaning by detailing what the tool returns (credit balance, receipt verification, passport data) but does not need to explain parameters since there are none. This meets the baseline without exceeding it.

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 clearly states the tool retrieves the credit balance, and specifies it includes receipt verification and passport data. However, it does not differentiate from sibling tools like get_credit_escrow or get_spend_receipt, leaving ambiguity about when to use this specific tool.

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

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

The description provides guidance to prefer cuecrux_session for routing but fails to address when to use this tool versus other get tools. It mentions direct callability for backward compatibility but lacks context on typical use cases 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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states that the tool lists active escrow holds, without mentioning side effects, authorization requirements, or the meaning of 'active'. This minimal disclosure is adequate but not thorough.

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 concise, containing a clear purpose statement and a usage note about preferring `cuecrux_session`. While the usage note adds length, it is relevant and valuable, making the description efficient overall.

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 description does not explain what an escrow hold is or what qualifies as 'active', and lacks mention of return values or pagination. Given the simplicity of the tool (no parameters), the description is minimally adequate but could benefit from more context.

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 input schema has zero parameters and 100% coverage, so the description does not need to explain parameters. The description adds no parameter information beyond the schema, but this is acceptable given the absence of parameters.

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 clearly states the action ('list') and the resource ('active escrow holds') for the tenant. This is specific and unambiguous, distinguishing it from similar tools like get_credit_balance which likely returns a balance rather than a list of holds.

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 explicitly advises to prefer `cuecrux_session` over this tool for new work, noting that this tool remains directly callable for backward compatibility. This provides clear guidance on when to use this tool versus alternatives.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It states the tool is directly callable for backward compatibility, implying it is a legacy path. However, it does not describe side effects, required permissions, caching behavior, or what the briefing contains, leaving gaps in transparency.

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 purpose but then spends over half the text on recommending an alternative tool. While informative, the recommendation could be more concise or placed after the description to keep the focus on the tool itself.

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

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

For a simple, parameterless tool with no output schema, the description provides the basic purpose and usage context. However, it lacks detail on what the briefing includes, update frequency, or response format, which would improve completeness.

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 baseline is 4. The description does not add parameter specifics (none needed), but it does not confuse either. It is adequate given the parameterless nature.

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 'Get the daily knowledge briefing' which clearly identifies the action and resource. However, it does not differentiate from siblings with similar 'get_' prefixes, and the branding term 'knowledge briefing' may be ambiguous without context.

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 explicitly advises preferring `cuecrux_session` as the primary call and explains why (returns a routing plan). It notes this tool remains directly callable for backward compatibility. This provides clear usage guidance, but does not delineate specific scenarios where direct use is better.

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?

No annotations are provided, so the description fully carries the burden. It mentions backward compatibility and that cuecrux_session returns a plan for routing, but it does not disclose any safety traits (e.g., read-only, side effects) or permissions. The behavioral context is partial.

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 concise (four sentences), front-loaded with the purpose, and every sentence adds value: purpose, usage preference, rationale, and legacy status. No extraneous content.

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 no parameters and no output schema, the description adequately states the tool's function and relationship to cuecrux_session. However, it lacks details about the output format or what 'domain affinity scores' represent, leaving some ambiguity for the 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?

The input schema has zero parameters and is 100% covered by documentation. The description adds no parameter-level details because there are none, so a 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 first sentence clearly states the tool's purpose: 'Get the agent's domain affinity scores.' It uses a specific verb+resource and distinguishes itself from siblings by noting that cuecrux_session is preferred, implying this is a legacy tool.

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

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

The description explicitly advises to prefer cuecrux_session as the primary MCP call, stating that this tool is for backward compatibility only. This provides clear when-to-use and when-not-to-use guidance, distinguishing it from the 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The word 'retrieve' implies a read-only operation, but the description does not explicitly state that there are no side effects, no permissions required, or any other behavioral traits. It is adequate but minimal.

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 short and efficient: one sentence for purpose, then a focused paragraph on usage guidance. Every sentence earns its place without redundancy, and the structure is clear.

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 absence of parameters, output schema, and annotations, the description fully covers what the tool does, what data it shows, and how it should be used. It provides complete context for an AI agent to select and invoke the 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?

The input schema has zero parameters, and the description does not need to add parameter information. Baseline for 0 parameters is 4, and the description adds no unnecessary detail.

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 clearly states the tool retrieves the economy dashboard for the agent, listing specific contents (balances, transactions, spending summaries). The verb 'retrieve' and resource 'economy dashboard' are unambiguous, and the tool name is distinct among siblings.

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 explicitly recommends preferring `cuecrux_session` as the primary call, explains why (returns a typed capability plan), and notes this tool is for backward compatibility only. This provides clear when-to-use and when-not-to-use guidance with a specific 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?

No annotations are provided, so the description bears full responsibility. However, it only mentions backward compatibility and hints at legacy status but does not disclose read-only behavior, authorization needs, rate limits, or return pagination details.

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 purpose in the first sentence, and the remaining sentences provide important usage guidance. While concise, the guidance portion could be slightly tightened.

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

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

There is no output schema, yet the description does not explain the return format or structure. It also omits details on parameter value ranges or examples, leaving the agent under-informed for 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 coverage is 100%, so the input schema already describes all 4 parameters. The description only restates two filter parameters (category, status) without adding syntax or examples, providing marginal value beyond the schema.

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

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

The description clearly states the tool lists feature requests with optional filtering by category and status. It does not explicitly distinguish from sibling tools, but the verb and resource are specific and clear.

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 explicitly advises to prefer `cuecrux_session` as the first MCP call for routing, and notes this tool is directly callable for backward compatibility. This provides clear when-to-use and when-not-to-use guidance along with an 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?

No annotations are provided, so the description carries the full burden. It describes fetching, filtering, and pagination but lacks details on authentication needs, rate limits, side effects, or behavior when no results are found. Basic read behavior is implied but not comprehensive.

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 concise paragraphs: first sentence delivers the core purpose, second adds critical usage guidance. Every sentence earns its place with no fluff or repetition.

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 no output schema and no annotations, the description covers basic purpose and filtering but does not explain return format, default behavior (e.g., default limit), ordering, or error conditions. The guidance on cuecrux_session is helpful but does not complete the picture for the tool itself.

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 description adds only marginal value by grouping filters as 'time range, entry type, and pagination' and noting cursor is from a previous response. The schema already describes each parameter adequately.

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 clearly states the verb 'Fetch' and resource 'journal entries' with scope 'for the active agent'. It mentions optional filtering by time range, entry type, and pagination, but does not explicitly differentiate from the sibling 'action_journal_query', which could have overlapping functionality.

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 strongly recommends using 'cuecrux_session' first for routing and states this tool is for backward compatibility. It provides clear context for when to use the alternative, but lacks explicit when-not-to-use or exclusion cases for direct calls.

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?

No annotations are provided, so the description must disclose behavioral traits. It only states 'Identify knowledge gaps' with no details on side effects, permissions, rate limits, or output format. For a data retrieval tool, the lack of output structure or pagination behavior is a significant gap.

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; the first is concise. The second sentence is a bit long and contains multi-clause routing advice, but it is still relatively efficient. Could be tighter without losing utility.

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 no output schema, the description should hint at the return structure (e.g., list of gaps with domain details). It does not. Also missing context on how domain filtering or pagination works. The tool is simple but the description leaves several practical usage details unaddressed.

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

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

Input schema has 100% description coverage for all three parameters (limit, domain, offset). The description adds no additional meaning beyond what the schema provides, so baseline 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 clearly states the tool identifies knowledge gaps across domains (specific verb+resource). It distinguishes from siblings like 'get_break_analysis' or 'get_beliefs' by focusing on gaps. The additional routing advice somewhat clutters but does not obscure the core purpose.

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?

Explicitly instructs to prefer 'cuecrux_session' first, explains why, and clarifies this tool is for backward compatibility. This provides clear when-to-use and when-not-to-use guidance, directly addressing alternatives.

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

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

With no annotations, the description carries full burden, but it only says the tool 'returns a trust passport'. It does not disclose behavioral traits such as whether it is read-only, any side effects, or what the passport contains. The mention of backward compatibility hints at deprecation but lacks depth.

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 four sentences, but the last three focus on recommending cuecrux_session rather than the tool itself. While the guidance is valuable, the core action is stated briefly, and the structure could be more front-loaded with immediate behavioral details.

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 no output schema and no annotations, the description provides minimal context. It explains the tool's direct use and backward compatibility, but does not describe the return format, any prerequisites, or what 'trust passport' entails. 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?

There are zero parameters, and the schema coverage is 100% (empty schema). The description adds no parameter info, but baseline for no params is 4. It does not need to say more about parameters.

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 first sentence 'Retrieve the agent's trust passport' uses a specific verb and resource, clearly stating the tool's action. It distinguishes itself from sibling tools like verify_passport, and the purpose is unambiguous.

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

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

The description explicitly advises preferring cuecrux_session over this tool, stating it returns a typed capability plan that routes all tools. It also clarifies that get_passport remains directly callable for backward compatibility, providing clear when-not and alternative 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?

No annotations provided; description only states retrieval without mentioning safety, side effects, or requirements. Lacks explicit read-only or non-destructive guarantee, though implied by 'retrieve'.

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?

Concise with front-loaded purpose. Extra paragraph on cuecrux_session is useful but slightly tangential, keeping overall length appropriate.

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 no parameters, output schema, or annotations, the description adequately covers the tool's purpose. Could specify return value format for greater completeness.

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?

Zero parameters; baseline score of 4 applies. Description does not add parameter info, but none is needed. Schema coverage is 100%.

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?

Clearly states 'Retrieve current pricing information for the tenant', specifying verb and resource. Distinguishes from siblings by noting backward compatibility preference, but could add more detail on what pricing info includes.

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?

Explicitly recommends using cuecrux_session first, describes its role, and clarifies that direct calls are for backward compatibility. Strong guidance on when and when not to use this tool.

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

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

With no annotations, the description carries the behavioral burden. It discloses the tool returns specific project details and implies a read-only operation. It also transparently flags backward-compatibility status and the preferred alternative path, adding context beyond raw purpose.

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 brief: a one-line summary followed by a necessary usage note. Every sentence adds value, and the critical guidance (prefer cuecrux_session) is front-loaded. No extraneous text.

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 tool's simplicity (one parameter, no output schema), the description covers the essence: what it returns and how to use it properly. It lacks details on errors or output format, but the core context is sufficient for a straightforward fetch operation.

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

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

Schema coverage is 0%, and the description does not elaborate on the single parameter 'project_id' beyond implying it identifies the project. The format, source, or example are missing, leaving the agent with minimal guidance for constructing a valid 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 clearly states it provides 'detail for a single project' including specific fields like 'planning target, allowed passports, working tenants.' This distinguishes it from sibling tools like 'list_projects' that list all 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?

The description explicitly advises to prefer 'cuecrux_session' as the primary call, explaining that it returns a routing plan for optimal channel, tier, and cost class. It notes this tool is directly callable for backward compatibility but the 'collapsed surface is the intended surface,' giving clear when-to-use 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?

With no annotations, the description carries the burden of behavioral disclosure. It mentions the constraint 'completed proof job' and pagination support, but does not clarify idempotency, safety, or error states. It adds useful context about cuecrux_session routing, but lacks full transparency.

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 purpose in two sentences. The second paragraph on cuecrux_session is relevant but slightly verbose, though it adds valuable guidance. Overall efficient for the information conveyed.

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 has only two parameters, but there is no output schema, so the description should explain the return format. It mentions 'chunk-level hashes' and cursor-based pagination, but does not detail the response structure. It is somewhat incomplete for a tool with no output schema.

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

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

Input schema coverage is 100% with descriptions for both parameters (proof_job_id and cursor). The description adds no new parameter-level information beyond what the schema provides, so baseline 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 clearly states the tool retrieves chunk-level hashes for a completed proof job and supports cursor-based pagination. It distinguishes itself from sibling tools like get_proof_receipt and get_proof_status by specifying exactly what data it returns.

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 explicitly advises preferring cuecrux_session as the first call for routing, and notes that this tool remains callable for backward compatibility. This provides clear guidance on when to use this tool versus the cuecrux_session workflow.

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?

No annotations provided, but the description only states 'Download' and contents. It does not disclose auth requirements, rate limits, or whether it is idempotent. Behavioral traits are minimally described.

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

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

Three sentences with all information front-loaded. No fluff, each sentence adds value: purpose, contents, and usage guidance.

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

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

For a simple download tool with one parameter and no output schema, the description covers the main purpose and usage guidance. Could mention output format or error handling, but overall adequate.

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% with a single parameter described in schema. The description does not add extra meaning (e.g., format, source, or prerequisites) beyond what the schema says.

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 clearly states the verb 'Download' and the resource 'full proofpack bundle for a receipt', listing included contents. This distinguishes it from siblings like get_proof_chunks or get_proof_receipt.

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?

Explicitly advises to prefer cuecrux_session as the primary entry point, and explains this tool is for backward compatibility. Provides clear when-to-use guidance, though does not compare to other proof-related siblings.

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?

No annotations provided, but the description openly states it retrieves data (read operation) and describes the receipt's components. It does not mention auth needs or rate limits, but for a simple retrieval tool this is sufficient.

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 four sentences, front-loaded with purpose, and every sentence adds value. No fluff or redundant 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 tool with one parameter and no output schema, the description covers its purpose, contents of the receipt, and usage guidance. It is fully adequate for an agent to understand and invoke 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 coverage is 100% and the parameter 'answer_id' is already described in the schema as 'The answer ID to get the proof receipt for'. The description adds no additional semantic value beyond what the schema 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 clearly states the tool retrieves a cryptographic proof receipt for a specific answer and lists its contents (Merkle root, signature, verification metadata), distinguishing it from siblings like get_proof_chunks and get_proof_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?

Explicitly advises to prefer cuecrux_session first for routing, explains that the tool remains directly callable for backward compatibility, and clarifies the intended surface, giving clear when-to-use and when-to-avoid 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?

No annotations exist, so description must disclose behavior. It explains it's a poll and returns state/progress, but doesn't explicitly state it's read-only or mention any side effects, though it's implied. Lacks depth on auth or rate limits.

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

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

The description is two sentences of core purpose followed by a paragraph of usage guidance. Efficient and front-loaded, but slightly wordy in the second part. No wasted content.

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 simple purpose, single parameter, and no output schema, the description fully covers what the tool does and how to use it appropriately, including relative placement against the sibling cuecrux_session.

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% with a clear description for proof_job_id. The description adds no extra meaning beyond the schema, so baseline 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 clearly states the tool polls the status of a proof job, listing possible states and that it returns progress details. It distinguishes from sibling tools like get_proof_chunks by focusing on 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?

Explicitly advises to prefer cuecrux_session for routing and states this tool is for backward compatibility, providing clear guidance on when to use 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?

No annotations provided. Description only indicates a read operation ('get') but lacks disclosure of side effects, permissions, or response behavior. Minimal behavioral context.

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

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

Over half the description promotes cuecrux_session rather than the tool itself. Verbose and unfocused; could be reduced to one sentence about the tool's 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?

No output schema; description does not explain what a reasoning profile contains or how to interpret the result. Incomplete for a tool with no structural hints.

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?

Zero parameters with 100% schema coverage; baseline score applies. Description adds no parameter details, but none are needed.

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

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

The description states 'Get the agent's current reasoning profile,' which is a specific verb+resource. However, it does not differentiate this tool from siblings like get_beliefs or get_knowledge_gaps, and the emphasis on cuecrux_session dilutes focus.

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?

Explicitly says 'Prefer cuecrux_session as your first and only direct MCP call' and clarifies this tool is for backward compatibility. Provides clear when-to-use and alternative 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?

No annotations are provided, so the description must disclose behavior. It indicates retrieval of session context but does not describe the return format, data freshness, or any side effects. For a tool with zero parameters, the description could still elaborate on what 'recent interactions and state' entails. Lacks sufficient detail for an agent to fully understand the 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?

The description is two sentences, with the purpose front-loaded. The second sentence is lengthy but provides important usage guidance. It is concise overall, though the second sentence could be slightly more streamlined.

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 no output schema and zero parameters, the description should explain what the returned session context includes. It vaguely mentions 'recent interactions and state' but lacks specifics. For an agent considering direct use, more detail is needed. The guidance to prefer cuecrux_session partially compensates.

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 input schema has zero parameters, so schema coverage is 100%. The baseline for no parameters is 4. The description does not need to add parameter information, and it does not, 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?

The description clearly states the tool retrieves 'current session context for the active agent, including recent interactions and state.' It uses specific verbs ('retrieve') and resource ('session context'), and distinguishes itself from sibling 'cuecrux_session' by noting it is for backward compatibility.

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 explicitly advises to prefer 'cuecrux_session' as the first call and explains why: it returns a typed capability plan that routes this and other tools. It states this tool is for backward compatibility and the collapsed surface is intended, giving clear when-to-use and when-not-to-use 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?

No annotations provided, so the description bears full burden. The verb 'retrieve' implies read-only, but the description does not explicitly confirm safety, idempotency, or any side effects. The routing context is helpful but not about the tool's own 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?

First sentence is concise and front-loaded with purpose. The second paragraph adds valuable usage guidance but is somewhat verbose for a simple retrieval tool. Still, it 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?

Simple tool with one param and no output schema. Description covers retrieval and routing context, but lacks details on return format, receipt contents, or potential error conditions. Adequate but not comprehensive.

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?

100% schema coverage means the schema already documents 'receipt_id'. The description adds no extra meaning beyond 'look up by ID', providing no new insights into parameter usage or constraints.

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 clearly states 'Retrieve a specific spend receipt by ID,' specifying the verb, resource, and input. It distinguishes from siblings like 'get_proof_receipt' and 'diff_receipts' by focusing on spend receipts.

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?

Explicitly advises to prefer 'cuecrux_session' for routing and notes that this tool is a direct fallback for backward compatibility. Provides clear context on when not to use it directly.

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?

No annotations provided, so the description bears full burden. It discloses the purpose but does not describe behavioral traits such as whether it is read-only, how staleness is determined, or any side effects. The description lacks depth beyond the basic action.

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

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

The first paragraph is direct and efficient. The second paragraph, while informative about usage, is slightly verbose and repeats the backward compatibility point. Overall, it is reasonably concise.

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

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

No output schema exists, but the description does not explain the response format or staleness criteria. The pagination mechanism is implied by the cursor parameter but not described. For a simple list tool, this is adequate but leaves gaps.

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

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

Schema coverage is 100% with descriptions for both 'limit' and 'cursor'. The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate since the schema already handles parameter documentation.

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 first sentence clearly states the tool lists stale pins for the active agent, specifying the resource ('pinned items') and the condition ('may be outdated and need refresh or removal'). It is specific but does not differentiate from sibling tools like 'pin_receipt' or 'get_watches' which are not mentioned.

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?

Explicitly instructs the agent to prefer `cuecrux_session` as the primary call and states that this tool is for backward compatibility. Provides clear when-to-use and when-not-to-use guidance, and names the 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?

No annotations are provided, so the description must cover behavioral traits. It fails to disclose what the tool does beyond retrieving a level, whether it has side effects, cost implications, or any operational impact. The focus on routing preference leaves behavioral gaps.

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 fairly concise, starting with a clear purpose statement. The second paragraph about cuecrux_session adds valuable guidance but could be seen as slightly verbose. Overall, well-structured and front-loaded.

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

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

The description lacks essential context: it does not explain what the trust escalation level represents, what the return value will be, or any usage constraints. Given no output schema and no annotations, the description is incomplete for an agent to understand the tool's full 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?

The tool has no parameters, and schema coverage is 100%. The description adds nothing parameter-specific, which is acceptable since there are no parameters to explain. 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 clearly states the tool gets 'the current agent's trust escalation level.' The verb 'get' and specific resource are clear. However, it does not explicitly distinguish from siblings beyond mentioning a preference for cuecrux_session, leaving some ambiguity in tool selection.

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 explicit guidance: prefer cuecrux_session over direct use, explains why (returns a routing plan), and clarifies that direct calls are for backward compatibility. This clearly tells when and when not to use the tool.

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?

No annotations are provided, so the description carries the full burden. It explains that alerts are retrieved but does not disclose any potential side effects, authentication requirements, rate limits, or response details. The behavior is implied to be read-only, but lacks explicit transparency.

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 core description is a single sentence, followed by a relevant note about `cuecrux_session`. While the note adds length, it provides important usage guidance. The structure is clear, but the key information could be more front-loaded.

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

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

Given the tool has four parameters with full schema descriptions, no output schema, and is a retrieval operation, the description covers the basic behavior, filtering, pagination, and provides integration guidance. This is complete for the tool's complexity.

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?

All four parameters have descriptions in the input schema (100% coverage). The description adds context about filtering and pagination, but does not provide additional semantic meaning beyond what the schema already offers. Thus, 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 clearly states the verb 'retrieve' and the resource 'alerts triggered by a specific watch'. It also mentions optional filtering by time and pagination. Among sibling tools, none share the same purpose, making it distinctive.

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 explicitly advises preferring `cuecrux_session` as the primary call and notes that this tool remains directly callable for backward compatibility. It also clarifies the optional filtering and pagination, guiding when to use this tool.

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?

No annotations are provided, so the description carries full behavioral burden. It states the operation is a read ('List'), but does not disclose idempotency, side effects, pagination behavior, or authentication requirements. The description is minimal in behavioral terms.

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 has two parts: a concise first line and a longer second paragraph about preferring cuecrux_session. The second paragraph, while informative, detracts from conciseness and is somewhat tangential to the tool's single purpose. Could be more streamlined.

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

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

For a simple list tool with no output schema and two optional parameters, the description covers the core purpose but lacks details on pagination defaults, what constitutes an 'active' watch, or return format. It is adequate but not fully complete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (limit and cursor). The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline of 3.

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 clearly states it lists active watches for the current agent ('List all active watches for the current agent.'). The verb 'list' and resource 'active watches' are specific, but it does not differentiate from the sibling tool 'get_watch_alerts', which could be confused. Thus, it falls short of a 5.

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

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

The description provides explicit guidance: prefer 'cuecrux_session' for routing and that this tool is for backward compatibility. It gives a clear alternative and context for when to use this tool, but it does not specify cases where direct use might be necessary, so not a 5.

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

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

No annotations exist, and the description does not disclose any behavioral traits such as side effects, authentication requirements, rate limits, or response format. This is a significant gap for a tool that is directly callable.

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 relatively short, using three sentences. The first sentence is slightly figurative but still informative. The structure is front-loaded with the core purpose, then guidance. It is largely efficient but could be more direct.

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

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

For a simple query tool, the description provides the essential purpose and usage guidance. However, it does not explain how the 'selected repos' are determined, nor does it describe the return format. Given no output schema, this leaves some ambiguity.

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 only parameter, 'limit', has 0% schema description coverage. The description does not explain its purpose or behavior beyond what is obvious from the schema constraints (min 1, max 500). It adds no value over the structured definition.

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 clearly identifies the tool as retrieving recent GitHub comments across selected repos. It uses a specific verb ('recent comments') and resource ('GitHub repos'), and distinguishes it from sibling tools like github_open_issues or github_recent_commits.

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?

Explicitly advises preferring `cuecrux_session` as the primary MCP call, explaining that it returns a capability plan for routing. It also notes backward compatibility but recommends the collapsed surface, providing clear guidance on when to use this tool vs. the 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?

No annotations are provided, so the description must bear full transparency. It only mentions 'indexed' and 'client-side filtering' but omits details on read-only nature, pagination, or return format.

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 concise with two short paragraphs. The first sentence is front-loaded with purpose. The second paragraph, while relevant to usage, detracts slightly from focus on the tool itself.

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 three parameters and no output schema or annotations, the description is incomplete. It lacks information on return values, pagination behavior, and the meaning of 'Crux-Indexed', leaving gaps for agent understanding.

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%, yet the description only explains the 'label' parameter as client-side filtering. The required 'repo' and optional 'limit' (with min/max) are left undocumented, failing to 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 first sentence clearly states the tool retrieves indexed issues from a selected repo, with an optional label filter. This distinguishes it from siblings like github_open_prs (pull requests) and github_comments_since (comments).

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 explicitly advises preferring cuecrux_session over direct use, establishing a usage hierarchy. However, it does not specify when direct use is appropriate or contrast with other GitHub tools.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It only mentions that results can be filtered client-side via the state field, but lacks details on side effects, authentication requirements, rate limits, or mutation behavior. Minimal disclosure.

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

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

The description is very concise: one sentence for purpose, one paragraph for usage guidance. Every sentence adds value without redundancy. Front-loaded with the core functionality.

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 tool with 2 parameters and no output schema, the description covers the repo parameter and the client-side filter, but omits the limit parameter and any details on output format, ordering, or pagination. Adequate but has clear gaps.

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

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

With 0% schema description coverage, the description should explain both parameters. It only implicitly covers 'repo' by mentioning 'selected repo', but does not describe the 'limit' parameter at all. Adds some meaning but insufficient 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 clearly states the tool retrieves indexed PRs from a selected repo, with client-side filtering by state. This distinguishes it from sibling tools like github_open_issues and github_search, making the purpose specific and unambiguous.

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

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

The description explicitly advises using cuecrux_session instead of this tool directly, noting that this tool exists for backward compatibility. This provides clear when-to-use and when-not-to-use guidance with a 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions 'indexed' but does not describe what that means for the agent (e.g., caching, staleness). It lacks details on read-only nature, rate limits, or error handling for missing repos.

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 relatively short but includes a substantial paragraph about routing. The purpose is front-loaded, and the additional text is relevant. It could be slightly more concise by merging the routing guidance into fewer sentences.

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 has a simple input schema (2 parameters) and no output schema. The description does not explain what 'indexed' means, the output format, or any side effects. The heavy focus on routing leaves the core functionality under-described.

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

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

With 0% schema description coverage, the description should explain the parameters. It does not mention `repo` or `limit` at all, leaving the agent to infer meaning from the schema alone. This is insufficient for effective tool use.

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 clearly states it returns 'recent indexed commits for a selected repo,' which is a specific verb+resource. However, it does not differentiate from sibling tools like github_comments_since or github_open_issues, which also retrieve GitHub data.

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 explicitly directs agents to prefer `cuecrux_session` as the primary call and limits this tool to backward compatibility. It states 'one call per session is enough,' providing clear when-to-use and when-not-to-use 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?

No annotations are provided, so the description carries full burden. It omits key behavioral details like read-only nature, rate limits, authentication requirements, result format, or pagination. The only behavioral hint is that repos are pre-selected via another endpoint, but this is insufficient for safe tool invocation.

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 relatively concise with two main ideas: purpose and usage guidance. The first sentence is efficient; the second is longer but necessary. Some redundancy exists with the repeated mention of cuecrux_session, but overall structure is acceptable.

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 3 parameters, no output schema, and no annotations, the description only covers purpose and basic usage pattern. It lacks parameter details, output description, error handling, and behavioral info, leaving the agent underinformed for a search tool expected to work with varied inputs.

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 does not explain any parameter specifics. Query is implied as search term, repo and top_k are not defined. This leaves agents guessing about parameter meanings and constraints, especially top_k's maximum of 200.

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 clearly states the tool searches an indexed GitHub corpus of commits, PRs, issues, and comments under selected repos. It distinguishes itself from sibling tools like github_open_issues by offering broad search across multiple types, making the purpose specific and distinct.

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 explicitly recommends using cuecrux_session first for routing and states this tool remains directly callable for backward compatibility. It provides clear when-to-use and when-not-to-use guidance, with a reference to alternative setup via the session.

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?

No annotations are provided, so the description should disclose behavioral traits. It only states the basic action without mentioning side effects (e.g., sending an email), permissions required, or rate limits. The agent lacks insight into what happens after the invite.

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 concise with a clear front-loaded purpose. The second paragraph about cuecrux_session, while helpful, is somewhat lengthy and could be streamlined, but overall it is efficient.

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

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

Given the lack of output schema, the description should explain return values or next steps. It does not mention what the tool returns (e.g., success confirmation, seat details) or any prerequisites (e.g., admin role). This leaves gaps for an 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 coverage is 100% and the schema already provides clear descriptions for both parameters (email and role). The tool description adds no additional semantic value beyond what is in the schema, achieving baseline 3.

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 clearly states the verb ('Invite'), the resource ('a new member'), and the method ('by email address'), making the tool's purpose unambiguous. It is distinct from sibling tools like revoke_seat or change_seat_role.

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?

Explicitly advises to prefer cuecrux_session for routing, and notes this tool is for backward compatibility. Provides clear when-to-use and when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It mentions joining with a credit pledge but does not disclose side effects, permissions, or reversibility. Minimal behavioral context.

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

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

The description includes a long paragraph of meta-instructions about another tool (cuecrux_session) that is not directly relevant to this tool's operation. This wastes space and reduces conciseness.

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 lack of annotations, no output schema, and only 2 parameters, the description fails to provide behavioral context, return value info, or prerequisites. The extra paragraph does not compensate.

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% with descriptions for both parameters. The description adds minimal extra meaning beyond 'credit pledge' hinting at pledge_crux. Baseline 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 clearly states the tool's purpose: 'Join an existing coalition with a credit pledge.' It uses a specific verb ('Join') and resource ('coalition'), and distinguishes from the sibling tool 'create_coalition'.

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 explicitly says to prefer 'cuecrux_session' over this tool and notes that this tool remains for backward compatibility. This provides clear when-to-use guidance and alternatives.

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?

No annotations provided, so the description must carry full burden. It describes the tool as listing projects and mirroring an API, but does not detail output format, authentication needs, or side effects. Given the simple read-only nature, the description is adequate but lacks explicit behavioral context.

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

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

The purpose is stated concisely in the first sentence. The subsequent usage guidance is valuable but slightly repetitive. Overall efficient, though could be tightened.

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

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

For a simple, parameterless listing tool with no output schema, the description covers purpose and usage guidance adequately. Missing details about return format, but it references the mirrored API endpoint, which provides some context.

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?

No parameters exist, and schematic coverage is 100%. Baseline for zero params is 4. The description adds no unnecessary parameter information, but is sufficient.

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 clearly states it lists all projects on the Crux Daemon and mirrors an API endpoint. It distinguishes its purpose from siblings by mentioning the preferred alternative tool, cuecrux_session, thus providing clear 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?

Explicitly advises preferring cuecrux_session for routing and capability planning, and states this tool is for backward compatibility. This provides clear when-to-use and when-not-to-use 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It correctly identifies the tool as a read operation (list seats) but does not mention authentication requirements, rate limits, or potential side effects. For a simple listing tool this is adequate but not exemplary.

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 concise with a clear front-loaded purpose. The second paragraph, while slightly wordy, provides essential routing guidance. Overall it is well-structured and efficient.

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

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

Given two parameters, no output schema, and no annotations, the description adequately explains the tool's purpose and usage context. However, it lacks detail on the return format (e.g., what fields each seat includes), which would enhance completeness for an agent invoking the 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 coverage is 100% for the two parameters ('limit' and 'cursor'), and the description does not add any meaning beyond what the schema already provides. It meets the baseline for a tool with full 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 clearly states the action ('list') and the resource ('all seats (members) in the current organisation'). It is specific and distinct from sibling tools like 'invite_seat', 'revoke_seat', and 'change_seat_role', which focus on seat management actions rather than listing.

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 explicitly recommends using 'cuecrux_session' as the primary entry point for routing, and clarifies that this tool is directly available for backward compatibility. This provides clear guidance on when to use this tool vs. the preferred 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?

No annotations are provided, so the description must carry full burden for behavioral disclosure. It does not state whether the tool is read-only, what happens when no filters are applied, or any side effects. The metaphor 'kanban surface' is insufficient.

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

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

The first sentence is clear and direct, but the following paragraph about cuecrux_session, while informative, is lengthy for this tool's definition. It could be more concise while still conveying the usage guidance.

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 4 optional parameters, no output schema, and no annotations, the description should cover return values, pagination, or default behavior. It lacks any such details, leaving significant gaps for an agent to invoke the 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?

With 0% schema description coverage, the description must add meaning to parameters. It merely lists the parameter names from the schema without any additional semantics like format, constraints, or behavior. No value added beyond restating names.

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 clearly states the tool lists work items with optional filters (project_id, state, tenant_id, assignee_passport), and calls it a 'kanban surface for cross-agent coordination.' This provides a specific verb+resource and a hint of its role, but does not explicitly differentiate from similar list tools like 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?

The description explicitly advises using cuecrux_session first for routing and only using list_work directly for backward compatibility. This provides clear when-to-use and when-not-to-use guidance with a 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?

No annotations are provided, so the description must fully disclose behavior. It lacks details on side effects, permissions, error handling, or return format. The verb 'resolve' suggests read-only but is not explicitly stated, leaving ambiguity about safety.

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 concise with two sentences and an additional paragraph. Every sentence provides value, including the routing advice about cuecrux_session, which is essential for usage. It is well-structured and front-loaded.

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

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

Given the lack of output schema, the description should explain what the tool returns, but it does not. It also does not cover error scenarios or the exact relationship with memory_session_init. Important details for an agent to correctly use the tool are missing.

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

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

Input schema has 100% coverage, so parameters are documented. The description does not add additional context beyond the schema, meeting the baseline but not exceeding it.

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 clearly states the tool resolves body content for on-demand engrams from memory_session_init, with a specific verb and resource. It distinguishes itself from sibling tools by referencing cuecrux_session as the preferred routing, making its role unique.

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?

Explicitly states when to use: 'Use when a question matches an on-demand engram's applies_when or trigger_features.' Also provides guidance to prefer cuecrux_session as an alternative, giving clear usage 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?

No annotations are provided, and the description only mentions 'using the cached Pattern B prompt' without explaining behavioral traits like state changes, permissions, or side effects. It does not add transparency beyond the basic purpose, leaving critical behavioral details unspecified.

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 three sentences long, front-loading the primary purpose, then providing usage guidance. Each sentence adds value with no redundancy, making it highly efficient and structured.

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 description lacks specification of return value or output format, which is problematic given the absence of an output schema. It implies prerequisites (prior memory retrieval) but does not make them explicit. The tool's complexity with 5 parameters and reasoning task warrants more detail about what the tool produces.

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 schema already provides clear parameter definitions. The description adds no additional parameter-level meaning beyond noting the source of chunks and facts. Baseline 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 tool's description clearly states its purpose: 'Reason over previously retrieved memory chunks and optional curated facts using the cached Pattern B prompt.' The verb 'reason' and resource 'memory chunks and facts' are specific. It distinguishes from related tools like memory_retrieve and prefers cuecrux_session, providing context for selection among siblings.

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 explicitly advises the agent to prefer cuecrux_session and notes that this tool is directly callable for backward compatibility. This provides clear guidance on when to use this tool versus the alternative, making it highly actionable.

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?

No annotations, so description carries full burden. It explains response behavior: pre_logic field should be injected before reasoning, and deterministic pre-execution may inline enumerated_facts. Also mentions calibration via modelId. Lacks explicit side effects or authorization needs.

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?

Concise (~100 words), front-loaded with purpose, then behavioral details, then usage guidance. Every sentence adds value; no redundancy.

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?

Despite no output schema or annotations, the description explains response structure (pre_logic, enumerated_facts) and usage routing. Lacks failure behavior or definition of domain terms, but adequate for agent use given complexity.

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 descriptions exist. The description adds value for modelId by explaining its role in engram dispatching and pre_logic formatting. Other parameters already clear from schema, so minimal added meaning beyond 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 specifies the verb 'Retrieve' and the resources 'memory chunks, optional curated ESI facts, and passport-driven engrams', clearly distinguishing it from siblings like memory_engrams_resolve and memory_reason_about. The mention of 'Pattern B memory reasoning' further defines its role.

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?

Explicit guidance to prefer cuecrux_session over direct calls, explaining that it returns a routing plan. Also notes backward compatibility and that the collapsed surface is intended. This clarifies when to use this tool vs alternatives.

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

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

With no annotations, the description carries full burden. It explains the tool returns a plan and is for backward compatibility, but lacks details on side effects, authorization needs, or behavior if called multiple times. The mention of 'backward compatibility' hints at deprecation but doesn't fully disclose implications.

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, focused paragraphs. The first paragraph states purpose and usage trigger; the second provides strategic context about tool preference. Every sentence adds value, no redundancy.

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?

Despite no output schema, the description lists exactly what the tool returns and positions it within a workflow (before memory_retrieve, prefer cuecrux_session). For a complex system with many siblings, this is sufficient for an agent to decide correct usage.

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 input schema covers the sole parameter 'modelId' with a clear description. The tool description adds no further meaning beyond what the schema already provides. Baseline 3 is appropriate given 100% 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 clearly states the tool's function: 'Boot a memory reasoning session' and enumerates the returned items (session procedure, passport identity, etc.). It distinguishes itself from siblings by referencing 'memory_retrieve' and 'cuecrux_session', ensuring the agent knows its specific role.

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?

Explicitly states when to call ('once before memory_retrieve when the session-init endpoint is enabled') and provides a strong alternative: 'Prefer cuecrux_session as your first and only direct MCP call'. Explains why the alternative is better, offering a clear decision rule.

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?

No annotations are provided, so the description carries full burden. It only states the purpose but does not disclose behavioral traits such as reversibility, side effects, rate limits, or authorization needs. Minimal transparency.

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 purpose and then provides usage guidelines. It is reasonably concise, though the usage alternative could be slightly more compact. Overall efficient.

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

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

For a simple action with 3 parameters (1 required) and no output schema, the description explains purpose and provides an alternative, but lacks details on return value, constraints, or what happens after pinning. Adequate but not comprehensive.

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% with descriptions for each parameter. The tool description does not add additional meaning beyond what the schema already provides. Baseline 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 clearly states 'Pin a receipt to prevent it from being garbage collected,' specifying the action and purpose. It distinguishes from siblings as no other sibling tool has 'pin' in its name, but does not explicitly differentiate further.

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 explicitly recommends preferring 'cuecrux_session' as the primary call and notes this tool is for backward compatibility, providing clear guidance on when and how to use this tool versus the 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?

Without annotations, the description fully covers the tool's behavior: async nature, retrieval, chunking, hashing, Merkle receipt creation, and return of job ID for polling. It does not mention error conditions or permissions, but the main process is transparent.

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 concise paragraphs: the first explains the tool's function and return value; the second provides critical routing guidance. Every sentence adds value, no redundancy.

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 tool with 3 parameters (1 required) and no output schema, the description is complete: it explains the process, return value, and how to use it within the broader system. It also references sibling tools for polling, ensuring context.

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% with descriptive parameter names and schema descriptions. The tool description adds no extra parameter semantics beyond what is already in the input schema, so baseline score 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 clearly states the action: 'Submit a document artefact for cryptographic proof.' It details the process (creates async proof job, chunks, hashes, produces Merkle receipt, returns job ID), distinguishing it from related tools like get_proof_status and get_proof_receipt.

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?

Explicitly advises to prefer cuecrux_session for routing, stating it returns a capability plan that directs tool usage. It explains that proof_document is directly callable for backward compatibility but the collapsed surface is intended. This provides clear when-to-use vs alternatives.

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?

No annotations are provided, so the description must disclose behavioral traits. It only says 'Purchase a credit bundle' without mentioning side effects, auth requirements, rate limits, idempotency, or return values. For a mutation tool, this is insufficient.

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 two sentences: the first states the purpose, the second provides routing guidance. No wasted words, front-loaded with essential 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?

The description lacks details about prerequisites (e.g., sufficient credits), success/failure behavior, return format (no output schema), and how the session plan interacts with this tool. Given the complexity of a purchase action, this is 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 100%, so the schema already documents both parameters. The description adds 'by ID' which aligns with the schema but does not provide additional meaning beyond what the schema states.

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 clearly states 'Purchase a credit bundle by ID,' which is a specific verb and resource. It distinguishes from sibling tools like browse_bundles (browsing) and get_credit_balance (checking balance).

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 advises preferring cuecrux_session for routing and notes that this tool remains directly callable for backward compatibility, with the session workflow being the intended surface. This provides clear context on when to use which approach, but could be more explicit about scenarios for direct use.

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?

Despite no annotations, the description indicates a read-only retrieval operation. It does not disclose additional behavioral traits like rate limits or authentication, but the semantic search nature is clear. Adequate but minimal.

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 concise with two clear parts: purpose and usage guidance. It is front-loaded with the primary action. The paragraph about cuecrux_session is necessary and not overly verbose.

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 no output schema, the description adequately explains inputs and purpose. It could mention return format briefly, but for a retrieval tool, the missing detail is not critical.

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% with descriptions for all parameters. The tool description adds no extra value beyond the schema, so 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 clearly states it retrieves relevant documents from the vault using semantic search across corpora. It distinguishes itself from the preferred cuecrux_session, providing clarity on its role as a backward-compatible direct call.

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?

Explicitly recommends using cuecrux_session instead for routing and plans, stating this tool is for backward compatibility. Provides clear when-to-use guidance and contrasts with the preferred 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?

No annotations are provided, so the description carries the full burden. It discloses trust routing, confidence filtering, and budget constraints, but does not mention side effects, permissions, or error handling. Adequate but not detailed.

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 well-structured with a clear first sentence. The second paragraph, while useful, adds length. Minor verbosity prevents a perfect score.

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 no output schema and no annotations, the description provides essential context but lacks details on return values, error conditions, or exact behavior when parameters are omitted. Adequate but not fully complete.

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