High-frequency OFAC wallet screening and recurring signed x402 checks for autonomous agents.
Scored across 13 tools
The five _quote tools (quote, machine_quote, batch_quote, counterparty_quote, compliance_monitor_quote) all perform the same preflight function, and catalog overlaps with verification_products as discovery surfaces. The descriptions are detailed enough to tell them apart by product line, but an agent could easily confuse quote with machine_quote or pick the wrong catalog tool.
The naming follows clear family patterns: product_quote, _status, and product_products suffixes are used consistently, with no mixing of casing conventions. Minor deviations exist (bare catalog vs. verification_products, bare coverage vs. coverage_status), but the overall pattern is predictable and readable.
At 13 tools, the count is within the well-scoped range for a commercial evidence marketplace. However, the five quote variants and two catalog tools carry some redundancy, suggesting a few could be consolidated without losing functionality.
The surface covers the domain well: discovery, catalogs, product-specific quotes, coverage/status checks, source listings, and sales telemetry. The deliberate absence of a purchase tool is consistent with the x402 model where paid retrieval happens via returned URLs, so agents can work around this by following the paid endpoints.
Free availability preflight for 2-10 quick checks. Individual item outcomes are withheld until payment.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral disclosure. It does reveal a key trait: 'Individual item outcomes are withheld until payment,' indicating that only a preliminary availability answer is given per item, with detailed results gated behind payment. It also mentions the batch size limit. However, it doesn't state what exactly is returned (e.g., boolean, summary), whether the operation is read-only, or any rate limits or auth requirements. This is partial but useful context.
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 extremely concise—two short sentences that immediately state the essential purpose and the key behavioral constraint. No redundant words, no fluff, and the most critical information (free, batch size, outcome withholding) is front-loaded. It earns a perfect score for 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?
The tool has a complex nested parameter structure with six fields, no parameter descriptions, no annotations, and no output schema. The description is far too sparse to enable correct invocation: it doesn't clarify what each item's fields mean, how to specify date ranges ('from'/'to'), what 'source' values signify, or what the response format looks like. While it hints at a preflight concept, an agent would struggle to build a valid request. The lack of schema documentation and annotations puts the full burden on the description, which it fails to meet.
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 a nested 'items' array with required fields (source, from, to) and optional fields (term, entity, event_type), but schema description coverage is 0%, meaning no field-level descriptions exist. The description adds nothing about these parameters—only that there are 2-10 'quick checks'. It fails to explain what each field represents, how to construct an item, or how sources like 'federal-register' or 'ofac' relate to the availability check. The agent has no guidance beyond the raw enum/type definitions.
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 identifies a batch availability preflight service with a specific verb ('preflight') and resource ('availability'), and specifies a 2-10 item range. It distinguishes itself from single-item quote tools by the word 'batch' and '2-10', though it doesn't explicitly name a sibling alternative. The purpose is understandable but lacks specifics on what 'availability' means or what data sources are involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick, free preliminary checks ('Free availability preflight'), suggesting it's for initial screening before committing to paid detailed quotes. However, it doesn't explicitly state when not to use it, what alternatives exist (e.g., 'quote' for detailed results, 'counterparty_quote' for counterparty-specific), or any conditions that would make another tool more appropriate. Guidance is vague and left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List free preflight and paid Federal Register evidence products
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. The verb 'List' conveys a read-only retrieval operation, but the description does not disclose output format, pagination, or whether any costs/limits apply to the paid products. Basic behavior is clear, details are not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that states the operation and scope without wasted words. The key qualifiers ('free preflight and paid') are included.
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 an empty-parameter list tool, the description is largely complete: it names the subject and scope. However, with no output schema, it would be stronger if it mentioned the shape of the returned product list or any pagination.
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 and 100% schema coverage, so there are no parameter semantics to document. The description adds useful context by defining what the catalog contains, meeting the baseline for a no-parameter tool.
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 the specific verb 'List' with a precise resource: free preflight and paid Federal Register evidence products. This distinguishes the catalog tool from sibling quote/status tools, which serve different purposes.
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 'List ... products' implies the tool is for browsing available evidence products, but it does not explicitly state when to use it over alternatives or mention any exclusions. Usage context is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free preflight for the recurring ARAKEL Compliance Monitor. Returns readiness, $0.05 price, cadence, and paid URL while withholding the signed monitoring result.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| to | No | ||
| from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses that the tool returns preliminary information and withholds the signed monitoring result, which is a meaningful behavioral trait. However, it does not explicitly state whether the call is read-only, idempotent, or has side effects; for a quote tool this is often implied but not stated. The transparency is partial.
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, information-dense sentence that front-loads the core purpose ('Free preflight...') and then lists the key outputs. It is concise with no filler, though it could be structured with more explicit separation of inputs and outputs. Still, it is appropriately sized.
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 absence of an output schema, the description does explain the return values, which is helpful. However, it omits any parameter guidance, and without usage guidelines or alternative routing, an agent would have difficulty calling the tool correctly. The tool has three parameters and no schema descriptions, so the description is incomplete for effective use.
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 0%, and the description does not explain any of the three parameters (q, to, from). The agent cannot infer what values to provide. The description adds no value beyond the raw schema, and with zero coverage it fails to compensate, making this dimension critically deficient.
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 a specific purpose: a free preflight for the recurring ARAKEL Compliance Monitor, and enumerates the return items (readiness, price, cadence, paid URL) plus what is withheld. It clearly identifies the resource and scope, though it does not explicitly contrast with the generic 'quote' sibling, so it does not fully achieve top marks for 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?
No guidance is given on when to use this tool versus the many sibling tools such as quote, counterparty_quote, or machine_quote. The description implies it is for compliance monitor quoting but does not state conditions for selection or alternatives, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free availability preflight for the signed multi-source counterparty dossier. Source results are withheld until payment.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| term | No | ||
| entity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully discloses that 'source results are withheld until payment,' which is a meaningful output limitation. However, it does not address authentication, side effects, or what happens after payment, leaving the behavioral picture incomplete.
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 only two sentences and wastes no words. It front-loads the core function and then adds the crucial withholding caveat, making it structurally efficient even though the wording is cryptic.
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 four undocumented parameters, no output schema, and no annotations, the description is not complete enough for reliable invocation. It leaves unclear what the preflight returns, how the date/entity parameters map to the dossier, and how this quote flow relates to the surrounding quote tool family.
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 0%, so the description should compensate by explaining entity, from, to, and term. It does not mention any of these parameters or their meanings, leaving the agent to guess what values to supply for a 'signed dossier' preflight.
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 identifies a specific function: a 'free availability preflight' for a 'signed multi-source counterparty dossier.' However, the terminology is jargon-heavy and does not clearly state what result the agent will receive (e.g., price quote, availability flag, or both), so the tool's exact purpose remains somewhat ambiguous.
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 no guidance on when to use this tool versus alternatives like batch_quote, quote, machine_quote, or coverage. It implies a pre-payment/preflight context ('free', 'withheld until payment') but never states an explicit condition or names a sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check observation coverage before buying a NOT_OBSERVED proof
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Check' implies a read-only operation, but the description does not explicitly state that there are no side effects, what data is examined, or what the response represents. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with the core action. Every word contributes to the purpose, and there is no fluff or redundant 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?
With no output schema and no annotations, the description must explain enough for correct invocation and interpretation. It does not describe what output to expect, what 'coverage' means in quantitative terms, or how to use the parameters. The sibling ambiguity with 'coverage_status' further reduces 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 description coverage is 0%, and the description does not explain the 'from' and 'to' parameters. The names suggest a range, but there is no mention of expected format (dates, timestamps, coordinates) or how they relate to observation coverage. The description fails to compensate for the schema gap.
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 a specific action ('Check observation coverage') and the context (before buying a NOT_OBSERVED proof). It is not a tautology of the name and implies a verification workflow. However, it does not explicitly differentiate from the sibling 'coverage_status', so some ambiguity remains.
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 a clear trigger: use this before purchasing a NOT_OBSERVED proof. This communicates when the tool is appropriate. It does not provide exclusions or mention alternative tools, but the stated use case is a practical guideline in itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect persistent autonomous observation continuity and source failures
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Inspect' signals a read-only operation and the description names the dimensions inspected (continuity and source failures), but it does not disclose output format, failure semantics, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant phrasing. It is front-loaded with the action verb, though the jargon-heavy phrase 'persistent autonomous observation continuity' could be clearer.
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, the description provides a reasonable starting point, but it omits any explanation of return values or how this status differs from sibling tools. Given no output schema and no annotations, a bit more context about expected results would make it more 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 tool has zero parameters and the schema description coverage is 100%, so the schema fully captures parameter semantics. The description adds no parameter-level meaning, but none 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 uses a specific verb ('Inspect') and names the subject matter: persistent autonomous observation continuity and source failures. It is clear about what the tool covers, though it does not explicitly differentiate itself from siblings like 'coverage' or 'discovery_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?
No guidance is provided about when to use this tool versus coverage_status's siblings. The description names no alternatives, conditions, or exclusions, leaving an agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return public autonomous discovery status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it only discloses that the status is 'public' (a weak hint that no special access is needed). It says nothing about what status values can appear, whether the data is live or cached, or how failures surface. For a status endpoint this is thin behavioral disclosure.
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?
Six words, no fluff, and the verb is front-loaded, so the prose is structurally disciplined. However, the description crosses from concise into under-specified, providing too little substance for a tool whose schema and annotations are both empty.
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?
This is a simple tool (0 params, no annotations, no output schema), so the description is the sole source for predicting the response, yet it never says what the returned status looks like, what its possible values are, or how 'autonomous discovery' relates to the sibling 'coverage_status'. An agent cannot forecast output shape or semantics.
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 tool has zero parameters (empty schema, 0 required), so there is nothing the description needs to document. The 'public' qualifier is consistent with a no-input read call. The zero-param baseline of 4 applies.
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 a verb ('Return') and a resource ('public autonomous discovery status'), so it is not a tautology, but the resource is vague: 'autonomous discovery' is undefined jargon, and next to the sibling 'coverage_status' an agent cannot tell what domain this status belongs to. It distinguishes from siblings only through the word 'discovery', which is never elaborated.
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 whatsoever. The description does not say when to call this tool versus the similarly named sibling 'coverage_status', nor whether 'public' means it should be preferred for unauthenticated checks. There is no when/when-not or alternative routing, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free x402 availability preflight. It reveals price and whether sellable evidence is available, but withholds the evidence result until payment.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| term | No | ||
| entity | No | ||
| source | Yes | ||
| product | No | ||
| event_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden. It explicitly states the tool is free, reveals price and sellable-evidence availability, and deliberately withholds the evidence result until payment, which is a meaningful behavioral trait. It does not mention side effects or errors, but 'preflight' implies a read-only check and the main behavior is disclosed.
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 entire description is one sentence that puts the core purpose first ('Free x402 availability preflight') and adds one essential caveat without padding. Every clause 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?
For a tool with seven parameters, no output schema, and no annotations, the description is too thin for an agent to know how to construct a valid request or interpret the response. It omits parameter explanations, return shape, and any payment/evidence-retrieval flow, so it is not complete enough.
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 0%, and the description makes no reference to any of the seven parameters (source, from, to, term, entity, product, event_type). The agent must infer parameter meanings from names and enums alone, so the description adds no semantic value for invocation.
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 identifies a concrete function: a free x402 availability preflight that reports price and sellable-evidence availability. It clearly separates the preflight from the paid evidence result, but it does not explicitly distinguish itself among the sibling quote tools (quote, batch_quote, counterparty_quote).
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 'Free x402 availability preflight' implies this should be called before paying to check price/availability, and 'withholds...until payment' implies a paid tool is needed for the evidence. However, there are no explicit when-to-use or when-not-to-use instructions and no mention of sibling alternatives, so selection guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return aggregate machine-sales funnel: requests, quotes, paywalls, paid requests, unique payers, and USDC revenue
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It says 'Return', which hints at a read-only operation, but it does not describe data freshness, time window, output format, permissions, or any side effects. For a tool without annotations, this is a minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb 'Return' and resource 'aggregate machine-sales funnel', then efficiently lists the six key metric categories. Every word contributes, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description clearly lists the metrics, it omits the return structure, time window, units for USDC revenue, and any caveats such as lack of filtering. With no output schema and no annotations, an agent lacks some information about the exact response shape and scope. It is adequate for a simple aggregate telemetry tool but leaves notable contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%. With no parameters, the description does not need to explain any inputs. The list of metrics is about return values, not parameter semantics. The no-parameter baseline of 4 applies.
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 has a specific verb 'Return' and a clear resource: the aggregate machine-sales funnel. It enumerates the exact metrics returned (requests, quotes, paywalls, paid requests, unique payers, USDC revenue), making it distinguishable from the quoting-focused sibling tools such as machine_quote and quote, which are about generating individual quotes rather than aggregate metrics.
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 aggregate nature of the tool implies it is used for high-l-level sales funnel metrics rather than for quoting tasks, but the description provides no explicit when-to-use or when-not-to-use guidance, and does not name any sibling tools or alternative conditions. Usage is only implied, not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ARAKEL official-source adapters and configuration status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'List' implies a read-only operation, but the description does not clarify what 'configuration status' actually contains, whether any prerequisites exist, or what kind of output to expect. Basic but not richly transparent.
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, focused sentence that leads with the action and immediately identifies the subject. There is no filler or redundant phrasing.
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 listing tool, the description is nearly sufficient. The main gap is that 'configuration status' is vague and the absence of an output schema means the agent gets no further details about the return shape, but the low complexity keeps this from being a major deficiency.
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 tool has zero parameters, so the schema already fully covers parameter semantics. The description adds context about the resource being listed, which is appropriate, and the baseline of 4 applies here.
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 ('List') and names a concrete resource ('ARAKEL official-source adapters and configuration status'), making the primary function clear. It does not explicitly differentiate from sibling tools, but the resource name is specific enough to avoid major 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?
No guidance is given about when to use this tool versus siblings such as coverage_status, discovery_status, or machine_quote. An agent must infer selection entirely from the tool name and minimal resource description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free availability preflight for legacy proof products. It returns price and whether sellable evidence is available, but withholds the evidence result until payment.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| term | Yes | ||
| product | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It meaningfully discloses that evidence results are withheld until payment, and that the call is free and returns price/availability. It does not mention authentication, rate limits, or side effects, but the 'preflight' framing and the explicit caveat provide solid transparency for an expected quote operation.
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 with no filler. It front-loads the tool category and scope, then states the return behavior and the key withholding caveat. Every word contributes useful 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?
Despite being concise, the description is not complete enough for reliable use: it lacks parameter semantics, usage alternatives, and any return structure or format. The absence of an output schema and annotations raises the burden on the description, which it only partially meets.
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 0%, and the description does not explain the meaning of term, from, to, or product. An agent cannot infer expected formats or domain semantics for these required parameters from either the schema or the description, making correct invocation essentially guesswork.
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 identifies a specific action ('availability preflight') and resource ('legacy proof products'), and states that it returns price and sellable-evidence availability. It is clear about the core function, though it does not explicitly differentiate itself from sibling quote tools like batch_quote, counterparty_quote, or machine_quote.
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 this is a preliminary check before payment, but gives no explicit guidance on when to choose this tool versus alternatives such as batch_quote, counterparty_quote, or machine_quote. There are no stated exclusions, prerequisites, or sibling-routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free funnel counters for the five ARAKEL x402/AP2 verification products: discovered, request, 402, payment header, verified and settled.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'free funnel counters' without explaining whether this is a read-only summary, whether counts are current or time-bounded, how they are aggregated, or whether any access restrictions or rate limits apply.
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 compact sentence that front-loads the core noun phrase 'free funnel counters.' However, the list contains six items after calling them 'five,' which is a structural clarity defect even though the text remains 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 zero-parameter counter with no output schema, the description provides the domain and the list of stages covered, which is minimally viable. It does not define what a 'funnel counter' returns, the output format, or any limitations, and the five-versus-six discrepancy leaves the stage list incomplete and confusing.
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 declares zero properties and schema description coverage is 100%, so there are no parameters to document. With zero parameters, the baseline is 4; the description does not need to add parameter-level meaning.
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 identifies the tool's resource ('funnel counters') and domain ('ARAKEL x402/AP2 verification products'), so the tool's purpose is understandable. However, it is phrased as a noun phrase rather than an explicit verb like 'returns' or 'lists,' and it says 'five' products while enumerating six items, adding slight 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?
There is no guidance about when to use this tool versus siblings such as verification_products or discovery_status. The description does not state usage conditions, prerequisites, or alternatives, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free discovery catalog for ARAKEL x402 Transaction Proof and AP2 Agent Trust products, including exact paid endpoints, free preflight endpoints, prices, request examples, result descriptions and evidence sources.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool is 'Free' and is a 'discovery catalog', which implies a read-only, non-destructive operation而立 the listed content types give some idea of the return value. It does not explicitly confirm there are no side effects, whether authentication is required, or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently packs the purpose, scoping, and included content into one compact string. Every phrase adds information and there is no filler, though the list at the end makes it slightly 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?
For a simple discovery tool with one optional enum parameter and no output schema, the description provides enough for an agent to understand what content to expect. It does not state default behavior when 'group' is omitted or detail the response structure, but these are minor gaps given the low complexity and lack of output 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?
The input schema has one optional enum parameter with no descriptions and 0% schema coverage. The description compensates by naming the two product lines—'ARAKEL x402 Transaction Proof' and 'AP2 Agent Trust'—which map directly to the enum values x402 and ap2. This adds meaningful semantics beyond the bare enum and helps an agent choose the group parameter.
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 identifies this as a free discovery catalog for ARAKEL x402 Transaction Proof and AP2 Agent Trust products and enumerates the contents (endpoints, prices, request examples, result descriptions, evidence sources). It distinguishes itself from the sibling 'catalog' tool by narrowing scope to verification products, though it lacks an explicit action verb.
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?
Usage is implied: an agent would use this when it needs to discover verification product details such as paid endpoints, preflight endpoints, and pricing. However, the description does not explicitly name sibling alternatives like 'catalog' or 'verification_product_funnel' or state when not to use it, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compliance_monitor_quoteverification_product_funnelverification_productsbatch_quotecounterparty_quotemachine_quote1 field changedInput schema / properties / product / enumPrevious value: -[
- "check",
- "proof",
- "change",
- "bundle"
-]New value: +[
+ "quick",
+ "check",
+ "proof",
+ "not_observed",
+ "change",
+ "bundle"
+]machine_quote1 field changedInput schema / properties / source / enumPrevious value: -[
- "federal-register",
- "sec",
- "ofac",
- "fda",
- "usaspending",
- "sam"
-]New value: +[
+ "federal-register",
+ "ofac",
+ "fda",
+ "usaspending"
+]catalogcoveragecoverage_statusdiscovery_statusmachine_quotemachine_sales_telemetrymachine_sourcesquoteOFAC sanctions screening for AI agents: screen names, wallets, entities against the SDN list.
Entity verification, sanctions screening, and trust scoring for AI agents via x402 micropayments.
Compliance MCP for AI agents: sanctions & KYT screening on 50+ chains, stablecoin-freeze, oracle.
KYC, KYB, AML, wallet screening, transaction monitoring, and fraud workflows for AI agents.
Add one secure layer between your agents and this server.
