AurelianFlo

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

Annotations already provide readOnlyHint=true, indicating the tool is safe. The description adds context about exact-match screening and output formats, but does not disclose behavioral details like rate limits, authentication requirements, or what happens with invalid addresses. With annotations covering the safety profile, the description provides adequate additional 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 a single sentence that packs key information (verb, resource, method, output options) efficiently. It is front-loaded with the main purpose. However, it is somewhat dense and could be slightly more structured with separate clauses.

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 complexity (10 parameters, 3 required, no output schema), the description provides a clear overview of inputs and outputs. It mentions the report components (sanctions summary, follow-up) and output formats. Missing details about error handling or response structure, but adequate for a generation 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 input schema already documents all parameters thoroughly. The description mentions key parameters (subject_name, addresses, output_format) but does not add significant meaning beyond what the schema provides. 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 generates an enhanced due diligence memo for a wallet set, specifying the method (exact-match OFAC screening, sanctions evidence summary) and output formats (JSON, PDF, DOCX). It distinguishes from sibling tools like wallet.ofac.screen (screening only) and report.docx.generate (general docx generation).

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 does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. While the output formats and screening details imply a specific use case, there is no direct comparison to siblings like wallet.ofac.batch or report.pdf.generate.

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?

Beyond the readOnlyHint annotation, the description discloses use of Monte Carlo simulation, data sources (stored diffs, backfill), and output composition (baseline, per-wallet risk, report). This adds significant behavioral context not captured in 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 single-sentence description is concise and front-loaded with the core purpose. However, it is slightly dense with technical jargon, making it less immediately accessible. Still efficient for its length.

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 complex tool with 10 parameters and output schema, the description covers input sources, simulation method, and output shape. It omits edge cases and error handling but is adequate given the presence of output schema and domain familiarity.

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 overarching context linking parameters (e.g., iterations, horizon_days, target) to the forecast process, enhancing understanding beyond individual parameter 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 the tool forecasts future OFAC wallet exposure for a wallet set, specifying input sources (stored diffs, backfill, priors) and output components (baseline, risk, report). This distinguishes it from siblings like wallet.ofac.report (current exposure) or simulation.montecarlo.report (general Monte Carlo).

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 is for forecasting OFAC exposure, but lacks explicit guidance on when to use it versus alternatives (e.g., wallet.ofac.screen for immediate screening). No when-not-to-use or alternative tool mentions.

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

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

Annotations already declare 'readOnlyHint: true', so the description does not need to reiterate that the tool is read-only. The description adds no additional behavioral context beyond what annotations provide, such as side effects, performance, or authorization needs. It adequately discloses the computational nature ('optimize') but does not go beyond the structured field.

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 is both concise and front-loaded with the primary action. It covers the essential elements without redundant words. Every part of the sentence (verb, resource, list of factors) contributes to understanding, making it efficient 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?

Given the tool's complexity (10 parameters, nested objects, multiple factors), the description is terse. While the output schema exists and parameters are fully documented, the description could provide more context about the optimization objective (e.g., 'minimize residual risk' versus 'maximize recall') or the meaning of 'review_budget'. It adequately summarizes the purpose but lacks depth for a comprehensive 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 input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the overall purpose of the parameters (e.g., 'using current OFAC exact matches, future exposure forecast probabilities, exposure value, relationship tier, recency, and optional current queue position metadata'), linking the factors explicitly to the optimization. This enhances understanding beyond individual parameter 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 the tool's purpose: 'Optimize a compliance review queue'. It lists relevant inputs (OFAC matches, exposure, tier, recency, queue position), distinguishing it from siblings like 'compliance.exposure.forecast' which forecasts exposure, and 'compliance.edd.report' which likely generates reports. The verb 'optimize' with a specific resource and list of parameters makes the purpose 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 provides no explicit guidance on when to use this tool versus alternatives like 'simulation.montecarlo.decision' (which might also optimize decisions) or when not to use it. There is no mention of prerequisites, limitations, or comparison to sibling tools. The usage context is only implied by the tool's name and description, which is insufficient for definitive selection.

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

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

The description says 'Generate a DOCX artifact' which implies creation, contradicting the annotation readOnlyHint: true. This is a serious inconsistency that could mislead the agent.

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?

Single sentence, 12 words, front-loaded with the action and resource. No fluff, but could benefit from a bit more context.

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, yet the description doesn't explain return values or behavior. For a complex tool with nested objects, this is insufficient.

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?

High schema coverage (83%) carries the burden. The description maps input concepts to schema fields but adds no new detail beyond what the schema already 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?

Clearly states the action (generate), the resource (DOCX artifact), and the input types (tables, metrics, summary). Distinguishes from sibling report.pdf.generate by specifying the format.

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 on when to use this tool versus alternatives like report.pdf.generate or compliance.edd.report. Lacks when-not or prerequisite information.

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

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

Annotations provide readOnlyHint=true, so the generative nature is consistent. Description adds 'artifact' but doesn't explain return behavior or persistence. With annotations covering safety, score is adequate.

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?

Single sentence that front-loads key action and inputs. Efficient with 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?

No output schema exists, so description should clarify what the generated artifact is (e.g., downloadable file, inline result). Missing this detail for a 6-parameter tool with nested objects.

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 83%, so parameters are well-documented structurally. Description adds no extra semantics beyond mapping to input types. 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 verb 'Generate' and resource 'PDF artifact', and lists the input types (structured report tables, metrics, summary content). This distinguishes it from sibling tool report.docx.generate which produces a different format.

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 on when to use this tool versus alternatives (e.g., report.docx.generate or other report tools). Lacks context about scenarios 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?

Annotations already provide readOnlyHint. The description adds behavioral context by indicating it returns information about capabilities, OFAC tools, access modes, and payment requirements, which is beyond what annotations offer. No contradictions.

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 is informative but slightly verbose. It is front-loaded with 'capability and connection check' and lists specifics efficiently, earning 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?

Given no parameters and no output schema, the description fully explains what the tool does—a capabilities overview including key features. It is sufficient for an agent to understand its purpose and when to 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?

The input schema has no parameters, so baseline is 4 per guidelines. The description does not need to add parameter info, but it describes the output content (capabilities, OFAC tools, etc.) which is relevant.

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 explicitly states it is a 'capability and connection check' for AurelianFlo, listing specific features (OFAC screening tools, access modes, payment requirements). This verb+resource clearly defines its purpose and distinguishes it from sibling tools which are specific actions.

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 for initial discovery of server capabilities, but lacks explicit guidance on when to use versus alternative tools. The context suggests it is a first step, but no direct exclusions or alternatives are mentioned.

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

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

The description fully discloses the read-only nature (consistent with readOnlyHint annotation) and specifies the return format: per-wallet results plus a batch-level proceed-or-pause decision. No contradictions with 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?

A single, front-loaded sentence conveying purpose, usage context, and output. No wasted words; 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?

For a batch screening tool with no output schema, the description adequately explains what is returned (per-wallet results and a batch decision). Given the low complexity and richness of sibling tools, the description is 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 coverage is 100% with both parameters described. The description does not elaborate on the optional 'asset' parameter but adds context for 'addresses' as batch screening against OFAC. Baseline 3 is appropriate as schema does the heavy lifting.

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 screens a batch of wallet addresses against OFAC SDN designations for specific use cases (payout, onboarding, treasury movement). It distinguishes from sibling tools like wallet.ofac.screen by emphasizing batch processing and returning a batch-level decision.

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 clear contexts for use ('before payout, onboarding, or treasury movement') but does not explicitly exclude single-address screening (handled by wallet.ofac.screen). The batch focus implies the intended use case, but a direct alternative mention would strengthen 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?

Annotations already indicate readOnlyHint=true, so the description's main behavioral addition is clarifying the return format (structured payload vs artifact). It does not contradict annotations, and the added detail on output options provides necessary transparency beyond the schema.

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, concise sentence that front-loads the main verb and clearly states the tool's function and output possibilities. There is no extraneous information, and every word contributes to understanding.

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 moderate complexity (3 parameters, no output schema, good annotations), the description adequately covers the core functionality and output options. It could mention error handling or the structure of the JSON payload, but the schema and annotations fill most 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 the baseline is 3. The description reiterates the 'address' and 'output_format' parameters but adds no new semantic meaning beyond what is already in the schema property 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 the tool's action ('Run an OFAC screening'), the resource ('crypto wallet address'), and the output possibilities ('structured sanctions-check payload' or 'PDF/DOCX artifact'). This distinguishes it from siblings like wallet.ofac.screen (likely a quick check) and wallet.ofac.batch (batch processing).

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 clear context on when to use this tool (when an OFAC screening report is needed) and specifies output format options. However, it does not explicitly mention when not to use it or suggest alternatives like wallet.ofac.screen for simple checks, but the context is sufficient for an AI agent to infer typical use cases.

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

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

Annotations already mark the tool as read-only, and the description adds detail on return types (exact hits, metadata, asset coverage, manual-review signal). This enhances transparency beyond annotations, though no extra behavioral traits (rate limits, auth needs) are mentioned.

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?

Single sentence, front-loaded with action and key output details. No unnecessary words 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 the lack of an output schema, the description adequately describes what is returned. For a simple screening tool with two parameters, the information is sufficient, though pagination or result size limits could be mentioned.

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% and the input schema already provides clear descriptions for both parameters. The tool description reinforces the asset filter but adds no new semantics 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 screens a wallet against OFAC SDN list and lists specific return fields. However, it does not explicitly differentiate from sibling tools like wallet.ofac.batch or wallet.ofac.report, which could cause confusion about when to use this single-screening version.

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 explicit guidance on when to use this tool versus alternatives (e.g., batch screening for multiple addresses). The description implies one-off screening but lacks contextual usage hints.

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