factorguide

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

No annotations provided, so the description carries the full burden. It discloses the need for an X-Wallet header and mentions trial limits, but does not specify if the operation is read-only or destructive, or what happens on failure. The mention of 'risk prediction' hints at read behavior but is not explicit.

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: tool purpose, key details, and requirements. No filler, though 'Include variances for sign detectability' is a bit terse. Overall well-structured and to the point.

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 annotations, output schema, or sibling context, the description lacks expected return behavior, error handling, or interpretation of results. For a diagnostic tool with 6 parameters, an agent needs more context to use it 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 coverage is 50% (3 of 6 parameters described). The description adds context about variances for sign detectability, which partially compensates for the undocumented variance_i and variance_j, but does not explain sample_size or coupling_value beyond the schema's minimal description.

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 it's a quick single-pair diagnostic with IC and risk prediction, which clarifies the tool's core action against siblings like factorguide_explain or factorguide_navigate. However, the phrasing is noun-heavy and jargon-laden, slightly reducing clarity.

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

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

Indicates it's a quick diagnostic for a single pair, implying it's not for multiple pairs or broader analyses. Mentions the X-Wallet header requirement and free trial, but lacks explicit when-to-use or when-not-to-use guidance compared to 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 are provided, so the description carries the full burden. It discloses that the tool consumes 1 query allocation, requires an X-Wallet header with an EVM wallet address, and notes the first 5 queries are free trial. These are important behavioral traits beyond what the input schema provides. It does not mention destructive actions, but the tool is inherently read-only.

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, consisting of three sentences that efficiently convey purpose, prerequisite, cost, and availability. No unnecessary words. It is front-loaded with 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?

The tool has only one parameter and no output schema. The description covers purpose, input, prerequisites, cost, and tiers. However, it does not describe the output format or what the explanation contains. While not critical, it would be helpful to briefly mention the output nature.

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 schema already describes 'prediction_hash' as from a previous navigate response). The description merely restates this, adding no extra meaning or nuance. Therefore, 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 provides a 'plain-language explanation of a previous navigate response, including wave mechanics grounding.' It specifies the required input (prediction_hash) and the action performed. This distinguishes it from sibling tools like factorguide_navigate (which produces the prediction) and factorguide_diagnose (which likely does something else).

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 it 'Requires a prediction_hash from a prior factorguide_navigate call,' indicating when to use it. It also mentions consumption of query allocation and wallet requirement. While it doesn't explicitly state when not to use it or list alternatives, the context is clear enough for a user to understand the prerequisite.

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 full burden. It discloses that the tool returns a 'block-diagonal strategy with calibrated risk prediction', requires the X-Wallet header for authentication, and offers a free trial of 5 queries. It also describes an optional feature with a condition (variance ratio > 20). However, it does not mention rate limits, error handling, or behavior when the free trial ends.

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 (about 5 sentences) and front-loads the purpose. Every sentence adds value, but it could be more structured (e.g., separate sections for input, output, optional). There is no waste, but some information is dense.

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

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

Given no output schema, the description offers a high-level idea of the return ('block-diagonal strategy with calibrated risk prediction') but not detailed format or error handling. Many parameters are left unexplained. The tool's complexity is moderate, but the description is adequate only for basic 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?

The schema has 0% description coverage, so the description must compensate. It explains coupling types and mention report_sign_detectability, but 11 out of 13 parameters (e.g., task_type, cost_model, model_class, compute_budget, etc.) are not elaborated. The description does not sufficiently clarify the meaning or usage of these 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 what the tool does: it 'Map[s] the factorization terrain' of a model, takes coupling structure as input, and returns a block-diagonal strategy with risk prediction. The verb 'Map' and resource 'factorization terrain' are specific, and the description distinguishes from siblings by focusing on factorization guidance.

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 on when to use precision matrix vs. covariance matrix ('precision matrix preferred for n>2; covariance matrix recommended if sign or CC information is needed') and mentions the optional parameter report_sign_detectability and the requirement for X-Wallet header. It does not explicitly exclude when not to use or list alternatives, but the context is clear.

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

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

Lacking annotations, the description carries the burden and adds crucial lifecycle context (Specification pending/v1.1 target), but omits other behavioral traits like side effects, idempotency, 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?

Extremely concise with zero fluff: first clause states purpose, second clause states implementation status—every word 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?

Adequate for a stub tool (acknowledges pending status), but lacks return value documentation and usage context given the analytical complexity implied by the domain.

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-parameter schema establishes baseline 4; description appropriately provides no parameter details since none exist.

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

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

States specific analytical purpose (detect coupling regime changes in time series via windowed IC) and distinguishes from siblings like synergy_detect, though the 'Specification pending' caveat introduces minor ambiguity about current capabilities.

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?

Provides no guidance on when to select this tool versus alternatives (e.g., factorguide_diagnose or factorguide_synergy_detect) or prerequisites for 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?

Discloses critical behavioral traits absent from annotations: zero computation cost, no query allocation consumption, and feedback loop effect ('future predictions improve').

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 tightly crafted sentences front-loaded with purpose; every clause delivers value regarding workflow position, parameters, or resource costs.

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?

Adequately covers domain-specific workflow (prediction loop completion) and required inputs given no output schema exists; minor gap on optional performance metrics.

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, partially compensates by explaining ess_ratio, psis_khat, and log_lik_gap as inference diagnostics, but omits n_replications, runtime_seconds, and actual_mse_ratio.

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

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

Specific verbs ('complete', 'report') and resource ('inference diagnostics') clearly identify this as the post-prediction feedback tool, distinguishing it from diagnostic/analysis 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?

Provides clear temporal context ('after running the approach') and cost constraints ('zero computation', 'no query allocation'), though lacks explicit '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?

Clarifies workflow timing (post-transfer submission) and protocol variations (x402 vs MPP) despite no annotations; lacks details on submission outcomes.

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

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

Two sentences, front-loaded with purpose followed by protocol guidance; 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?

Complete for low complexity (2 params, no output schema); covers purpose, timing, and protocol distinctions adequately.

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?

References parameters in x402 context, but schema coverage is 100% with clear descriptions, meeting baseline expectations without significant additional semantics.

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

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

Specific verb (submit) + resource (payment proof) clearly stated; distinctly different from diagnostic/explanatory 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?

Explicitly distinguishes when to use (x402 payments with tx_hash/chain) vs when not to use (MPP with in-band auth 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?

Discloses client-side computation pattern and v1.1 maturity status, but omits side effects, rate limits, or what 'spectral summary' entails given 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?

Three tight sentences with no fluff; purpose front-loaded, though 'specification pending' warning might ideally come earlier.

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?

Inadequate for the schema complexity (5 params, nested objects, 0% coverage); critical gaps around reference parameters and return values.

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

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

With 0% schema coverage, description only explains 'walsh_coefficients' conceptually while leaving 'ic_matrix_ref', 'n_variables', and nested order structures completely unexplained.

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

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

States specific action (detect synergistic structure) and method (Walsh-Hadamard spectral analysis), though doesn't clearly differentiate from sibling 'regime_detect'.

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?

Implies usage context (when agent has pre-computed Walsh coefficients) but lacks explicit when-not or comparison to diagnose/regime_detect alternatives.

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