AurelianFlo

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

Description contradicts annotations: 'Build a paid... memo' implies a write or side-effect (billing), but annotations declare readOnlyHint=true. Description does not reconcile this or explain billing behavior, misleading 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?

Two sentences, front-loaded with purpose and output, followed by alternative guidance. Zero filler, 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 10 parameters, existing output schema, and annotations, description covers purpose and usage well. Lacks explanation of 'paid' implications and does not detail required fields, but overall sufficient for an agent to invoke 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 description coverage is 100%, so baseline 3. Description does not add meaning beyond schema; it restates some parameters (addresses, output_format) but without new insights into usage or constraints.

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 'Build', specific resource 'paid enhanced due diligence memo', and distinguishing details like 'exact-match OFAC screening' and output options. Contrasts with sibling tools (wallet_ofac_batch, report_*_generate), establishing unique purpose.

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 ('for case handoff') and when to use alternatives (wallet_ofac_batch for screening, report_*_generate when payload exists), providing clear decision rules.

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, so the description's mention of forecasting and returning data aligns with read-only behavior. The description adds context about data sources and output format, without contradicting 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 description is a single dense sentence that efficiently conveys the core purpose and usage guidance. It is slightly long but still front-loaded 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 the tool's complexity (10 parameters, nested objects, output schema), the description provides an adequate overview of functionality and usage context. It does not detail output format but the output schema exists to cover that.

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 baseline is 3. The description does not add new parameter semantics beyond what the schema already provides; it focuses on the tool's overall purpose rather than individual 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 the tool forecasts future OFAC wallet exposure, using specific data sources (stored diffs, backfill, caller prior), and distinguishes it from sibling tool wallet_ofac_batch by noting it is for when current screening is not enough.

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 the tool ('Use this when current screening is not enough') and when not to, naming the alternative wallet_ofac_batch for current hit status only.

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, covering safety. The description does not contradict this but also does not add behavioral context beyond the input factors. No mention of side effects, required permissions, or output format details that aren't already in the schema or 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 with no redundancy. First defines purpose, second provides usage guidance. Every sentence earns its place; no filler or unnecessary 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's complexity (10 params, nested objects, output schema exists), the description is adequate. It covers purpose and usage guidelines clearly. While it could mention the output's nature (e.g., ranked list), the presence of an output schema likely handles that. Minor gap: no explanation of optimization methodology.

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 baseline is 3. The description does not elaborate on individual parameters (e.g., objective, iterations, tier_weights) beyond listing high-level factors like 'current OFAC exact matches'. No extra semantic value beyond the 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 starts with 'Optimize a compliance review queue using ...', clearly stating the verb (optimize) and resource (compliance review queue). It distinguishes from siblings by naming alternatives like compliance_exposure_forecast 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 provides when to use ('when review_items and review_budget are known') and when not to ('use compliance_exposure_forecast for probability-only analysis or compliance_edd_report for a case memo'). This gives clear usage boundaries and direct alternative tool names.

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 goes beyond readOnlyHint annotations by disclosing a critical behavioral limitation: 'AurelianFlo does not persist saved queues server-side', meaning the tool is essentially a stub. This transparency helps manage expectations, though the implication that the tool might list queues if persisted is slightly confusing.

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 sentences, but the first sentence is a single long clause that could be more readable. It is efficient and front-loaded with the main purpose, though slightly wordy.

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 tool's unusual nature (non-persistent queues), the description adequately covers the essential behavioral caveat. It explains why calling the tool may be pointless, which is necessary completeness.

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 baseline is 3. The description adds no extra meaning beyond the schema: 'limit' and 'case_reference' are described similarly. No additional parameter context is provided.

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 frames the tool as a utility for a specific niche question ('whether AurelianFlo can list prior compliance_queue_optimize results'), which is confusing and narrow. The name 'queue_saved_list' suggests listing saved queues, but the description calls it a 'status utility', creating purpose ambiguity.

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

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

The description explicitly states when not to use it (rerun compliance_queue_optimize instead) and identifies the alternative tool by name. However, it does not clarify general use cases beyond the specific query about AurelianFlo.

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 the key behavioral detail that it does not persist hosted files, going beyond the readOnlyHint annotation. 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, each serving a distinct purpose: first defines functionality and nature, second gives usage guidance. 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?

The description covers purpose, usage, and behavioral transparency. Given high schema coverage and presence of output schema, the description is sufficient for selecting the tool but could briefly note required parameters are minimum.

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 83% schema description coverage, the schema already documents most parameters. The description adds no additional parameter-level details beyond listing the content types (report_meta, tables, metrics, summary). 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 returns an inline DOCX artifact from supplied content and labels it a read-only renderer. It explicitly distinguishes from siblings like report_pdf_generate 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 provides explicit when-to-use (structured report payload exists) and when-not-to-use (use report_pdf_generate for fixed-layout or compliance_edd_report to build memo first). It names specific sibling tools.

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 read-only behavior and that it does not persist files, which aligns with readOnlyHint annotation. Adds context about returning inline PDF artifact beyond 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 purpose, immediately followed by usage guidelines. No unnecessary 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 output schema exists, description covers key aspects: what it returns (inline PDF), its non-persistent nature, and when to use. Provides sufficient context for agent decision.

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 baseline is 3. Description mentions parameters (report_meta, tables, metrics, summary) but adds little beyond existing schema details.

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 explicitly states it returns an inline PDF artifact and is a read-only renderer. It distinguishes from siblings report_docx_generate and compliance_edd_report by specifying when to use each.

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?

Clearly states when to use: only when a structured report payload already exists. Provides explicit alternatives for editable Word output and building the memo first.

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. Description adds critical behavior: reports are returned as inline contentBase64, and are not persisted server-side. No contradiction 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: first defines purpose, second adds key behavioral trait. No wasted words, front-loaded with primary function.

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?

With output schema and annotations present, description covers core purpose and a critical behavioral detail (no server persistence). Minor lack: 'retrieval status' phrasing could be clearer about whether it returns status or the report content itself, but the inline artifact mention confirms content return.

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

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

Schema coverage is 100%, so baseline is 3. Description repeats the optional nature of parameters but does not add deeper meaning or examples beyond the 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?

Description clearly states the tool retrieves previously generated reports, with verb 'retrieve' and resource 'past report'. Distinguishes from sibling generation and compliance tools by focusing on saved report retrieval, and provides specific implementation detail about AurelianFlo returning artifacts inline.

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 'for agents asking about previously generated reports', which is a clear use case. However, it does not explicitly state when not to use or list alternatives, though the sibling tools context implies generation 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?

Annotations already provide readOnlyHint: true. The description adds that it is 'free' and a 'connection check,' implying no side effects. No contradictions. It adds useful context beyond 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 with no wasted words. The first sentence front-loads the core purpose ('Free first-call capability and connection check'), making it immediately scannable.

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 zero-parameter tool with an output schema, the description fully explains its purpose, usage order, and what information it returns. It 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?

The input schema has zero parameters, so baseline is 4. No additional parameter information is needed.

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 it is a 'free first-call capability and connection check' and specifies what it inspects: 'OFAC screening workflows, access modes, and x402 payment requirements.' This provides a specific verb and resource, and it is distinct from sibling tools which are compliance and wallet-related.

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 it before paid tools,' giving clear when-to-use guidance. It also mentions the inspection subjects, helping the agent decide if this tool is relevant.

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 disclosing the return format ('per-wallet results plus a batch-level proceed-or-pause decision'). No contradiction. Could mention rate limits or authentication but still strong.

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, each dense with information. First sentence covers purpose, scope, and outputs. Second sentence provides sibling comparisons. No superfluous text.

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 2 parameters with full schema coverage and an output schema (present but not shown), the description provides all necessary context: what it does, when to use it, what it returns, and how it differs from siblings.

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 parameter descriptions. The description adds context for the 'asset' parameter (optional, example tickers) but does not significantly enhance understanding beyond the schema. 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 verb ('Screen'), resource ('crypto wallet addresses'), scope ('1-100'), and context ('before payout, onboarding, or treasury movement'). It explicitly differentiates from sibling tools by naming 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?

Provides explicit guidance on when to use this tool (batch screening for multiple addresses) and when to use alternatives (wallet_ofac_screen for single address, compliance_edd_report for formal memo). This empowers correct tool 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?

Annotations already provide readOnlyHint=true. The description adds that the report is 'paid' and can return inline PDF/DOCX artifacts, which are important behavioral traits beyond the annotation. No contradiction found.

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 sentences, front-loads the core action and output, and includes alternative tool references without extraneous 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 the presence of an output schema, annotations, and full parameter coverage, the description covers the purpose, alternatives, paid nature, and output format 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?

Schema coverage is 100%, so baseline is 3. The description does not add additional meaning to parameters 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?

The description clearly states the tool's purpose: run a paid OFAC screening report for one crypto wallet and return structured JSON or artifact. It specifies the resource (crypto wallet) and action (run report), and distinguishes itself from sibling tools wallet_ofac_screen and wallet_ofac_batch.

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 provides when-to-use and when-not-to-use: 'Use wallet_ofac_screen for a quick single-address status check, or wallet_ofac_batch for multiple addresses.' This guides the agent to select the correct tool.

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 safety profile is clear. Description adds behavioral context about return values (exact hits, sanctioned entity metadata, asset coverage, manual-review signal) without contradicting annotations. No additional behavioral traits beyond what is already conveyed.

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 wasted words. First sentence front-loads the core functionality and outputs; second sentence provides usage guidance. Ideal conciseness.

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?

With an output schema present and comprehensive annotations, the description is complete: it explains the purpose, outputs, and usage context. No gaps remain given the tool's 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?

Schema coverage is 100%, so the schema fully documents both parameters. The description restates the purpose but does not add significant meaning beyond what the schema already provides. 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?

Clearly states the verb 'screen' and the resource 'crypto wallet address against OFAC SDN digital currency designations'. Lists specific outputs (exact hits, metadata, etc.) and explicitly distinguishes from sibling tools (wallet_ofac_report, wallet_ofac_batch).

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 this tool: 'one-off status checks'. Directly names alternative tools for different use cases: wallet_ofac_report for PDF/DOCX output and wallet_ofac_batch for multiple addresses.

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