Chainflip Broker as a Service

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

With readOnlyHint=true in annotations, the description adds valuable return value semantics by specifying the response includes 'deposit detection, swap progress, and egress information.' This compensates for the missing output schema. It does not contradict annotations and provides concrete details about what 'status' encompasses.

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 efficient sentences with zero waste: first establishes purpose and required input, second details return contents. Information is front-loaded with no redundant or filler 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?

For a single-parameter read operation, the description is adequately complete. Annotations cover safety properties (read-only, non-destructive), and the description compensates for the missing output schema by listing return contents. Could improve by mentioning error handling for invalid IDs or polling frequency recommendations.

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 (swapId fully documented in schema referencing sibling tools) and only one parameter, the baseline applies. The description references 'its ID' acknowledging the parameter but adds no significant semantic 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?

The description clearly states the tool checks 'the status of a swap by its ID' with specific resource and parameter identification. It implicitly distinguishes from sibling quote/list/start tools by focusing on 'swap' status, though it lacks explicit differentiation text comparing it to start_swap or get_quotes.

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 through 'by its ID' and the parameter schema clarifies the ID comes from start_swap/start_dca_swap, suggesting a workflow sequence. However, the main description lacks explicit guidance on when to poll (e.g., 'Use after initiating a swap to monitor progress') or when not to use it versus 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?

Since annotations already establish readOnly/destructive hints, the description adds valuable behavioral context: it discloses the return content (exchange rates, fees, estimated output amounts) compensating for the missing output schema, and notes the optional authentication requirement ('API key is optional') beyond what the schema default implies.

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?

Four sentences efficiently structured: purpose definition, return value disclosure, usage context, and authentication note. Every sentence earns its place without redundancy. Front-loaded with the core action and well-paced information density.

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 4-parameter quote-fetching tool with full schema coverage and safety annotations, the description is complete. It compensates for the missing output schema by detailing what the response contains, explains the specific domain constraint (native units), and covers authentication requirements.

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 all parameters including examples. The description reinforces the 'native units' concept and mentions the optional API key, but does not add significant semantic meaning beyond what the structured schema provides. Baseline 3 is appropriate given the schema's completeness.

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 specific action (get swap quotes), resource (crypto assets), and unique constraint (using native/smallest unit amounts). It effectively distinguishes from sibling 'get_quotes' by emphasizing 'native units' in both the first sentence and the usage guideline.

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 when-to-use guidance ('Use this when you have amounts in native units') with concrete examples (satoshis, wei). This clearly signals the appropriate context for selection. However, it does not explicitly name the sibling alternative (get_quotes) for non-native amounts or state when NOT to use this 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 declare readOnlyHint/openWorldHint; description adds valuable context about what is returned ('exchange rates, fees, and estimated output amounts') and authentication requirements ('API key is optional'). Does not mention quote expiration or volatility despite openWorldHint=true.

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?

Three sentences with zero waste: purpose (sentence 1), return values (sentence 2), authentication note (sentence 3). Information is front-loaded and dense.

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 compensates by detailing return contents (rates, fees, amounts). Annotations cover safety profile. Minor gap: doesn't address quote validity periods or volatility implied by openWorldHint.

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 has 100% coverage with clear descriptions and examples (e.g., '1.5 for 1.5 BTC'). Description reinforces that apiKey is optional but doesn't add syntax constraints or format details beyond the schema. 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?

Specific verb 'Get' + resource 'swap quotes' + clear scope 'exchanging one crypto asset to another.' Distinguishes effectively from sibling 'start_swap' (execution vs. quoting) and 'list_assets' (pricing vs. catalog).

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?

Mentions 'API key is optional' which guides authentication usage. However, lacks explicit guidance on when to use this vs. sibling 'get_native_quotes' or that this should be called before 'start_swap'. Usage is implied but not 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 readOnly/idempotent/destructive hints, so description focuses on adding return value context. It successfully discloses the data structure returned (specific fields like minimum amounts, decimals, direction) which compensates for the missing output schema. 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?

Single sentence efficiently packs the action verb, resource scope ('all available'), and comprehensive field enumeration without redundancy. Information is front-loaded with critical details first.

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 zero parameters and no output schema, the description achieves completeness by detailing the returned data fields. For a simple list operation with strong annotations, this level of description is sufficient.

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 contains zero parameters, establishing a baseline of 4. Description correctly focuses on output semantics rather than inventing parameter documentation. No parameter compensation 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?

Description uses specific verb 'List' with clear resource 'swap assets' and enumerates returned details (ticker, network, direction, decimals, minimum amounts, USD prices). Clearly distinguishes from siblings like get_quotes and start_swap by focusing on asset metadata rather than pricing or execution.

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 referencing 'swap assets' which relates to the swap-related siblings, but provides no explicit when-to-use guidance (e.g., 'use before start_swap to identify valid tickers') or alternatives (e.g., distinction from get_quotes for pricing vs asset discovery).

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?

Adds critical behavioral details absent from annotations: returns 'deposit address' (crucial since no output schema exists) and explains the splitting mechanism. Notes API key optionality. Misses opportunity to clarify non-idempotent implications (creates new swap each call) or failure modes (minimum price triggers refund).

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?

Three sentences with zero waste. Front-loaded with core purpose (sentence 1), return value (sentence 2 - critical for no output schema), and optional auth (sentence 3). No filler or tautology.

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?

Compensates for missing output schema by stating return value (deposit address). Explains DCA mechanics adequately given schema completeness. Minor gap: omits operational flow (user must send funds to deposit address to trigger sub-swaps) and doesn't mention retry/expiration behavior implied by refundAddress parameter.

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, baseline is 3. Description adds marginal value by noting 'API key is optional' (redundant with schema but reinforces) and implicitly confirming DCA nature relates to 'numberOfChunks' parameter. No additional syntax guidance or parameter relationships explained.

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?

Excellent specificity: 'Start' (verb) + 'DCA cross-chain swap' (resource) + 'splits into multiple sub-swaps over time' (mechanism). Clearly distinguishes from sibling 'start_swap' via explicit DCA terminology and temporal splitting concept.

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 scenario (DCA strategy vs. single swap) but lacks explicit when-to-use guidance relative to 'start_swap'. No mention of prerequisites like fund availability or minimum amounts needed for effective DCA splitting.

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 establish write-operation and non-idempotent nature. The description adds crucial behavioral context not in annotations: it returns a deposit address requiring user action (sending funds). However, it omits that the process is asynchronous and requires subsequent status monitoring via 'check_status'.

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?

Three short sentences efficiently front-load the core action and return value. The API key mention is slightly redundant with schema but acceptable. No fluff, though the third sentence could be eliminated if schema coverage were trusted implicitly.

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 basic invocation but insufficient for a financial transaction tool. Given the existence of 'check_status' sibling and complex swap lifecycle, the description should mention that monitoring is required post-invocation. No output schema exists to compensate for this 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?

With 100% schema description coverage, the schema carries the full semantic load for all 6 parameters. The description merely reinforces that the API key is optional (already in schema) but adds no clarifying context for complex fields like 'minimumPrice' (ratio calculation) or the relationship between refundAddress and minimumPrice.

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?

States specific action ('Start') and resource ('cross-chain swap'). However, it fails to explicitly differentiate from sibling 'start_dca_swap' (e.g., by noting this is for single immediate swaps vs. recurring/averaging), which could confuse tool selection.

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 minimal guidance—only noting the API key is optional. Missing critical distinctions: when to use this vs. 'start_dca_swap', prerequisites (e.g., having source funds ready), or that 'get_quotes' should typically be called first to establish pricing.

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