factorguide

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

With no annotations, the description carries the transparency burden and it does disclose important behavioral constraints: it requires an X-Wallet header with EVM address and notes a 5-query free trial. It also hints at output content ('IC with risk prediction', 'variances for sign detectability'). It does not explicitly state read-only safety, but the diagnostic nature implies a non-mutating operation.

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

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

The description is brief and front-loaded with the core purpose. However, the sentence 'Include variances for sign detectability' is awkwardly phrased and could be misread as an instruction rather than a description of behavior, slightly detracting from clarity.

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 gives the purpose, authentication requirement, and a hint of outputs, but it lacks details on return structure (no output schema), omits any mention of sample_size, and does not clarify how it differs from sibling diagnostic tools. It is adequate for a simple quick diagnostic but leaves notable gaps for full autonomous 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?

The schema covers 50% of parameters with descriptions. The description adds some context for variance parameters ('variances for sign detectability') and clarifies that the tool deals with IC, but it does not explain sample_size or the exact role of coupling_value beyond what the schema says. Thus it partially compensates for the schema gaps but not fully.

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 'Quick single-pair diagnostic' that computes IC with risk prediction for both model classes, distinguishing it as a focused diagnostic for a single variable pair. It is more specific than a mere restatement, though it does not explicitly name sibling tools for comparison.

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

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

The phrase 'Quick single-pair diagnostic' implies its use for quick, focused pair analysis, and the 'first 5 queries are free trial' gives a usage restriction. However, it does not explicitly state when to prefer this over tools like factorguide_synergy_detect or factorguide_regime_detect, nor does it provide exclusions.

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 full burden of behavioral disclosure. It responsibly reveals the query cost (1 allocation), authentication requirement (X-Wallet header), and tier/trial restrictions, which are critical operational details beyond what the schema provides.

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-loaded with the primary purpose, followed by concise requirement and cost details. Every sentence adds essential information with no redundancy or filler.

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

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

Despite having no output schema or annotations, the description adequately covers purpose, prerequisites, cost, authentication, and access constraints. For a simple one-parameter tool, this provides sufficient context for an agent to correctly select and invoke it.

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 documents prediction_hash. The description reinforces that it comes from a previous navigate call, but does not add substantially new parameter-level detail beyond the schema's own 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?

The description uses a specific verb ('explains') with a clear object ('a previous navigate response') and adds concrete context about wave mechanics grounding. It clearly differentiates from sibling tools like factorguide_diagnose and factorguide_report_outcome.

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 the prerequisite (prediction_hash from a prior factorguide_navigate call), making the intended usage clear. It also provides context on when it's applicable (starter/professional tiers) and free trial limits, though it doesn't explicitly name alternative tools for 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 provided, the description discloses key behaviors: requires an EVM wallet header, free trial limit, and conditional behavior for report_sign_detectability (no additional cost when variance ratio > 20). It also implies a read-only analysis. Still, it omits potential side effects or data handling details, so it is not fully 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?

The description is well-organized: starts with purpose, then input/output, then optional flag, then auth and pricing. Every sentence adds value, but the opening metaphor 'Map the factorization terrain' is slightly vague and could be replaced with a more direct statement. Still, it is efficient and not redundant.

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 (13 parameters, no output schema, no annotations), the description is incomplete. It does not cover most parameters, output structure, error conditions, or what 'cost' means in detail. The provided information is a good start but leaves too many gaps for an agent to invoke it correctly.

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

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

Schema coverage is 0% and the description only explains 'coupling' (preferred input formats) and 'report_sign_detectability'. The other 11 parameters including sample_size, task_type, cost_model, model_class, and accuracy_target are left entirely unexplained. This does not adequately compensate for the lack of schema descriptions.

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 a specific action: 'Map the factorization terrain of your model' and explains the input (coupling structure) and output (block-diagonal strategy with calibrated risk prediction). It directly answers the question 'How should I factorize, and what will it cost me?' which distinguishes it from siblings like diagnose or explain.

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 input selection guidance: 'precision matrix preferred for n>2; covariance matrix recommended if sign or CC information is needed.' It also mentions prerequisites like X-Wallet header and trial limitations. However, it does not explicitly contrast with sibling tools, so it misses exclusionary 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 full burden of behavioral transparency. It reveals the method (windowed IC) but does not disclose expected inputs (the schema is empty), outputs, side effects, or limitations. The 'Specification pending' note further indicates incomplete behavioral detail.

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 sentence that front-loads the core purpose. It avoids unnecessary detail, and the placeholder note about specification is acceptable in context. 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?

For a tool with no parameters and no output schema, the description gives a clear core purpose. However, it is declared a 'Specification pending v1.1 target', indicating incompleteness, and lacks any usage context or return-value expectations. It is minimally 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?

The input schema has zero parameters, so the baseline for parameter semantics is 4 per the rubric. The description adds no parameter information, but none is needed given the empty schema.

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

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

The description clearly states a specific action (detect) and resource (coupling regime changes in time series) with a methodological detail (windowed IC). This distinguishes it from siblings like factorguide_synergy_detect by focusing on regime changes rather than synergy.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, preconditions, or comparisons with sibling tools, leaving the agent to infer usage from the name alone.

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 full burden of behavioral disclosure. It adds valuable context by stating that the tool requires 'Zero additional computation required' and 'Does not consume a query allocation', which are important cost-related side effects. The phrase 'so future predictions improve' also indicates a learning/feedback effect, further increasing 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 exceptionally concise: three sentences with no redundant words. It front-loads the primary purpose ('Complete the prediction loop — report inference diagnostics'), then provides supporting details efficiently. Every sentence adds value, and there is no repetition of schema 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?

Given the tool has 8 parameters, no output schema, and no annotations, the description should provide more guidance to ensure successful invocation. It explains the main diagnostic metrics but omits crucial context for the required prediction_hash field and other optional fields. The phrase 'Complete the prediction loop' is somewhat abstract and does not specify the required identifier or the expected response, leaving an agent under-equipped for accurate 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?

The schema has 0% coverage in the description, but the description explicitly names three key parameters: ESS ratio, PSIS-khat, and log-likelihood gap, which map directly to the schema fields ess_ratio, psis_khat, and log_lik_gap. It also implies approach_taken via 'the approach FactorGuide recommended'. However, other parameters like prediction_hash, n_replications, runtime_seconds, and actual_mse_ratio are not explained, leaving gaps for an agent trying to fill them correctly.

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: reporting inference diagnostics after running FactorGuide's recommended approach. It specifies the resource ('inference diagnostics'), the action ('report'), and the outcome ('future predictions improve'). This distinguishes it from sibling tools like factorguide_diagnose or factorguide_explain, which are likely for other stages of the workflow.

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 a clear when-to-use condition: 'After running the approach FactorGuide recommended'. It also notes that the tool 'Does not consume a query allocation', implying it is low-cost. However, it does not explicitly state when not to use this tool or name alternatives, so it falls short of a perfect 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?

With no annotations, the description must carry the full burden. It adds useful protocol-specific behavior (x402 requires params, MPP does not), but does not disclose side effects, idempotency, permissions, or response behavior. For a mutation-type tool, this leaves notable 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?

Two sentences with no redundancy. The main purpose is front-loaded, and the protocol-specific guidance is concise and 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?

For a simple 2-parameter tool with no output schema, the description adequately covers purpose, protocol variants, and parameter applicability. It does omit return-value details, but the simplicity of the tool and the clarity of the protocol distinction make it reasonably 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 baseline is 3. The description adds meaningful conditionality by clarifying that tx_hash and chain are for x402 only, and for MPP they should be omitted. This goes beyond what the schema alone explains.

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 verb ('Submit'), resource ('payment proof to a FactorGuide wallet address'), and scope ('after sending stablecoins'). It also distinguishes between x402 and MPP flows, making it unambiguous and distinct from the sibling diagnostic 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?

It explicitly tells when to use the tool ('after sending stablecoins'), and gives a clear exclusion for MPP ('use in-band Authorization header instead — no separate submission needed'), which is an explicit alternative path. This provides 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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions that the agent performs the transform locally and sends only a spectral summary, which is partially informative, but it does not disclose side effects, permissions, rate limits, or output behavior. The 'Specification pending' statement is a maturity warning, not a behavioral trait. Overall, the description gives minimal operational 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 concise, consisting of two sentences. It front-loads the primary purpose, then adds a usage note, and finally a specification status. Every sentence contributes meaningful information without redundancy. It is well-structured for quick scanning.

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?

This tool has five parameters, nested objects, no annotations, and no output schema, making it moderately complex. The description provides only the tool's purpose and a processing note, but lacks parameter details, expected outputs, error conditions, or safety information. The 'Specification pending' note further indicates incompleteness, leaving the description inadequate for reliable 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 description coverage is 0%, so the description must compensate for explaining the five parameters, but it does not. It only mentions 'pre-computed Walsh coefficients,' which maps to the walsh_coefficients parameter, but leaves n_samples, n_variables, ic_matrix_ref, and transform_method unexplained. Given the complexity of the nested walsh_coefficients object, this lack of parameter semantics is a significant gap.

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

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

The description clearly states the tool's function: 'Detect hidden synergistic structure via Walsh-Hadamard spectral analysis.' This specifies a distinct verb and resource, differentiating it from sibling tools like factorguide_diagnose and factorguide_regime_detect. The mention of accepting pre-computed Walsh coefficients further clarifies 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?

The description implies usage when pre-computed Walsh coefficients are available and notes that the agent should perform the transform locally, providing some context. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use guidance. There is no reference to sibling tools or conditional selection criteria.

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