AurelianFlo

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

Annotations declare readOnlyHint=true, implying no state change, but the description says 'Build a paid enhanced due diligence memo,' which suggests a generative/write operation. This contradiction undermines transparency. No additional behavioral detail (e.g., side effects, auth needs) is provided beyond the conflicting hint.

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; first sentence conveys action, resource, and output; second sentence provides usage guidance. No redundant words.

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 complexity (10 params, 3 required) and presence of output schema, the description covers purpose, usage, and output format. It does not explain prerequisites or process flow, but remains sufficient for an agent to decide 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 description adds limited value beyond parameter names/types. However, it does mention 'exact-match OFAC screening' and 'sanctions evidence' which contextualize the addresses parameter. 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?

Description clearly states the verb 'Build', the resource 'paid enhanced due diligence memo for a wallet set', and the output 'structured JSON or inline PDF/DOCX artifact'. It also distinguishes from siblings by listing alternatives.

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 this for case handoff') and when not to, giving specific alternative tools: 'wallet_ofac_batch for screening-only results' and 'report_pdf_generate/report_docx_generate only when the report payload already exists'.

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. Description adds context about data sources (OFAC snapshot diffs, backfill, explicit priors) and output structure (baseline, risk, report), which is useful beyond the annotation.

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 cover purpose, behavior, and usage guidance. 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?

Given the complexity (10 params, output schema), description covers key output types and usage. Could elaborate on data source terms, but domain knowledge is assumed. Adequate overall.

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 thorough descriptions for all parameters. The description adds minimal parameter-specific meaning, only hinting at metadata-weighted risk. 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 states it forecasts future OFAC wallet exposure, using specific verbs and resources, and distinguishes from sibling tool wallet_ofac_batch by noting its focus on current hit 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 when to use this tool ('when current screening is not enough') and when not (for current hits, use wallet_ofac_batch). Also mentions different data source strategies.

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 aligns with the readOnlyHint annotation; no contradiction. It adds context about computation inputs but doesn't detail output or side effects. With annotations covering safety, this is acceptable.

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, no filler. The first sentence states purpose and inputs, the second gives usage guidance. Front-loaded 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 a complex input schema (10 params, nested objects), output schema exists, and annotations are present, the description is largely sufficient. It could have explained what 'optimize' produces (e.g., a ranked list), but the output schema likely fills that gap.

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 each parameter has a description. The description's mention of factors like 'current OFAC exact matches' adds some high-level context but doesn't deepen understanding beyond the schema. 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: 'Optimize a compliance review queue' and lists the specific factors used. It also distinguishes from siblings by name-dropping alternative tools for different use cases.

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: 'Use this when review_items and review_budget are known; use compliance_exposure_forecast for probability-only analysis or compliance_edd_report for a case memo.' Clearly specifies when to use and when not, with named 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?

Description adds critical behavioral context beyond annotations: reveals that saved queues are not persisted server-side by AurelianFlo, meaning the tool may effectively return empty/no results. This is a key transparency disclosure not evident from readOnlyHint alone.

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 essential caveat. No redundant information. Highly 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 output schema exists (not shown, but noted in context), the description adequately covers purpose, usage context, and behavioral caveats. With only 2 parameters fully described in schema, no further details needed.

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 no additional semantic value beyond what the schema already provides for 'limit' and 'case_reference'.

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?

Clear verb+resource: 'list saved queue status'. The description specifies it's for agents asking about listing prior compliance_queue_optimize results, distinguishing it from sibling tools like compliance_queue_optimize that create queues. However, it doesn't explicitly differentiate from list-like siblings (e.g., report_saved_retrieve).

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 (agents asking if AurelianFlo can list prior results) and provides a clear alternative: rerun compliance_queue_optimize with original review_items. This guides the agent away from using this ineffectively.

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 adds behavioral context by stating 'this read-only renderer does not persist hosted files,' which complements the readOnlyHint=true annotation. It clarifies that the tool is safe and non-destructive without needing to infer from the annotation alone.

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 with no unnecessary words. First sentence states core functionality, second provides usage context and alternatives. 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?

Given the complexity (6 params, nested objects, output schema exists), the description covers purpose, guidelines, and behavioral traits well. It mentions the output is an 'inline DOCX artifact' but does not detail the output structure; however, the output schema likely provides that, so it's acceptable. Minor missing detail on what 'inline' means specifically, but overall 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 83%, so the schema already documents most parameter details. The description enumerates the key content parameters (report_meta, tables, metrics, summary) which groups them meaningfully, but does not add significant new semantics beyond what's 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 clearly states the action ('Return an inline DOCX artifact') and the required inputs ('report_meta, tables, metrics, and summary content'). It also distinguishes from siblings by naming report_pdf_generate and compliance_edd_report, so the agent knows exactly when to use this 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 second sentence provides explicit usage guidance: 'Use this only when a structured report payload already exists' and directs to alternatives for different scenarios (report_pdf_generate for fixed-layout, compliance_edd_report to build memo first). This is clear and 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?

Annotations declare readOnlyHint=true, and description adds 'this read-only renderer does not persist hosted files,' confirming no side effects. No contradictions. Description adds value beyond annotations by clarifying non-persistence.

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: first states action and key inputs, second gives usage guidance. No fluff, every sentence earns its place. 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?

For a tool with 6 parameters (2 required), high schema coverage, and output schema present, the description covers purpose, usage, behavioral traits, and alternatives. No gaps remain given available metadata.

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 most parameters already have explanations. Description groups inputs into categories (report_meta, tables, metrics, summary) which helps mapping but does not add deep semantic details 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?

Description clearly states the tool returns an inline PDF artifact from structured inputs, using specific verbs and resources. It distinguishes from siblings by naming report_docx_generate and compliance_edd_report, making 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?

Explicitly says 'Use this only when a structured report payload already exists' and provides alternatives: use report_docx_generate for Word or compliance_edd_report to build memo first. This gives 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?

Annotations already set readOnlyHint=true. The description adds valuable behavioral context: 'returns report artifacts inline as artifact.contentBase64' and 'does not persist hosted report files server-side', clarifying the output format and server-side 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 efficient sentences with no redundant information. The first sentence states the purpose, the second adds behavioral details, making it front-loaded and 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 the presence of an output schema and annotations, the description provides sufficient context about the tool's behavior and return format. It covers the key aspects for an agent to use 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?

Schema coverage is 100% with all three parameters described. The description does not add further semantic meaning beyond what the schema provides, 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 retrieves status of past saved reports, using specific verbs 'retrieve' and 'returns'. It distinguishes from sibling report tools by focusing on retrieval and mentioning that reports are not persisted server-side.

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 says 'for agents asking about previously generated reports', which implies the usage context. However, it does not explicitly state when not to use this tool or mention alternatives like queue_saved_list for listing saved reports.

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 adds value by noting it's free and a connection check. No additional behavioral details needed given the simple nature.

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, front-loaded sentence with no wasted words. Every part earns its place, clearly stating the tool's role and what it inspects.

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 existing output schema, the description sufficiently explains the tool's function as a connection and capability check. It mentions key inspection areas, making it complete for its simplicity.

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 schema coverage is 100%. The description adds no parameter-specific info, which meets the baseline of 3 for high 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 is a 'free first-call capability and connection check' for AurelianFlo, with specific purpose to inspect OFAC screening workflows, access modes, and x402 payment requirements. It distinguishes from sibling tools that focus on compliance reports and wallet operations.

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 to use it 'before paid tools' and explains it's for connection and capability inspection. While no when-not or alternatives are given, the context of a first-call check 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?

Annotations already signal readOnlyHint: true, and the description adds behavioral context: it returns per-wallet results plus a proceed-or-pause decision, and it is intended for batch screening. 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?

Two sentences, front-loaded with core action and context, then alternatives. No fluff; every sentence is informative.

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 (batch OFAC screening), the description covers the batch size, use cases, and distinguishing siblings. With output schema present, return values are documented elsewhere. 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%, so the description does not need to add much parameter info. It mentions the batch size (1-100) but does not add meaning beyond the schema's descriptions for 'asset' and 'addresses'. 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 'screen', the resource 'crypto wallet addresses against OFAC SDN digital currency designations', and the specific outcomes (per-wallet results plus batch-level decision). It also distinguishes itself from sibling tools like wallet_ofac_screen and compliance_edd_report.

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 when to use this tool (before payout, onboarding, treasury movement) and when to use alternatives ('Use this instead of wallet_ofac_screen for multiple addresses; use compliance_edd_report when a formal memo is needed'). This provides clear decision-making 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?

Annotations declare readOnlyHint=true, which is consistent. The description adds valuable context: the tool is 'paid' (cost implication) and returns 'structured JSON or an inline PDF/DOCX artifact' (output behavior). This exceeds annotation coverage without contradiction.

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 and output, then alternatives. Every sentence earns its place with no 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?

Given output schema exists (context signal), return values need not be detailed. The description mentions paid nature, output options, and sibling alternatives. Could mention prerequisites or cost details, but overall sufficient for a report tool with moderate 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% with each parameter described. The description adds context about output_format (structured vs artifact) but does not significantly elaborate on parameter meaning beyond the schema. 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 explicitly states 'Run a paid OFAC screening report for one crypto wallet', using a specific verb and resource. It distinguishes from sibling tools wallet_ofac_screen and wallet_ofac_batch by mentioning their use cases: quick single-address check and batch screening. This provides 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?

The description gives direct guidance on when to use this tool vs alternatives: 'Use wallet_ofac_screen for a quick single-address status check, or wallet_ofac_batch for multiple addresses.' This explicitly states use cases and exclusions, making it easy for an agent to decide.

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. The description adds value by detailing the return types (exact hits, metadata, coverage, manual-review signal) beyond the annotation, but does not cover other behavioral traits like rate limits or authentication requirements.

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 the core action, no redundant information. Every sentence serves a 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 presence of an output schema and the simplicity of the tool, the description covers purpose, usage, and return types adequately. However, it omits any discussion of prerequisites or potential errors.

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 does not add significant meaning beyond the schema; it mentions the address and asset filter implicitly but does not elaborate on parameter semantics further.

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 one crypto wallet address against OFAC SDN digital currency designations and returns specific results. It distinguishes from siblings by naming wallet_ofac_report and wallet_ofac_batch for different use cases.

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 'Use this for one-off status checks' and points to alternatives for PDF/DOCX output or multiple addresses, 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.