AurelianFlo

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

Annotations declare readOnlyHint=true; the description adds valuable behavioral context about the aggregation logic ('batch-level proceed-or-pause decision') and output format ('report-ready output') that annotations don't provide. It discloses the dual-level result structure (per-wallet + batch summary) without contradicting the read-only safety 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?

Single dense sentence front-loaded with the action verb. Efficiently packs multiple value propositions: screening target (OFAC SDN), granularity (per-wallet), aggregation logic (batch decision), and output utility (report-ready). Zero 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?

Without an output schema, the description compensates by detailing the return structure (per-wallet results, batch decision, report-ready format). It captures the compliance context (OFAC SDN) essential for this domain. Could slightly improve by mentioning the 100-address limit, though this is technically in the schema.

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 100% schema description coverage, the baseline is appropriately met. The description implicitly references the batch nature (aligning with the 'addresses' array) but does not add semantic details beyond what the schema already provides for the 'asset' filter or address format requirements.

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 specific verb 'Screen' with clear resource 'wallet addresses against OFAC SDN digital currency address designations' and distinguishes from siblings by emphasizing 'batch' processing and 'batch-level proceed-or-pause decision', clearly differentiating it from single-wallet screening 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?

While the description implies batch usage through terminology ('batch of wallet addresses', 'batch-level decision'), it lacks explicit guidance on when to choose this over sibling 'ofac_wallet_screen' (likely single-wallet) or the report generation tools. No explicit 'when-not-to-use' or prerequisites are stated.

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 only declare readOnlyHint=true; the description adds substantial behavioral context including 'exact-match' screening methodology (distinguishing from fuzzy matching), 'one-call' atomic output behavior, and specific memo contents (evidence summary, follow-up items) that annotations do not cover.

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?

Dense single sentence packs multiple distinguishing features (screening type, status labels, output formats) without waste. Front-loaded with core purpose and methodology; could improve readability with structural breaks but maintains efficiency.

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

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

Adequate for input parameters (100% schema coverage) and functional scope, but gaps remain: no output schema exists, and the description omits return value structure, error handling for OFAC hits, or rate limit considerations expected for compliance-critical tools.

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%, establishing baseline 3. The description adds minimal parameter semantics beyond the schema—referencing 'wallet set' (addresses) and output formats—but does not explain optional metadata fields (case_name, jurisdiction) or provide selection guidance for the output_format enum.

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 specific verb 'Generate' with resource 'enhanced due diligence memo' and clearly distinguishes from siblings by specifying 'exact-match OFAC screening,' 'workflow-safe status labels,' and 'evidence summary'—features absent from basic screening tools like ofac_wallet_screen.

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?

While lacking explicit 'when not to use' statements, the description provides clear contextual boundaries through 'enhanced due diligence memo' and specialized features (workflow-safe labels, required follow-up), signaling this is for formal compliance documentation versus quick screening or generic report generation.

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, indicating a safe operation. The description adds value by specifying the report structure (executive summary, headline metrics, workbook-ready tables), which helps predict output characteristics. However, it omits details about computation time, caching behavior, or error handling for invalid Monte Carlo workflows.

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, efficient sentence that front-loads the action verb 'Generate' and immediately specifies the output format. Every clause provides distinct information (purpose, source workflow, output components) with zero redundancy or filler content.

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

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

Given the tool's complexity (nested request objects, 7 analysis types) and lack of output schema, the description adequately compensates by describing the report's content structure. It could be improved by mentioning the return format (e.g., JSON/markdown) or noting that 'request' must be a valid simulation payload, but it covers the essential behavioral contract.

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 100% schema description coverage, the structured data adequately documents all four parameters. The description references 'Monte Carlo workflow' which loosely maps to the analysis_type enum values, but adds no additional parameter syntax, validation rules, or examples beyond what the schema already provides. Baseline 3 is appropriate 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 generates a structured decision report from Monte Carlo workflows and lists specific output components (executive summary, headline metrics, tables). However, it does not explicitly differentiate from the sibling tool 'monte_carlo_report', leaving ambiguity about which Monte Carlo reporting tool to select.

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 like 'monte_carlo_report' or the generic 'report_docx_generate'/'report_pdf_generate' tools. There are no prerequisites mentioned for the 'request' payload or 'analysis_type' selection criteria.

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 'paid call' cost model which is not present in annotations, and clarifies the dual return behavior (JSON vs documents). However, it does not explain the 'destructiveHint: true' annotation (what gets destroyed/modified or consumed) or mention rate limits, authentication requirements, or artifact 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?

The description is a single, tight sentence that front-loads the action verb ('Run'), specifies the domain, lists return variants, and notes the cost model. Every clause earns its place with zero redundancy or waste.

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 the high-level return behavior adequately despite no output schema. However, it is incomplete regarding the required 'request' parameter, which accepts arbitrary additionalProperties but lacks structural guidance in both schema and description. It also omits what the 'destructive' aspect entails.

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 100% schema description coverage, the baseline is 3. The description maps 'structured report payload' to json and 'premium PDF or DOCX' to those formats, adding semantic color to the output_format enum. However, it adds no guidance for the complex 'request' parameter (a required object with additionalProperties: true) regarding expected internal structure or valid fields.

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 'Run[s] a supported Monte Carlo workflow' and specifies the return types ('structured report payload', 'premium PDF or DOCX'). It distinguishes from OFAC siblings via the Monte Carlo domain. However, it fails to differentiate from the sibling 'monte_carlo_decision_report', leaving ambiguity about which Monte Carlo tool to use.

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 'in one paid call' provides implicit usage guidance regarding cost efficiency and atomicity, hinting this combines simulation and document generation. However, it lacks explicit 'when to use' guidance comparing it to 'monte_carlo_decision_report' or the standalone 'report_pdf_generate'/'report_docx_generate' 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?

The description adds valuable behavioral context beyond the annotations: it specifies 'exact-match' screening (distinguishing from fuzzy matching) and explicitly warns that this is a 'paid call', which aligns with and explains the destructiveHint annotation. It also clarifies that PDF/DOCX outputs are 'premium' artifacts.

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 front-loads the action verb and efficiently packs in the screening type, return format options, and cost structure. No words are wasted; every clause conveys essential selection criteria.

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 compensates by indicating the return types (structured payload vs. documents). It covers the tool's cost profile and screening methodology. It could be improved by describing what the screening report actually contains or the implications of an OFAC match.

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 100% schema description coverage, the schema already fully documents each parameter. The description adds aggregate context about the 'premium' nature of PDF/DOCX outputs and 'structured' nature of JSON, but does not elaborate on parameter syntax or validation rules 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 core action ('Run exact-match OFAC wallet screening') and the specific output formats (JSON payload or PDF/DOCX artifacts). However, it does not explicitly differentiate from the sibling tool 'ofac_wallet_screen', which has a very similar name and likely overlapping functionality.

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 mentions 'one paid call', indicating a cost barrier, but provides no explicit guidance on when to choose this tool versus 'ofac_wallet_screen' or the generic 'report_pdf_generate'/'report_docx_generate' siblings. No prerequisites or when-not-to-use conditions are stated.

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, but the description adds crucial behavioral context: it discloses that the tool performs exact matching (exact hits), returns sanctioned entity metadata, and includes a manual-review signal indicating potential fuzzy matches or borderline cases. This safety/review behavior is valuable context not present 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?

Single, information-dense sentence that is front-loaded with the action. Every clause earns its place: specifies the regulatory dataset (OFAC SDN), the domain (digital currency), and the specific return values. No waste or 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?

Despite lacking an output schema, the description comprehensively compensates by listing all return components: exact hits, sanctioned entity metadata, asset coverage, and manual-review signals. This is sufficient for an agent to understand the tool's complete behavior given the simple 2-parameter input structure.

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 100% schema description coverage, the schema already fully documents both parameters (address and asset). The description mentions 'asset coverage' in the return value context but does not add semantic meaning to the parameters beyond what the schema provides, meeting the baseline expectation.

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 ('Screen') and clearly identifies the resource (wallet address against OFAC SDN digital currency designations). It distinguishes from sibling report-generation tools by emphasizing specific screening outputs (exact hits, manual-review signal) rather than document 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?

While the description implies real-time compliance screening through terms like 'screen' and 'manual-review signal,' it lacks explicit guidance on when to use this tool versus the sibling 'ofac_wallet_report' or other alternatives. No when-not or prerequisites 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?

Annotations declare destructiveHint=true, indicating this operation destroys or overwrites data, but the description completely omits what gets destroyed (e.g., existing files, previous versions) or the implications of this destructiveness. No additional behavioral context (rate limits, auth, side effects) is provided.

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 structure is appropriately front-loaded with the action verb. It is brief (11 words), though 'premium' consumes space without adding functional 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 destructive tool with 6 parameters, nested objects, and no output schema, the description is insufficient. It lacks critical safety warnings, return value information, and explanation of the AurelianFlo model integration required for proper usage.

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 input schema carries the burden of parameter documentation. The description references the 'AurelianFlo report model' implying parameter structure, but does not elaborate on specific parameter semantics, syntax, or validation rules 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 verb (Generate) and resource (DOCX artifact), distinguishing it from the sibling report_pdf_generate by format. However, the terms 'premium' and 'AurelianFlo' add marketing fluff and jargon without clarifying functional scope.

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 prefer DOCX over the PDF alternative (report_pdf_generate), nor are prerequisites for the 'AurelianFlo report model' explained. The agent receives no selection criteria or exclusion contexts.

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 annotation 'destructiveHint: true' indicates a side-effect operation, which the description loosely aligns with via 'Generate.' However, the description fails to explain what specifically is destructive (e.g., file system writes, overwrites), where the artifact is stored, or how it is returned to the caller—critical gaps given there is no output 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, front-loaded sentence with no filler words. It efficiently communicates the core action and output format. However, given the tool's complexity and side effects, it may be excessively terse rather than appropriately 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?

For a tool with 6 parameters, nested object structures, destructive annotations, and no output schema, the description is insufficient. It fails to explain the artifact lifecycle, return value (e.g., binary data vs. URL), or persistence implications, leaving critical behavioral gaps the agent must guess.

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 input parameters are well-documented in the JSON schema itself. The description mentions the 'AurelianFlo report model' abstractly but does not map this concept to specific required parameters (report_meta, tables) or explain the structure expectations beyond what the schema already provides. Baseline score appropriate 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 uses a specific verb ('Generate') and identifies the output format ('PDF artifact') and data model ('AurelianFlo report model'). It implicitly distinguishes itself from the sibling 'report_docx_generate' by specifying PDF, though it doesn't explicitly clarify when to choose this over other report formats.

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 guidance on when to use this tool versus alternatives like 'report_docx_generate' or the various 'monte_carlo' report siblings. It lacks prerequisites (e.g., what constitutes a valid AurelianFlo model) and exclusion criteria.

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 adds critical behavioral context: the check is 'Free' (contrasting with paid sibling tools), and it specifically reveals x402 payment requirements and access mode availability (direct vs Smithery-hosted).

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, dense sentence front-loaded with the core action ('Free capability and connection check'). Every clause delivers value: cost (free), function (check), and specific return data (access modes, payment requirements). No waste.

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 read-only capability tool with no output schema, the description adequately covers what information is returned (access modes, payment requirements). It could specify return format, but lists content domains sufficiently for agent selection.

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?

Input schema has 0 parameters with 100% coverage. Per evaluation guidelines, 0 parameters establishes a baseline score of 4.

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 it performs a 'capability and connection check' for the AurelianFlo MCP, distinguishing it from sibling report-generation tools (monte_carlo_*, ofac_*, report_*_generate). It specifies the resource (AurelianFlo MCP) and scope (access modes, payment requirements).

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

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

Implies usage context by mentioning it reveals 'which tools require x402 payment,' suggesting it should be called before paid operations. However, it could be more explicit about calling this first for capability discovery versus jumping directly to sibling tools.

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