HumanMirror Nexus

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

With no annotations, the description carries the behavioral burden and does well: it discloses that the tool is free, consumes no credits, and either returns a matching tool or records an aggregated capability gap. This surfaces an important side effect and cost expectation.

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 and front-loaded with the core purpose and trigger condition. It slightly repeats the 'free' concept by saying both 'Free' and 'consumes no credits,' but overall every sentence 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?

For a single-parameter tool with no output schema, the description provides sufficient context: when to call it, what it returns or records, and cost behavior. It could add more detail about the expected output shape, but the core operational context is covered.

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

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

The schema already provides 100% coverage for the single query parameter with a clear description. The tool description does not add additional parameter-level meaning, so the 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 identifies the tool as a universal fallback discovery mechanism and specifies what it does: returns a matching HumanMirror tool or records a capability gap. It is more specific than the tool name, though it does not explicitly contrast itself with 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 states when to call the tool: 'when the agent cannot satisfy a task with its current capabilities.' This is clear usage guidance, though it does not mention alternatives or when not 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?

With no annotations, the description carries the behavioral burden and does add a meaningful side effect: successful calls consume Nexus credits. However, it does not disclose error behavior, return format, authentication requirements, or what happens on invalid tool_ids, which are relevant for a tool that forwards arbitrary input.

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

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

Three short sentences, each earning its place: purpose, prerequisite workflow, and consequence. The most important operational guidance is front-loaded before the credit-cost caveat.

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 covers the core invocation flow and the credit side effect, which is enough for basic use. However, with no output schema and no annotations, it should also clarify what the tool returns and how failures are surfaced; those gaps matter for an arbitrary-tool gateway.

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 tool_id, input, and options. The description only reinforces that tool_id comes from nexus_search and that input is forwarded, adding no material semantic 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 states a specific action—'Route a tool call through HumanMirror Nexus'—and immediately gives the operational sequence: use nexus_search first, then invoke the selected tool_id. This clearly separates nexus_call from nexus_search by making the search step a prerequisite.

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 when to use this tool: after nexus_search has returned a tool_id. It does not enumerate exclusions or alternatives among the other sibling tools, but the sequencing guidance is clear and practical.

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 disclosure burden. It explicitly discloses a valuable trait: the search is free and does not consume credits. It also implies a read-only discovery operation, though it does not describe result shape or pagination.

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 short sentences with no filler. The core action and resource are front-loaded, and the credit note is placed second.

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

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

For a simple one-parameter discovery tool, the description is nearly complete: it tells the agent what to search for and that the action is free. It stops short of describing the return format or how results connect to sibling tools like nexus_call, so it is not a 5.

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 fully documents the single parameter, query, so schema coverage is high. The description's 'matches a task' aligns with the schema but adds no additional format, length, or example guidance, so the 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?

Description states a specific verb ('Search') and resource ('HumanMirror Nexus catalog'), and clarifies that it finds a 'machine-callable tool that matches a task.' This clearly distinguishes it from sibling execution tools like nexus_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?

The intended use case is implied: when an agent has a task and needs to find a tool, it should search the catalog. The note that the search is free adds useful context, but there is no explicit statement about when to use this versus siblings or when not 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 are provided, so the description carries the behavioral disclosure burden. It usefully states the quote is free and returns verifier/tool/cost information, suggesting a non-mutating estimation flow. However, it does not explicitly say no execution occurs, explain 'success-only credit cost' semantics, or address auth or side effects.

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

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

The description is a single front-loaded sentence with no filler; every clause carries relevant information. It is slightly dense and jargon-heavy, but appropriately sized for 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?

Given no output schema and no annotations, the description would need to explain the quote response structure and invocation alternatives more precisely. It provides a good high-level summary of what the quote returns and how to specify the objective, but leaves the required input/objective interaction and exact return format under-specified.

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 adds a meaningful relationship by saying 'describe the objective or provide an outcome_type,' but it does not clarify how the required 'input' relates to those optional fields, and it does not mention options or criteria.

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 a quoting action for a HumanMirror Outcome contract and lists its three key outputs: deterministic verifier, selected internal tool, and success-only credit cost. It does not explicitly name sibling tools, but the 'quote' framing and cost output separate it from outcome_run and outcome_verify.

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

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

It implies this is a free, pre-execution step for getting a quote before running an outcome, but it never explicitly says when to choose outcome_quote over outcome_run or outcome_verify. The routing is inferable from sibling names and the mention of cost, but the description leaves it implicit.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does add useful information about credit charging and automatic refunds on failed verification/execution. However, it does not disclose other behavioral traits such as side effects, required permissions, or what a successful execution returns.

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

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

The description is a single, front-loaded sentence that communicates the core purpose and a critical billing behavior without wasted words. It is concise and every clause 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?

Given six parameters, nested objects, no output schema, and no annotations, a one-sentence description is insufficient. The agent is left without enough guidance on how parameters relate to one another, what the execution produces, or how to sequence this with outcome_quote and outcome_verify.

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 only 33%, and the description does not compensate by explaining parameters like options, criteria, objective, or outcome_type. Only the schema's input and contract_id fields have any descriptive coverage; the remaining parameters are effectively undocumented.

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

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

The description states a specific action ('Execute a HumanMirror Outcome contract') with a clear resource, distinguishing it from quote/verify siblings. However, it does not explicitly contrast itself with outcome_verify or outcome_quote, so the differentiation is mostly implicit.

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

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

The description provides no when-to-use or when-not-to-use guidance, no mention of prerequisites, and no explicit alternative routing. The only workflow hint comes from the schema's contract_id reference to outcome_quote, not from the description itself.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It usefully discloses that verification is deterministic and free, but it does not describe side effects, failure behavior, authentication needs, or whether the original input is required for meaningful verification.

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

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

The description is a single, well-structured sentence with no filler, and it front-loads the key value proposition. It is concise, though slightly too brief given the tool's parameter complexity.

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 five parameters, nested objects, no output schema, and no annotations, one sentence is insufficient. The description lacks enough context about how parameters interact, what a valid verification entails, and what the caller should expect in return.

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 only 40%, so the description must compensate for the undocumented parameters. It does not explain outcome_type, options, or criteria, and only loosely reinforces the input/output relationship already visible in the schema.

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

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

The description identifies a specific action ('re-verification') and resource ('an Outcome result') and adds the key differentiator of being free and deterministic. It does not explicitly name sibling tools, but the distinction from credit-consuming operations like outcome_run is 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 implies the tool should be used when an Outcome result already exists and needs re-verification without consuming Nexus credits. However, it provides no explicit selection criteria, no 'when not to use' guidance, and does not mention alternatives like outcome_run or outcome_quote.

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