A
licenseB
qualityD
maintenanceProvides AI agents with research tools for AI agent ecosystem analysis, DeFi protocol analysis, and general market research.
3
29 npm
MIT
DropEngine x402 Agent Services
Server Details
AI Agent Utility Layer for agent safety, web monitoring, crypto research and tool discovery.
Ownership verified
- Status
- Healthy
- Uptime
- 99.6% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.5/5.0
Scored across 24 tools
Disambiguation4/5
Most tools target clearly distinct service domains (URL vs package vs wallet vs content vs transaction vs token security, whale vs arbitrage vs backtest intelligence), and the tiered invoice tools are cleanly separated by page count. The main friction is the large family of 'preflight/check' safety gates that overlap conceptually with the combined preflight_action orchestrator, though descriptions explicitly delineate roles.
Naming Consistency3/5
Names are uniformly snake_case, which aids readability, but the verb/noun ordering is mixed: verb_noun (check_url, route_tool, simulate_transaction) alongside noun_verb (action_lock, invoice_preflight, mcp_server_inspect) and pure noun phrases (agent_permission_vault, agent_spend_governor). The inconsistency is readable but not predictable.
Tool Count3/5
At 24 tools this is on the heavy side for a single server, though the breadth of the agent-safety and crypto-intelligence domain gives most tools a defensible place. The three invoice page-tier variants plus a quote selector push it toward feeling padded.
Completeness4/5
The surface covers a wide lifecycle: spend/permission/action governance, pre-action safety checks across URL, package, wallet, content, transaction, and token, plus intelligence, extraction, and meta-routing tools. Gaps are minor (e.g., no explicit payment/broadcast tool, but that appears intentional and clearly stated as out of scope).
Available Tools
24 toolsaction_lockAInspect
Action Lock ($0.001 USDC): Prevent duplicate side effects across agent retries, crashes, and concurrent workers. If an action has side effects and may be retried or executed concurrently, acquire before execution. Complete after confirmed success; release after confirmed failure. Use before payments, purchases, orders, emails, transactions, writes, and external tool actions. Avoid pure reads or equivalent provider-side idempotency. An expired lease can hide a completed external effect; reconcile first. Agent Action Gate asks whether an action should be performed; Action Lock asks whether it is already running or completed.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| state | Yes | |
| reason | Yes | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No | |
| decision | Yes | |
| action_id | Yes | |
| duplicate | Yes | |
| lease_token | Yes | |
| retry_after_ms | Yes | |
| retry_decision | Yes | |
| lease_expires_at | Yes | |
| dedupe_expires_at | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses the price ($0.001 USDC), the acquire/complete/release lifecycle, and a real failure mode ('An expired lease can hide a completed external effect; reconcile first'). It stops short of stating what happens on lock contention (fail vs. block), what acquire returns, or whether calls are idempotent, so it is not exhaustive for a no-annotation mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and lifecycle are front-loaded and earn their place, but a large trailing block covers product-family routing ('unclear capability/provider → use free /api/discover...') and workflow-recipe boilerplate plus a list of things Agent Action Gate does not do, most of which is not specific to action_lock. The useful content is diluted by shared catalog copy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description covers cost, lifecycle, concurrency rationale, and when to skip the tool. The main remaining gap is contention/error behavior on a failed acquire and how the lease_token flows between calls, which an agent must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema by explaining the operation ordering (acquire before execution, complete after confirmed success, release after confirmed failure) and the lease-expiry hazard, which the schema's per-branch const operations do not convey. It still says nothing about lease_ttl_seconds vs. dedupe_ttl_seconds or payload_hash semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Action Lock ... Prevent duplicate side effects across agent retries, crashes, and concurrent workers') and explicitly contrasts itself with the nearest sibling: 'Agent Action Gate asks whether an action should be performed; Action Lock asks whether it is already running or completed.' An agent can separate the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('If an action has side effects and may be retried or executed concurrently, acquire before execution'), lifecycle ordering (complete after confirmed success, release after confirmed failure), positive examples (payments, purchases, orders, emails, transactions, writes) and a when-not ('Avoid pure reads or equivalent provider-side idempotency'). It also names alternatives (Agent Action Gate, /api/discover, route_tool) with the conditions that select them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
agent_outcome_receiptAInspect
Create or verify a tamper-evident receipt of an agent-reported outcome. It proves DropEngine recorded a claim, not that the external event independently occurred. Do not send raw payloads or secrets. Price: $0.001 USDC per call.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No |
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers meaningful behavioral facts: tamper-evidence semantics, what the receipt does and does not attest, an explicit 'do not send raw payloads or secrets' constraint, and per-call cost ($0.001 USDC). It stops short of stating auth requirements or whether verify/status are read-only, but the safety-relevant disclosure is strong for an un-annotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first three sentences are tight and correctly front-loaded, but roughly two-thirds of the text is cross-tool routing boilerplate, including a sentence enumerating what Agent Action Gate does NOT do that has nothing to do with this tool. That bulk does not earn its place in this definition and dilutes the tool-specific content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the 100%-covered input schema handles parameters. The description covers purpose, trust semantics, security constraint, and price, leaving only auth/permission requirements and read-vs-write status for verify/status unstated. Adequate for an un-annotated mutation-or-read tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the oneOf branches fully constrain the issue/verify/status operations, so the schema does the heavy lifting. The description adds only the 'do not send raw payloads or secrets' constraint and implies the create/verify split; it does not explain the meaning of action_id, result_hash, external_reference, or scope beyond what the schema encodes. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Create or verify a tamper-evident receipt of an agent-reported outcome' — and adds a trust-boundary caveat ('proves DropEngine recorded a claim, not that the external event independently occurred') that helps distinguish it from verification-style siblings. It is clear, though it never explicitly names the siblings it differs from (verify_claim, action_lock).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The routing paragraph gives when-to-use guidance across the family ('known single capability → call the direct tool', 'multi-step objective → read the matching workflow recipe'), which implies this is a direct capability tool. However, none of it is tool-specific: it never says when to issue vs. verify vs. status, or when to prefer a receipt over verify_claim. Guidance is implied rather than stated for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
agent_permission_vaultBInspect
Check whether an owner-configured policy authorizes this capability for the verified caller. Permission check only; agents cannot grant themselves permission. This is authorization, not action safety. Price: $0.001 USDC per call.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | default | |
| context | No | ||
| resource | No | * | |
| operation | Yes | ||
| capability | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the crucial boundary that this is authorization not action safety and that agents cannot self-grant, plus the $0.001 USDC price and post-approval limits of the action gate. It doesn't explain the return payload, but an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated: it embeds an entire multi-tool routing guide and a list of unrelated exclusions (payment, reputation, simulation) that belong in other tools' definitions. The core purpose is buried behind the operational preamble instead of being front-loaded content-wise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Purpose, permissions boundary, and routing are covered, and an output schema exists so return values need no explanation. However the complete absence of parameter meaning documentation across 5 params is a real completeness gap for a callable contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never explains what 'operation', 'capability', 'resource', or 'scope' mean or how they relate. For a 5-parameter tool with a nested context object, the semantics are effectively undocumented, leaving the agent guessing at capability format and resource scoping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb (check) and resource (owner-configured policy authorization) for a verified caller. It distinguishes itself from the broader sibling preflight_action by clarifying it is a permission check, not an action safety assessment, though it doesn't compare to similarly-named siblings with the same precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent entry points' section provides an explicit routing map with conditions selecting each alternative (risky action → Agent Action Gate; unclear provider → /api/discover; comparison → route_tool), and it clearly says agents cannot grant themselves permission. The guidance is rich but somewhat sprawling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
agent_spend_governorAInspect
Enforce autonomous-agent budgets before paid actions. Call before spending; authorize, commit, release, or inspect an opaque reservation. Do not use for free operations or an equivalent trusted budget system. Price: $0.001 USDC per call.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses real behavioral facts: paid at $0.001 USDC per call, calls are "paid separately and are not bundle charged," and the reservation is opaque. It does not disclose auth/credential requirements, whether authorize is idempotent or expiring, what release does to a held amount, or failure semantics for an already-committed action_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Correctly front-loaded with purpose, cost and the do-not-use clause in the first three sentences. The remainder is a generic routing/boilerplate block shared across the tool family, and the final sentence enumerates what "Agent Action Gate" does not do — content about a different tool that dilutes focus rather than earning its place here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not owed. Given the multi-operation oneOf schema, the description covers purpose, cost, trigger and routing scope sufficiently for an agent to call it. The lifecycle semantics of the four operations remain implicit, which is the only shortfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported at 100%, so the baseline is 3. The description names the operation values (authorize, commit, release, inspect) which aligns with the schema's const/enum, but adds nothing about amount, action_id, scope, asset or vendor semantics, and the oneOf branch split (amount/action_id only valid on authorize) is left unexplained in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: "Enforce autonomous-agent budgets before paid actions," then names the four operations (authorize, commit, release, inspect). The routing paragraph distinguishes it from route_tool, Agent Action Gate and /api/discover. However, the closing exclusion list is written about "Agent Action Gate" rather than this tool, which muddles which tool the caveats apply to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ("Call before spending") and an explicit negative ("Do not use for free operations or an equivalent trusted budget system"). The entry-point routing table adds clear when-to-use branches per situation. No guidance on the ordering/sequencing of authorize vs commit vs release is given, which is the main gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_whale_activityAInspect
Paid Whale Intelligence ($0.02 USDC). Summarizes large public GeckoTerminal-indexed DEX trades for a token address on a supported chain. Large-trader labels are size-based heuristics, not verified whale identities; data is not chain-wide. Wallet mode uses Helius (Solana) or Etherscan API V2 (EVM) when configured, returning recent indexed transactions only; it does not claim complete balances or whale labels.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | No | |
| next | No | |
| tool | Yes | |
| error | No | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No | |
| timestamp | Yes |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the paid cost ($0.02 USDC), the data source (GeckoTerminal-indexed DEX trades), the wallet-mode backends (Helius for Solana, Etherscan API V2 for EVM), and candid limitations (labels are size heuristics, data is not chain-wide, no complete balances). It stops short of describing rate limits, pagination, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The tool-specific opening is well front-loaded (paid flag and purpose first), but the lengthy 'Agent entry points' block is suite-wide boilerplate that does not earn its place in this tool's description and dilutes focus. The core content is buried under routing meta-guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the two modes are explained. Combined with the candid data-source and limitation disclosures, an agent has enough to invoke it correctly; only parameter-level detail (window/min_transaction_usd semantics) is left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the mode/asset/chain/limit/window/min_transaction_usd/address fields, establishing the baseline of 3. The description clarifies the semantic difference between asset mode (token address) and wallet mode (recent indexed transactions), but adds no meaning for limit, window, or min_transaction_usd thresholds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening states a specific verb+resource ('Summarizes large public GeckoTerminal-indexed DEX trades') and scope ('for a token address on a supported chain'), and distinguishes two operating modes (asset vs wallet). It is clear what the tool does, though differentiation from siblings relies on generic routing boilerplate rather than tool-specific comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent entry points' block gives routing rules (unclear capability → /api/discover; comparison → route_tool; known single capability → direct tool), but this guidance is generic across the whole suite, not tailored to when whale-activity analysis is the right choice. There is no explicit when-not-to-use condition specific to this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
backtest_strategyAInspect
Paid Strategy Backtest ($0.10 USDC). Tests built-in long-only spot strategies against bounded public Binance OHLCV history. Signals form at candle close and execute at the next candle open. Applies configured fees/slippage; accepts declarative parameters only and never executes user code. Historical results are not predictions.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| market | Yes | ||
| fee_bps | No | ||
| strategy | Yes | ||
| timeframe | Yes | ||
| slippage_bps | No | ||
| initial_capital | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | No | |
| next | No | |
| tool | Yes | |
| error | No | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No | |
| timestamp | Yes |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses the $0.10 USDC cost, the signal-at-close/execute-at-next-open execution model, fee/slippage application, the safety guarantee that no user code runs, and the non-predictive nature of results. It stops short of rate limits, history-bound specifics, or failure modes, but this is strong disclosure for an unannotated mutation-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first block is tight and front-loaded with the core operation, cost, and semantics. However, the large 'Agent entry points' paragraph is generic cross-server boilerplate repeated verbatim, adding bulk that does not earn its place for this specific tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description covers cost, execution semantics, constraints, and safety. The main gap is the polymorphic strategy object and market/capital parameters, which are not explained anywhere, but the definition is otherwise complete for calling the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for fees/slippage ('configured fees/slippage'), the strategy nature ('built-in long-only spot strategies'), and the time-range/history bound, but leaves 'market' and 'initial_capital' unexplained and gives no detail on the strategy.parameters object. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (backtest) and resource (strategy) with precise scope: built-in long-only spot strategies against bounded Binance OHLCV history. The 'never executes user code' and 'historical results are not predictions' clauses further pin down exactly what class of operation this is, distinguishing it from any code-execution or live-trading sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent entry points' block is server-wide boilerplate (Agent Action Gate, /api/discover, route_tool, workflow recipes) that is not specific to backtest_strategy and offers no guidance on when to pick this tool versus an alternative. It only vaguely implies 'known single capability → call the direct tool.' No exclusions or preconditions for backtesting are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_changeBInspect
Paid Change / Diff Check ($0.001 USDC). Checks normalized text on a public HTTPS page against a previous SHA-256 hash, returning a compact diff when a prior snapshot is available.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| previous_hash | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| diff | Yes | |
| meta | No | |
| next | No | |
| error | No | |
| cached | Yes | |
| result | No | |
| status | No | |
| changed | Yes | |
| payment | No | |
| success | Yes | |
| summary | Yes | |
| agent_ux | No | |
| checked_at | Yes | |
| change_type | Yes | |
| change_score | Yes | |
| current_hash | Yes | |
| previous_hash | Yes | |
| data_age_seconds | Yes | |
| baseline_available | Yes |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose real traits: paid at $0.001 USDC, requires a public HTTPS page, calls are billed separately and not bundle-charged, and the diff is returned only 'when a prior snapshot is available'. It omits what happens when no snapshot exists, payment authorization mechanics, and error behavior, so it is partial rather than thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is tight and front-loaded with the cost and the action. The following block is long generic boilerplate about Agent Action Gate, /api/discover, route_tool and workflow recipes that is largely irrelevant to invoking this specific tool, and its list of 'does not...' exclusions is repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not needed, and the description does cover cost, the public-HTTPS precondition, and the conditional diff. With 0% schema coverage on both required params and no annotations, the edge cases (no prior snapshot, hash mismatch, payment failure) are left unspecified for a paid tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to both params: the url must be a public HTTPS page, and previous_hash is a SHA-256 hash. That is genuinely useful, but it does not cover format/length constraints or failure modes for a stale or mismatched hash.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb+resource: 'Checks normalized text on a public HTTPS page against a previous SHA-256 hash, returning a compact diff'. This is a clear, concrete capability. It stops short of naming the neighbouring siblings it is distinct from (check_url, scan_content), so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent entry points' block gives generic meta-routing ('known single capability → call the direct tool', 'multi-step objective → read the recipe'), but never states when to pick check_change over check_url or scan_content, nor the precondition that a prior snapshot must exist to get a diff. Usage is implied rather than instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_packageAInspect
Paid Package Safety Gate ($0.005 USDC on Base). Call before a coding agent installs, imports, or adds an unfamiliar npm dependency. Checks resolved package/version, OSV vulnerabilities and malware advisories, popular-name typosquatting, and install lifecycle scripts using static analysis only. Package code is never executed. Checks up to 10 direct dependencies when their versions can be resolved; it does not traverse transitive dependencies or assess maintainer history. Unknown coverage returns caution.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | ||
| version | No | ||
| ecosystem | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| cached | Yes | |
| result | No | |
| status | No | |
| package | Yes | |
| payment | No | |
| sources | Yes | |
| success | Yes | |
| agent_ux | No | |
| degraded | Yes | |
| warnings | Yes | |
| ecosystem | Yes | |
| checked_at | Yes | |
| deprecated | Yes | |
| reputation | Yes | |
| risk_level | Yes | |
| risk_score | Yes | |
| similar_to | Yes | |
| new_package | Yes | |
| recommendation | Yes | |
| typosquat_risk | Yes | |
| dependency_risk | Yes | |
| known_malicious | Yes | |
| maintainer_risk | Yes | |
| risk_confidence | Yes | |
| dependency_count | Yes | |
| maintainer_count | Yes | |
| package_age_days | Yes | |
| recommended_next | No | |
| resolved_version | Yes | |
| similarity_score | Yes | |
| requested_version | Yes | |
| suspicious_scripts | Yes | |
| dependency_findings | Yes | |
| install_script_risk | Yes | |
| malicious_confidence | Yes | |
| dependencies_analyzed | Yes | |
| known_vulnerabilities | Yes | |
| data_freshness_seconds | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so richly: cost ($0.005 USDC on Base), static-analysis-only execution guarantee, a hard limit of 10 direct dependencies, exclusion of transitive traversal and maintainer history, and the fallback behavior ("Unknown coverage returns caution").
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is front-loaded and efficient, but roughly half the text is generic gateway boilerplate about entry points and what Agent Action Gate does not do, which is repeated across sibling tools rather than earning its place here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation. Purpose, cost, and scope limits are complete; the only shortfall is the thin coverage of parameter semantics for a 3-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implies the package and version parameters ("resolved package/version") and constrains ecosystem to npm ("npm dependency"), but adds no format guidance for version ranges or what happens when version is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (checks an npm package) and enumerates exactly what it evaluates: OSV vulnerabilities, malware advisories, typosquatting, and lifecycle scripts. It is clearly distinguishable from siblings like check_url or route_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the trigger ("Call before a coding agent installs, imports, or adds an unfamiliar npm dependency") and the entry-point routing section directs the agent to Agent Action Gate, /api/discover, route_tool, or direct tools depending on the situation. When-to-use and alternatives are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_urlAInspect
Paid Agent Preflight URL check ($0.005 USDC on Base). Call before an agent opens, follows, downloads from, or trusts an unknown URL. Performs deterministic checks, safely inspects HTTPS redirects without loading page content, blocks localhost/private addresses, and optionally queries Google Web Risk when configured. No LLM is used. A clean result is not a guarantee of safety.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| safe | Yes | |
| error | No | |
| https | Yes | |
| cached | Yes | |
| result | No | |
| status | No | |
| malware | Yes | |
| payment | No | |
| sources | Yes | |
| success | Yes | |
| threats | Yes | |
| agent_ux | No | |
| degraded | Yes | |
| phishing | Yes | |
| warnings | Yes | |
| final_url | Yes | |
| checked_at | Yes | |
| risk_level | Yes | |
| risk_score | Yes | |
| normalized_url | Yes | |
| recommendation | Yes | |
| redirect_count | Yes | |
| domain_age_risk | Yes | |
| recommended_next | No | |
| suspicious_domain | Yes | |
| suspicious_redirect | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: discloses the $0.005 USDC cost, deterministic/no-LLM nature, that redirects are inspected without loading page content, that localhost/private addresses are blocked, optional Google Web Risk use, and an explicit limitation ('a clean result is not a guarantee of safety'). It stops short of error/timeout behavior or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is front-loaded and useful, but the trailing routing/disclaimer paragraph is long, generic, and reused boilerplate that dilutes the tool-specific payload. It earns partial place as sibling routing, but the ratio of boilerplate to signal is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be described, and the description covers trigger, cost, behavioral limits, and sibling routing. What remains thin is the input URL contract, which leaves a minor gap for a single required parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter at 0% schema coverage, so the description must compensate. It gives context (an 'unknown URL' the agent may open/follow/download) but never states expected format, scheme requirements, or the 4096-character bound present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (URL preflight check) with cost and chain, and immediately scopes what it inspects. It is distinguishable from siblings like check_package and check_change by naming the target artifact (URL) explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit trigger ('Call before an agent opens, follows, downloads from, or trusts an unknown URL') plus a routing paragraph naming alternatives: Agent Action Gate for combined action safety, /api/discover for unknown capabilities, route_tool for comparisons. The routing block is largely generic boilerplate reused across siblings, which slightly weakens the tool-specific guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_walletAInspect
Paid Wallet Risk Check ($0.02 USDC on Base). Call before an agent sends funds to, accepts value from, grants an approval to, or interacts with an unfamiliar address. Checks whether the address is a wallet or contract and reads basic on-chain metadata. Sanctions, scam, drainer, mixer, and malicious-address intelligence are unknown unless a trusted provider is configured; without one, the result is cautious and low-confidence, not a safety certification. Never send private keys or seed phrases.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| address | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| chain | Yes | |
| error | No | |
| cached | Yes | |
| result | No | |
| status | No | |
| address | Yes | |
| onchain | Yes | |
| payment | No | |
| sources | Yes | |
| success | Yes | |
| agent_ux | No | |
| contract | Yes | |
| degraded | Yes | |
| warnings | Yes | |
| exposures | Yes | |
| scam_risk | Yes | |
| checked_at | Yes | |
| reputation | Yes | |
| risk_level | Yes | |
| risk_score | Yes | |
| address_type | Yes | |
| drainer_risk | Yes | |
| mixer_exposure | Yes | |
| recommendation | Yes | |
| known_malicious | Yes | |
| risk_confidence | Yes | |
| sanctions_match | Yes | |
| suspicious_activity | Yes | |
| data_freshness_seconds | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses key behaviors: the $0.02 USDC cost on Base, the limited confidence without a configured trusted provider, and the explicit warning that it is not a safety certification. It also warns never to send private keys or seed phrases, which is critical operational guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, price, and primary usage, then follows with routing guidance. It is slightly long because the 'Agent entry points' paragraph is generic boilerplate, but most sentences still earn their place by clarifying alternatives or constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage context, cost, limitations, and safety warnings, and the output schema handles return values. The main gap is the lack of explicit parameter semantics for 'chain' and 'address', though the simple schema and regex pattern mitigate this for a two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the two parameters. It mentions 'address' but provides no format details beyond what the regex already enforces, and it only loosely implies a chain by saying 'on Base' without explaining the allowed base-sepolia option or the chain parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific tool: a paid wallet risk check that determines whether an address is a wallet or contract and reads basic on-chain metadata. It also explicitly distinguishes this tool from siblings like Agent Action Gate, route_tool, and /api/discover, so an agent can identify its role without opening other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to call it: before sending funds to, accepting value from, granting approval to, or interacting with an unfamiliar address. The 'Agent entry points' section then maps broader needs to alternatives such as Agent Action Gate for combined risk assessments, route_tool for comparisons, and workflow recipes for multi-step objectives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_structuredAInspect
Paid Fresh Structured Extract ($0.01 USDC). Extracts a fresh webpage into a simple agent-defined typed JSON shape, with validation and per-field provenance. Uses static page data only; never executes page JavaScript and never fabricates missing fields.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| schema | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| data | Yes | |
| meta | No | |
| next | No | |
| error | No | |
| cached | Yes | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No | |
| final_url | Yes | |
| confidence | Yes | |
| provenance | Yes | |
| validation | Yes | |
| extracted_at | Yes | |
| data_age_seconds | Yes | |
| recommended_next | No |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the load well: it discloses the price ($0.01 USDC), that it uses static page data only, that it never executes page JavaScript, and that it never fabricates missing fields. These are meaningful behavioral constraints, though it omits failure behavior and provenance format details that would fully round out the disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is tight, specific, and front-loaded. The second paragraph, however, is a long generic routing disclaimer that repeats across the toolset and does not earn its length in tool-specific value, diluting the conciseness of the definition as a whole.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description adds the essential context: payment, static-only extraction, and non-fabrication. Combined with the clear purpose statement, an agent has enough to invoke this tool correctly, with only minor gaps around the schema parameter's exact format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for two undocumented parameters. The phrase 'agent-defined typed JSON shape' gestures at the schema parameter's purpose, but the url parameter is only implied and the type-mapping syntax the schema enum allows is never explained, leaving the semantics partially covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a concrete verb (extracts), the resource (a fresh webpage), and the output form (agent-defined typed JSON with validation and per-field provenance), so the tool's function is unambiguous. It does not, however, explicitly differentiate itself from lookalike siblings such as check_url or scan_content, so the boundary is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent entry points' block gives explicit routing rules: direct tool for a known single capability, route_tool for comparisons, /api/discover for unclear capabilities, Agent Action Gate for risky external actions, and workflow recipes for multi-step objectives. This is strong when-to-use guidance, though it is generic ecosystem boilerplate that never names the extraction-specific alternatives an agent would weigh against this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_live_quoteBInspect
Paid Live Product Quote ($0.01 USDC). Retrieves explicitly published product price and stock from a public HTTPS product page before an agent buys; shipping, tax and unknown values remain null. Never purchases.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| variant | No | ||
| quantity | No | ||
| destination | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| quote | Yes | |
| cached | Yes | |
| result | No | |
| status | No | |
| payment | No | |
| product | Yes | |
| sources | Yes | |
| success | Yes | |
| variant | Yes | |
| agent_ux | No | |
| delivery | Yes | |
| confidence | Yes | |
| fetched_at | Yes | |
| availability | Yes | |
| data_age_seconds | Yes |
TDQS
B3.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningfully disclose behavior: it is paid ($0.01 USDC), it is a non-purchasing read ('never purchases'), and it defines null semantics for shipping, tax, and unknown values. It stops short of naming auth/payment mechanics (how the $0.01 is charged) or failure modes, which keeps it out of the top band.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is front-loaded, dense, and earns its place. The following paragraph, however, is ~120 words of server-wide agent-routing boilerplate that is identical across every sibling tool and dilutes the tool-specific signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and cost/read-only behavior is covered. But for a paid external-fetch tool with four parameters at 0% schema coverage and nested objects, gaps remain: what page/format support exists, what happens on unsupported pages, and what variant/quantity/destination actually change.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter semantics, and it largely does not. It hints that 'shipping, tax' exist (implying destination drives estimates) but never explains variant, quantity, or how destination.country/postal_code are used; an agent gets no more than it could infer from the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb (retrieves) and resource (explicitly published product price and stock from a public HTTPS product page) and adds a scope boundary ('never purchases'). It is clearly distinguishable from a purchasing tool, though the sibling differentiation that follows is generic routing boilerplate rather than something specific to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives the situational trigger ('before an agent buys') and the entry-point block includes 'known single capability → call the direct tool', which weakly justifies using this over route_tool or /api/discover. However, the block is server-wide boilerplate; it never addresses the overlapping siblings like extract_structured, check_url, or scan_content, so the guidance is implied rather than explicit for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice_preflightAInspect
Paid invoice check ($0.065 USDC on Base): UBL XML or complete PDF/image invoices up to 3 pages. Compares expected purchase fields and line items; returns evidence, amount checks and match/discrepancy/needs_review. No payment or bookkeeping action is taken.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| expected | No | ||
| mime_type | No | ||
| document_url | No | ||
| document_xml | No | ||
| document_base64 | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| checks | Yes | |
| result | No | |
| status | No | |
| invoice | Yes | |
| payment | No | |
| agent_ux | No | |
| decision | Yes | |
| evidence | Yes | |
| warnings | Yes | |
| source_sha256 | Yes | |
| pages_processed | No |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does well: discloses the exact price ($0.065 USDC on Base), input formats and a page cap, the nature of the result, and explicitly states no payment or bookkeeping action is taken. It does not describe how payment is authorized/charged or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening paragraph is tight and front-loaded. The second paragraph is largely generic routing boilerplate that recurs across tools and is only partially specific to this tool, diluting the signal without adding invoice-specific value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out. However, for a 5-parameter nested tool with zero schema documentation and a payment component, the description leaves the document-input alternatives, requiredness, and payment mechanics underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters including nested objects, so the description must compensate. It conveys meaning for the expected-fields object (purchase fields, line items) and the document input formats (XML vs complete PDF/image), but does not clarify that document_url/document_xml/document_base64 are alternative transports or how mime_type relates to them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (invoice check) with scope: UBL XML or PDF/image up to 3 pages, comparing expected fields and line items, returning match/discrepancy/needs_review. The 3-page limit and 'paid' qualifier cleanly separate it from the sibling invoice_preflight_10_pages and invoice_preflight_50_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent entry points' block explicitly routes: known single capability to the direct tool, unclear capability to /api/discover, constrained comparison to route_tool, combined safety assessment to Agent Action Gate, and multi-step to workflow recipes. It lacks a direct 'use this over the 10/50-page variants when the invoice is <=3 pages' statement, but alternatives and selection conditions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice_preflight_10_pagesBInspect
Paid invoice OCR ($0.13 USDC on Base): process complete PDF/image invoices up to 10 pages. Oversized PDFs are rejected before OCR.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| expected | No | ||
| mime_type | No | ||
| document_url | No | ||
| document_base64 | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| checks | Yes | |
| result | No | |
| status | No | |
| invoice | Yes | |
| payment | No | |
| agent_ux | No | |
| decision | Yes | |
| evidence | Yes | |
| warnings | Yes | |
| source_sha256 | Yes | |
| pages_processed | No |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it does disclose useful behavior: a paid operation at $0.13 USDC on Base and that oversized PDFs are rejected before OCR (implying no OCR work occurs on them). It stops short of covering payment/auth mechanics or whether rejected documents are charged, so it is partial rather than complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The tool-specific portion is two tight, front-loaded sentences that lead with the action and price. However, the large 'Agent entry points' boilerplate block is generic, largely irrelevant to this single tool, and dilutes the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and pricing/format/limits are present. But for a 4-parameter paid OCR tool with a nested 'expected' verification object and clear sibling tiers, the absence of any parameter explanation and of explicit tier-selection guidance leaves real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and it does not — none of document_url, document_base64, mime_type, or the nested 'expected' reconciliation object are explained. The 'expected' object in particular is non-obvious (it drives preflight verification against tax/total/subtotal/line_items) and is left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('process complete PDF/image invoices'), adds the exact scope limit ('up to 10 pages'), the input formats (PDF/image), and the pricing model. This clearly differentiates it from the tiered siblings invoice_preflight and invoice_preflight_50_pages without needing to open any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the 10-page ceiling, which implicitly routes larger documents to invoice_preflight_50_pages, and the appended 'Agent entry points' block gives generic routing (direct tool for known capability, route_tool for comparison). However, that block is boilerplate shared across tools and never explicitly contrasts this tier against its sibling tiers or states when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice_preflight_50_pagesBInspect
Paid invoice OCR ($0.475 USDC on Base): process complete PDF/image invoices up to 50 pages. Oversized PDFs are rejected before OCR.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| expected | No | ||
| mime_type | No | ||
| document_url | No | ||
| document_base64 | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| checks | Yes | |
| result | No | |
| status | No | |
| invoice | Yes | |
| payment | No | |
| agent_ux | No | |
| decision | Yes | |
| evidence | Yes | |
| warnings | Yes | |
| source_sha256 | Yes | |
| pages_processed | No |
TDQS
B3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the cost and currency and the pre-OCR rejection behavior for oversized files, but says nothing about payment/refund handling on rejection, whether document_url or document_base64 is required (both are non-required), authentication needs, or what preflight validation actually does on mismatch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is tightly front-loaded with scope, price, and the rejection rule. However, the multi-line entry-point paragraph is generic boilerplate that does not earn its place in a tool-specific definition and dilutes the signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. But for a 4-parameter tool with 0% schema coverage, nested objects, no annotations, and an unexplained 'expected' comparison argument, the description leaves essential calling information missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does not. It hints at mime_type via 'PDF/image' but never explains the nested 'expected' object (tax, total, currency, subtotal, line_items, supplier_name, purchase_order), which is the core semantic of the tool, nor the exclusivity or size limits of document_url vs document_base64.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Paid invoice OCR'), the concrete scope ('up to 50 pages'), the price ($0.475 USDC on Base), and a distinguishing constraint ('Oversized PDFs are rejected before OCR'). This clearly separates it from smaller-tier siblings by page limit, though it never names invoice_preflight_10_pages or invoice_preflight_quote to make the choice explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The entry-point paragraph offers generic routing heuristics ('known single capability → call the direct tool'), but it is shared boilerplate that applies to every tool rather than guidance specific to choosing the 50-page tier over the 10-page tier or the quote variant. Usage is only implied by the page cap and price.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice_preflight_quoteAInspect
FREE, no wallet or document upload: choose the lowest priced Invoice Preflight tool from document type, PDF page count, and optional byte size. Call this before a paid invoice tool when the tier is uncertain. It does not inspect or validate the document.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page_count | No | ||
| document_type | Yes | ||
| file_size_bytes | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| reason | Yes | |
| result | No | |
| status | No | |
| network | Yes | |
| payment | No | |
| agent_ux | No | |
| price_usdc | Yes | |
| no_payment_taken | Yes | |
| recommended_tool | Yes | |
| document_not_inspected | Yes | |
| final_validation_on_paid_call | Yes |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that the operation is FREE, requires no wallet or document upload, performs no inspection/validation, and is not bundle charged. It does not state latency, caching, or rate limits, but for a stateless quote lookup the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first two sentences are tight and front-loaded, but the long 'Agent entry points' paragraph is largely boilerplate about other tools (Agent Action Gate, route_tool, workflow recipes) and contributes little to selecting or invoking this specific quote tool. It inflates the definition without earning its length here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complexity is low, the schema is small and simple, and an output schema exists so return values need not be explained. Combined with the free/no-wallet disclosure, the description gives an agent enough to call it correctly; the off-topic routing paragraph is the only weak point.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description names all three inputs (document type, PDF page count, optional byte size), which compensates partially and matches the schema properties. It does not add format, units, or edge-case details beyond the parameter names and the 1–10000 bounds already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb and resource — pick the lowest-priced Invoice Preflight tool — and explicitly scopes it as free with no wallet or document upload. It distinguishes itself cleanly from the paid invoice siblings (invoice_preflight, invoice_preflight_10_pages, invoice_preflight_50_pages) and disclaims that it does not inspect the document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a direct when-to-use rule: 'Call this before a paid invoice tool when the tier is uncertain.' The entry-point block also routes among alternatives (Agent Action Gate, discover, route_tool, direct tool), giving clear context. It stops short of an explicit when-not-to-use for this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_server_inspectAInspect
MCP server health check ($0.01 USDC on Base): connect to any public MCP endpoint over HTTPS, confirm it is reachable, list its tool names and input-schema summaries, compare against expected tool names, and flag risky or misleading tool descriptions. Read-only: inspected tools are never called. Use it before wiring an unknown MCP server into an agent, or to verify your own deployment. Pair with check_url to pre-screen a suspicious endpoint.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | ||
| expected_tools | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| error | No | |
| tools | Yes | |
| result | No | |
| server | Yes | |
| status | No | |
| payment | No | |
| agent_ux | No | |
| tool_count | Yes | |
| capabilities | Yes | |
| inspected_at | Yes | |
| endpoint_host | Yes | |
| expected_tools | Yes | |
| tool_list_truncated | Yes | |
| duplicate_tool_names | Yes | |
| read_only_inspection | Yes | |
| metadata_is_untrusted | Yes | |
| tools_were_not_called | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses read-only behavior ('inspected tools are never called'), the cost and payment rail ($0.01 USDC on Base), and that inspected content is only summarized, never executed. It does not cover failure modes (unreachable endpoint, invalid URL) or rate limits, so it falls short of full disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first paragraph is tight, front-loaded, and entirely on-point. The second 'Agent entry points' paragraph is long generic boilerplate that spends most of its words on other tools (Agent Action Gate, route_tool, /api/discover) and on what a sibling does not do, diluting the tool's own definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. The description covers cost, read-only guarantee, and the full operation set, which is sufficient for a two-parameter inspection tool. Minor gaps remain around unreachable-endpoint handling and what happens when expected_tools is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly maps both parameters: 'endpoint' via 'connect to any public MCP endpoint over HTTPS' (establishing the HTTPS requirement and public reachability) and 'expected_tools' via 'compare against expected tool names'. It adds meaning but no syntax, array limits, or format guidance beyond what the parameter names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('MCP server health check') and enumerates the concrete operations: connect over HTTPS, confirm reachability, list tool names and input-schema summaries, compare against expected names, and flag risky descriptions. This is clearly distinguishable from siblings like check_url, scan_content, or route_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states explicit when-to-use conditions ('before wiring an unknown MCP server into an agent, or to verify your own deployment') and names a complementary sibling ('Pair with check_url to pre-screen a suspicious endpoint'). The agent entry-points paragraph further routes between alternatives by scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preflight_actionAInspect
Agent Action Gate ($0.02 USDC flat; stable MCP tool name preflight_action). Use before an AI agent performs an external action. Evaluates the required safety, trust, spending and transaction checks and returns ALLOW, REVIEW, REQUIRE_APPROVAL or DENY. Use before opening an untrusted URL, installing a dependency, calling an unfamiliar MCP/tool, spending funds, submitting a transaction, or consuming untrusted external content. Do not use for pure local deterministic computation or when no external action/risk exists. Does not assess seller reputation. Missing or skipped relevant checks cannot produce ALLOW. REQUIRE_APPROVAL is a recommendation only; use /api/financial/authorize-spend separately for actual spend-policy authorization and owner approval. It does not sign, route payment, or broadcast. No private keys, seed phrases, or secrets are accepted. Typical latency depends on selected checks/providers; there is no uniform SLA. Recommended workflows: agent-safety-gate, safe-transaction-preflight, tool-discovery-trust.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | ||
| target | No | ||
| context | No | ||
| action_type | Yes | ||
| expected_cost | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| risk | Yes | |
| error | No | |
| checks | Yes | |
| intent | Yes | |
| result | No | |
| status | No | |
| payment | No | |
| reasons | Yes | |
| success | Yes | |
| agent_ux | No | |
| decision | Yes | |
| retryable | Yes | |
| checks_run | Yes | |
| confidence | Yes | |
| latency_ms | Yes | |
| action_type | Yes | |
| skip_reason | Yes | |
| failed_checks | Yes | |
| decision_scope | Yes | |
| estimated_cost | Yes | |
| next_best_tool | Yes | |
| skipped_checks | Yes | |
| evidence_status | Yes | |
| required_checks | Yes | |
| approval_handoff | Yes | |
| attempted_checks | Yes | |
| completed_checks | Yes | |
| recommended_action | Yes | |
| confidence_semantics | Yes | |
| signing_or_broadcast_performed | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: flat $0.02 USDC pricing, that missing/skipped checks cannot yield ALLOW, that REQUIRE_APPROVAL is a recommendation only, that it does not sign/route/broadcast payments, that no keys or secrets are accepted, and that latency has no uniform SLA. It also clarifies workflows are stateless recipes not bundle-charged executors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded well (name, price, use case), but the text is dense and contains genuine repetition — 'It does not sign, route payment, or broadcast' restates the earlier 'does not approve payment, sign or broadcast transactions', and the non-replacement list is duplicated by 'Agent Action Gate does not... replace human approval'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is unnecessary. For a paid gate with nested params and enumerated decisions, the description supplies pricing, decision semantics, exclusions, sibling routing, and workflow guidance — everything needed to decide whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with five top-level params including nested target/context/expected_cost objects. The action-type list implicitly maps inputs to fields (URL→open_url, package→install_package, transaction→transaction, content→use_external_content), which adds real value, but intent, risk_tolerance, agent_id, purpose, expected_cost subfields and extract_fields remain undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Evaluates the required safety, trust, spending and transaction checks') and names the exact output vocabulary (ALLOW, REVIEW, REQUIRE_APPROVAL, DENY). It distinguishes itself from siblings by explicitly pointing to /api/discover, route_tool, and direct tools as separate paths, so an agent can tell it apart without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use list (untrusted URL, dependency install, unfamiliar MCP/tool, spending funds, submitting a transaction, consuming untrusted content), an explicit when-not ('pure local deterministic computation... no external action/risk'), and routing to alternatives by scenario. This leaves almost nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
route_toolAInspect
Paid Agent Tool Router ($0.002 USDC on Base). Finds and ranks machine-payable MCP services and x402 HTTP endpoints before your agent chooses or pays a provider. Uses structured capability matching, hard constraints, price, observed latency/reliability, and cold-start trust confidence; no LLM call is required. Returns the best tool, confidence, reason, price, relevant workflow, next-best option, and a context-aware recommended_next when useful. This is recommendation metadata only: it never invokes the selected provider or makes a second payment. Without X402_BAZAAR_DISCOVERY_URLS, results come only from this platform's local service registry and are marked degraded.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| capability | Yes | ||
| constraints | No | ||
| preferences | No | ||
| completed_tools | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| why | No | |
| meta | No | |
| next | No | |
| error | No | |
| query | Yes | |
| cached | Yes | |
| reason | No | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No | |
| degraded | Yes | |
| best_tool | No | |
| capability | Yes | |
| checked_at | Yes | |
| confidence | No | |
| match_found | Yes | |
| recommended | Yes | |
| alternatives | Yes | |
| optimize_for | Yes | |
| next_best_tool | No | |
| routing_reason | Yes | |
| relevance_score | No | |
| candidates_found | Yes | |
| recommended_next | No | |
| registry_sources | Yes | |
| confidence_semantics | No | |
| recommended_workflow | No | |
| expected_total_cost_usd | No | |
| candidates_after_filters | Yes | |
| routing_data_age_seconds | Yes | |
| provider_availability_source | No | |
| provider_availability_observed_at | No |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well: it discloses the paid cost ($0.002 USDC on Base), states that it never invokes the selected provider or makes a second payment, notes it is recommendation metadata only, and explains degraded results when X402_BAZAAR_DISCOVERY_URLS is absent. It also clarifies that no LLM call is required and that workflows are stateless recipes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded and well-structured, opening with the core purpose and cost. Most sentences earn their place by clarifying alternatives or behavior, though the detailed Agent Action Gate limitation list is somewhat tangential for this specific tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It is largely complete for a complex paid routing tool: purpose, cost, side effects, degraded mode, output fields, and alternatives are covered, and an output schema exists so return values need not be explained. The main gap is parameter-level semantics for the five inputs, which matters given 0% schema description coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not describe the five input parameters directly. It references capability matching, hard constraints, price, latency/reliability, but omits what 'query', 'completed_tools', and 'preferences.optimize_for' do and never explains allowed values or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Paid Agent Tool Router... Finds and ranks machine-payable MCP services and x402 HTTP endpoints before your agent chooses or pays a provider.' It distinguishes itself from siblings through explicit entry-point guidance (free /api/discover, direct tool, Agent Action Gate, workflow recipes), so an agent can identify its unique role without opening other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use and when-not-to-use guidance: 'risky external action → use Agent Action Gate... unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool.' This directly routes the agent among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_arbitrageAInspect
Paid Arbitrage Intelligence ($0.03 USDC). Compares Binance and Coinbase public spot order books at a requested trade size and applies caller- or server-configured taker fee assumptions. Rejects stale books. Excludes transfers, inventory rebalancing, and guaranteed execution; does not place orders.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| venues | No | ||
| quote_asset | No | USDT | |
| trade_size_usd | Yes | ||
| fee_bps_by_venue | No | ||
| min_net_spread_bps | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | No | |
| next | No | |
| tool | Yes | |
| error | No | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No | |
| timestamp | Yes |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses price ($0.03 USDC), staleness handling ('rejects stale books'), and clear negative guarantees (no transfers, no inventory rebalancing, no guaranteed execution, does not place orders). It omits auth/credential requirements, rate limits, and what failure mode a rejected stale book produces for the caller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first paragraph is dense and front-loaded with cost and scope. The second paragraph is long generic routing boilerplate about Agent Action Gate, /api/discover, and workflows that has little to do with arbitrage scanning and inflates the definition considerably.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because an output schema exists, return-value explanation is not required, and the scope/exclusions are well covered. However, for a 6-parameter paid tool with zero schema description coverage, the description leaves several inputs (min_net_spread_bps, quote_asset, venues) and the stale-book rejection behavior undefined for the caller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 6 parameters including a nested fee map, so the description must compensate. It explains trade_size ('at a requested trade size') and clarifies fee_bps_by_venue as 'caller- or server-configured', but says nothing about quote_asset, venues selection, or min_net_spread_bps threshold behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+scope: it compares Binance and Coinbase public spot order books at a requested trade size and applies taker fee assumptions. An agent can distinguish this from quote-style siblings like get_live_quote and from route_tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The routing paragraph gives real guidance ('known single capability → call the direct tool', 'constrained comparison → use paid route_tool'), but it is ecosystem-wide boilerplate rather than advice about scan_arbitrage specifically. It never states when this tool beats get_live_quote or analyze_whale_activity for a given arbitrage question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_contentAInspect
Paid Untrusted Content Security Layer ($0.005 USDC on Base). Scan untrusted text, HTML, Markdown, email, document text, API responses, and tool outputs before your agent adds them to context, follows their instructions, or acts. Returns risk score, risk categories, recommendation, and sanitized plain text when possible. Bounded deterministic local scanning; no external LLM or provider call. Maximum 100000 characters.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | ||
| content | Yes | ||
| content_type | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| safe | Yes | |
| error | No | |
| cached | Yes | |
| result | No | |
| status | No | |
| payment | No | |
| sources | Yes | |
| agent_ux | No | |
| degraded | Yes | |
| risk_level | Yes | |
| risk_score | Yes | |
| scanned_at | Yes | |
| recommendation | Yes | |
| detected_patterns | Yes | |
| requested_actions | Yes | |
| sanitized_content | Yes | |
| credential_theft_risk | Yes | |
| data_exfiltration_risk | Yes | |
| tool_manipulation_risk | Yes | |
| instruction_override_risk | Yes | |
| prompt_injection_detected | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it delivers: paid cost ($0.005 USDC on Base), deterministic local scanning with no external LLM/provider call, a 100000-character cap, and the return shape (risk score, categories, recommendation, sanitized text). It omits payment/auth mechanics and any rate-limit or failure behavior, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first paragraph is well front-loaded and earns its place. The 'Agent entry points' block is largely server-wide routing boilerplate, and the closing list of things Agent Action Gate does *not* do describes a sibling tool rather than this one, which dilutes an otherwise tight definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is optional, yet the description still summarizes outputs helpfully. Combined with the payment model, scanning determinism, size limit, and routing guidance, this is close to complete; the only real gap is the undocumented 'source' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are 3 parameters, so the description must compensate. It enumerates the content_type values and states the content length cap, but the 'source' parameter (max 2048 chars) is never mentioned, leaving one of three parameters undocumented anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Scan untrusted text, HTML, Markdown, email, document text, API responses, and tool outputs') and its scope ('before your agent adds them to context, follows their instructions, or acts'). This clearly separates it from sibling scanners like check_url, verify_claim, or token_security_audit by naming the exact content domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('before your agent adds them to context, follows their instructions, or acts') and explicit routing to alternatives by condition: Agent Action Gate for combined action-safety assessment, free /api/discover for unclear capability, paid route_tool for constrained comparison, direct tool for a known single capability. Nothing 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.
simulate_transactionAInspect
Paid Transaction Preflight ($0.02 USDC on Base). Simulates an unsigned Base transaction before an autonomous agent signs or broadcasts it. Returns RPC execution/revert status, gas estimate, known top-level method decoding, direct ERC-20 transfer/approval calldata, unlimited approval warnings, and machine-readable risk. Standard JSON-RPC does not expose full internal token state changes; do not treat calldata decoding as a complete state diff. Never send a private key or seed phrase. This tool never signs, holds keys, or broadcasts.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| data | Yes | ||
| from | Yes | ||
| chain | Yes | ||
| value | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| chain | Yes | |
| error | No | |
| cached | Yes | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No | |
| chain_id | Yes | |
| degraded | Yes | |
| warnings | Yes | |
| approvals | Yes | |
| checked_at | Yes | |
| risk_level | Yes | |
| risk_score | Yes | |
| estimated_gas | Yes | |
| gas_price_wei | Yes | |
| revert_reason | Yes | |
| analysis_scope | Yes | |
| contract_calls | Yes | |
| recommendation | Yes | |
| simulated_block | Yes | |
| token_transfers | Yes | |
| estimated_usd_cost | Yes | |
| simulation_success | Yes | |
| contract_reputation | Yes | |
| estimated_native_cost | Yes | |
| native_balance_changes | Yes |
TDQS
A4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it enumerates the returned signals (revert status, gas estimate, method decoding, ERC-20 transfer/approval calldata, unlimited-approval warnings, machine-readable risk), discloses a hard limitation (no full internal token state diff), and states the safety contract (never signs, holds keys, or broadcasts; never send a private key).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first paragraph is dense and well front-loaded, but the 'Agent entry points' paragraph is generic cross-tool routing boilerplate that is not specific to this tool and repeats the same 'does not replace...' caveat twice, diluting focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values are covered by the output schema and the description redundantly restates them; safety and limitations are well covered. The gap is parameter-level semantics for 5 undocumented required fields, which the schema alone does not explain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 required parameters, and the description adds no per-parameter meaning for chain, from, to, value, or data. It implies 'unsigned transaction' and mentions ERC-20 calldata decoding, but an agent still gets no guidance on the value units, data encoding expectations, or chain field values beyond the schema enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource+scope: simulates an unsigned Base transaction before signing/broadcasting. It is clearly distinguishable from sibling audit/simulation tools (token_security_audit, preflight_action) and names the paid cost and chain up front.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent entry points' block gives an explicit routing map (risky external action -> Agent Action Gate, unclear capability -> discover, comparison -> route_tool, known capability -> direct tool) and states what this tool does not replace. However, it never states directly when to prefer simulate_transaction over close siblings like preflight_action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_security_auditBInspect
Paid Token Security Audit ($0.01 USDC). Normalizes GoPlus token-security flags and public EVM RPC metadata for supported EVM tokens. Configure GOPLUS_ACCESS_TOKEN or explicitly enable the bounded public API with GOPLUS_PUBLIC_TOKEN_API_ENABLED=1; if neither is available, no payment is requested. Missing provider fields remain unknown and incomplete coverage returns caution. Reports provider findings separately from deterministic internal scoring. Does not trade or guarantee token safety.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| token_address | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | No | |
| next | No | |
| tool | Yes | |
| error | No | |
| result | No | |
| status | No | |
| payment | No | |
| success | Yes | |
| agent_ux | No | |
| timestamp | Yes |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the $0.01 USDC price, that no payment is requested when no provider is configured, that missing provider fields stay 'unknown' and incomplete coverage returns 'caution', and that provider findings are reported separately from internal scoring. It does not cover rate limits or exactly what happens on unsupported chains, but the failure-mode and pricing disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core audit paragraph is dense but front-loaded with the paid nature and scope, and every clause carries information. However, the trailing "Agent entry points" block is long, generic boilerplate applicable to many tools rather than this one, diluting the signal-to-noise ratio.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers pricing, configuration prerequisites, failure modes, and scope boundaries adequately for calling correctly. The only material gap is that supported chains/token address expectations are left entirely to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does not — it says 'supported EVM tokens' without enumerating the supported chains or explaining the token_address format. The chain enum in the schema self-documents valid values, but the description adds no semantics for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening states a specific verb and resource — a paid token security audit that normalizes GoPlus flags and EVM RPC metadata for supported EVM tokens — and draws an explicit boundary ("Does not trade or guarantee token safety"). It is clearly a read-only security-check tool, though it never names how it differs from audit-adjacent siblings like check_wallet or verify_claim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is present but generic: the "Agent entry points" block routes by capability shape ("known single capability → call the direct tool") rather than stating when to pick token_security_audit over check_wallet or simulate_transaction. Prerequisites (GOPLUS token or bounded public API) are stated, which is useful, but no explicit when/not/alternative specific to this tool appears.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_claimAInspect
Paid Freshness / Claim Verifier ($0.02 USDC). Checks a factual claim against fresh web search evidence and returns supported/contradicted/mixed/insufficient/stale with sources. Requires TAVILY_API_KEY. If the key is missing, returns a provider-unavailable error before requesting payment. Claim text is sent to the configured search provider.
Agent entry points: risky external action → use Agent Action Gate when a combined action-specific safety assessment is needed; unclear capability/provider → use free /api/discover; constrained comparison between callable alternatives → use paid route_tool; known single capability → call the direct tool; multi-step objective → read the matching workflow recipe and call only relevant steps. Workflows are stateless recipes, not executors; calls are paid separately and are not bundle charged. Agent Action Gate does not approve payment, sign or broadcast transactions, evaluate seller reputation, replace transaction simulation, replace route_tool, or replace human approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | ||
| freshness_days | No | ||
| preferred_domains | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | No | |
| next | No | |
| claim | Yes | |
| error | No | |
| cached | Yes | |
| result | No | |
| status | No | |
| payment | No | |
| sources | Yes | |
| success | Yes | |
| verdict | Yes | |
| agent_ux | No | |
| degraded | Yes | |
| evidence | Yes | |
| warnings | Yes | |
| freshness | Yes | |
| confidence | Yes | |
| verified_at | Yes | |
| conflicting_evidence | Yes |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does it well: it discloses the price ($0.02 USDC), the TAVILY_API_KEY requirement, the failure behavior (provider-unavailable error returned before payment is requested), and the privacy side effect (claim text is sent to the external search provider). These are exactly the non-obvious traits an agent must know before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is front-loaded and dense: price, function, output values, auth, and failure mode in four tight sentences. The appended routing paragraph is longer and server-wide boilerplate rather than tool-specific, so it dilutes rather than sharpens, but the essential content stays up front.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-structure explanation is optional (the verdict enumeration is a bonus), and the payment, key, error, and privacy behavior are covered. The main shortfall is the entirely undocumented parameters, which leaves an agent guessing at freshness and domain-filter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all three parameters, so the description must compensate, and it largely does not. 'Fresh web search evidence' faintly hints at freshness_days, but the range/semantics of freshness_days and the purpose of preferred_domains (up to 10 domain filters) are never explained, and the claim length bounds (8-2000 chars) go unmentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb and resource (checks a factual claim) and enumerates the exact verdict space (supported/contradicted/mixed/insufficient/stale) plus the evidence returned (sources). This is clearly differentiable from siblings like check_url, scan_content, or extract_structured, which operate on URLs/content rather than claim truth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The entry-point routing block gives clear context: a known single capability means 'call the direct tool,' while comparisons go to route_tool and unclear capability to /api/discover. That is useful disambiguation, though the guidance is generic to the server rather than tailored to when claim verification specifically beats check_url or scan_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- Changed
action_lock2 fields changed- added
Output schema / properties / retry_decisionAdded value: +{ + "enum": [ + "RETRY_ALLOWED", + "RETRY_LATER", + "DO_NOT_RETRY", + "REVIEW" + ], + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "success", - "decision", - "state", - "action_id", - "lease_token", - "lease_expires_at", - "dedupe_expires_at", - "duplicate", - "retry_after_ms", - "reason" -]New value: +[ + "success", + "decision", + "retry_decision", + "state", + "action_id", + "lease_token", + "lease_expires_at", + "dedupe_expires_at", + "duplicate", + "retry_after_ms", + "reason" +]
- Added
agent_outcome_receipt - Added
agent_permission_vault - Added
agent_spend_governor
1 tool update
- Added
action_lock
3 tool updates
- Changed
check_url1 field changed- added
Output schema / properties / recommended_next / properties / recommendation_idAdded value: +{ + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" +}
- Changed
extract_structured1 field changed- added
Output schema / properties / recommended_next / properties / recommendation_idAdded value: +{ + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" +}
- Changed
route_tool1 field changed- changed
Output schema / properties / recommended_next / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "availability": { - "type": [ - "string", - "null" - ] - }, - "availability_observation": { - "type": "string" - }, - "condition": { - "type": "string" - }, - "price": { - "type": [ - "string", - "null" - ] - }, - "reason": { - "type": "string" - }, - "tool": { - "type": "string" - }, - "workflow_id": { - "type": "string" - } - }, - "required": [ - "tool", - "reason", - "price" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "availability": { + "type": [ + "string", + "null" + ] + }, + "availability_observation": { + "type": "string" + }, + "condition": { + "type": "string" + }, + "price": { + "type": [ + "string", + "null" + ] + }, + "reason": { + "type": "string" + }, + "recommendation_id": { + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "tool": { + "type": "string" + }, + "workflow_id": { + "type": "string" + } + }, + "required": [ + "tool", + "reason", + "price" + ], + "type": "object" + }, + { + "type": "null" + } +]
20 tool updates
- Changed
analyze_whale_activity11 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - changed
Output schema / properties / meta / additionalPropertiesPrevious value: -falseNew value: +{} - removed
Output schema / properties / meta / propertiesRemoved value: -{ - "cache": { - "additionalProperties": false, - "properties": { - "age_ms": { - "minimum": 0, - "type": "number" - }, - "hit": { - "type": "boolean" - } - }, - "required": [ - "hit", - "age_ms" - ], - "type": "object" - }, - "failed_sources": { - "items": { - "additionalProperties": false, - "properties": { - "reason": { - "type": "string" - }, - "source": { - "type": "string" - } - }, - "required": [ - "source", - "reason" - ], - "type": "object" - }, - "type": "array" - }, - "latency_ms": { - "minimum": 0, - "type": "number" - }, - "partial": { - "type": "boolean" - }, - "sources": { - "items": { - "type": "string" - }, - "type": "array" - } -} - added
Output schema / properties / meta / propertyNamesAdded value: +{ + "type": "string" +} - removed
Output schema / properties / meta / requiredRemoved value: -[ - "sources", - "latency_ms", - "partial", - "failed_sources", - "cache" -] - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "success", - "tool", - "timestamp", - "data", - "meta" -]New value: +[ + "success", + "tool", + "timestamp", + "data" +]
- Changed
backtest_strategy11 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - changed
Output schema / properties / meta / additionalPropertiesPrevious value: -falseNew value: +{} - removed
Output schema / properties / meta / propertiesRemoved value: -{ - "cache": { - "additionalProperties": false, - "properties": { - "age_ms": { - "minimum": 0, - "type": "number" - }, - "hit": { - "type": "boolean" - } - }, - "required": [ - "hit", - "age_ms" - ], - "type": "object" - }, - "failed_sources": { - "items": { - "additionalProperties": false, - "properties": { - "reason": { - "type": "string" - }, - "source": { - "type": "string" - } - }, - "required": [ - "source", - "reason" - ], - "type": "object" - }, - "type": "array" - }, - "latency_ms": { - "minimum": 0, - "type": "number" - }, - "partial": { - "type": "boolean" - }, - "sources": { - "items": { - "type": "string" - }, - "type": "array" - } -} - added
Output schema / properties / meta / propertyNamesAdded value: +{ + "type": "string" +} - removed
Output schema / properties / meta / requiredRemoved value: -[ - "sources", - "latency_ms", - "partial", - "failed_sources", - "cache" -] - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "success", - "tool", - "timestamp", - "data", - "meta" -]New value: +[ + "success", + "tool", + "timestamp", + "data" +]
- Changed
check_change7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
check_package7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
check_url11 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / recommended_next / properties / availabilityAdded value: +{ + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / recommended_next / properties / availability_observationAdded value: +{ + "type": "string" +} - added
Output schema / properties / recommended_next / properties / conditionAdded value: +{ + "type": "string" +} - added
Output schema / properties / recommended_next / properties / workflow_idAdded value: +{ + "type": "string" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
check_wallet7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
extract_structured11 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / recommended_next / properties / availabilityAdded value: +{ + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / recommended_next / properties / availability_observationAdded value: +{ + "type": "string" +} - added
Output schema / properties / recommended_next / properties / conditionAdded value: +{ + "type": "string" +} - added
Output schema / properties / recommended_next / properties / workflow_idAdded value: +{ + "type": "string" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
get_live_quote7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
invoice_preflight7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
invoice_preflight_10_pages7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
invoice_preflight_50_pages7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
invoice_preflight_quote8 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - changed
Output schema / properties / status / enumPrevious value: -[ - "ready", - "needs_page_count", - "unsupported", - "temporarily_unavailable" -]New value: +[ + "succeeded", + "failed", + "partial", + "outcome_unknown" +] - changed
Output schema / requiredPrevious value: -[ - "status", - "recommended_tool", - "price_usdc", - "network", - "reason", - "no_payment_taken", - "document_not_inspected", - "final_validation_on_paid_call" -]New value: +[ + "recommended_tool", + "price_usdc", + "network", + "reason", + "no_payment_taken", + "document_not_inspected", + "final_validation_on_paid_call" +]
- Changed
mcp_server_inspect9 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - removed
Output schema / properties / status / constRemoved value: -"reachable" - added
Output schema / properties / status / enumAdded value: +[ + "succeeded", + "failed", + "partial", + "outcome_unknown" +] - changed
Output schema / requiredPrevious value: -[ - "status", - "endpoint_host", - "inspected_at", - "server", - "capabilities", - "tool_count", - "tool_list_truncated", - "duplicate_tool_names", - "expected_tools", - "tools", - "read_only_inspection", - "tools_were_not_called", - "metadata_is_untrusted" -]New value: +[ + "endpoint_host", + "inspected_at", + "server", + "capabilities", + "tool_count", + "tool_list_truncated", + "duplicate_tool_names", + "expected_tools", + "tools", + "read_only_inspection", + "tools_were_not_called", + "metadata_is_untrusted" +]
- Changed
preflight_action13 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / approval_handoffAdded value: +{ + "additionalProperties": false, + "properties": { + "note": { + "type": "string" + }, + "request_id": { + "type": "null" + }, + "status": { + "enum": [ + "not_requested", + "not_created_by_gate" + ], + "type": "string" + } + }, + "required": [ + "status", + "request_id", + "note" + ], + "type": "object" +} - added
Output schema / properties / attempted_checksAdded value: +{ + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / confidence_semanticsAdded value: +{ + "const": "Heuristic evidence sufficiency/risk signal; not a probability or guarantee.", + "type": "string" +} - added
Output schema / properties / decision_scopeAdded value: +{ + "additionalProperties": false, + "properties": { + "assesses": { + "items": { + "type": "string" + }, + "type": "array" + }, + "does_not": { + "items": { + "type": "string" + }, + "type": "array" + }, + "question": { + "const": "Should my agent perform this action?", + "type": "string" + } + }, + "required": [ + "question", + "assesses", + "does_not" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / evidence_statusAdded value: +{ + "enum": [ + "incomplete", + "rule_evaluable" + ], + "type": "string" +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "success", - "decision", - "risk", - "confidence", - "required_checks", - "completed_checks", - "checks_run", - "failed_checks", - "skipped_checks", - "skip_reason", - "reasons", - "retryable", - "estimated_cost", - "recommended_action", - "next_best_tool", - "latency_ms", - "signing_or_broadcast_performed", - "checks", - "action_type", - "intent" -]New value: +[ + "success", + "decision", + "risk", + "confidence", + "confidence_semantics", + "evidence_status", + "required_checks", + "attempted_checks", + "completed_checks", + "checks_run", + "failed_checks", + "skipped_checks", + "skip_reason", + "reasons", + "retryable", + "estimated_cost", + "recommended_action", + "next_best_tool", + "latency_ms", + "signing_or_broadcast_performed", + "checks", + "decision_scope", + "approval_handoff", + "action_type", + "intent" +]
- Changed
route_tool14 fields changed- added
Input schema / properties / completed_toolsAdded value: +{ + "items": { + "maxLength": 128, + "minLength": 1, + "type": "string" + }, + "maxItems": 30, + "type": "array" +} - added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / confidence_semanticsAdded value: +{ + "type": "string" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / provider_availability_observed_atAdded value: +{ + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / provider_availability_sourceAdded value: +{ + "type": "string" +} - changed
Output schema / properties / recommended_next / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "price": { - "type": [ - "string", - "null" - ] - }, - "reason": { - "type": "string" - }, - "tool": { - "type": "string" - }, - "workflow_id": { - "type": "string" - } - }, - "required": [ - "tool", - "reason", - "price" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "availability": { + "type": [ + "string", + "null" + ] + }, + "availability_observation": { + "type": "string" + }, + "condition": { + "type": "string" + }, + "price": { + "type": [ + "string", + "null" + ] + }, + "reason": { + "type": "string" + }, + "tool": { + "type": "string" + }, + "workflow_id": { + "type": "string" + } + }, + "required": [ + "tool", + "reason", + "price" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / recommended_workflow / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "estimated_total_price_usd": { - "type": "number" - }, - "id": { - "type": "string" - }, - "name": { - "type": "string" - } - }, - "required": [ - "id", - "name", - "estimated_total_price_usd" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "estimated_cost": { + "additionalProperties": false, + "properties": { + "basis": { + "type": "string" + }, + "conditional_call_count": { + "type": "number" + }, + "currency": { + "type": "string" + }, + "expected": { + "type": "number" + }, + "max": { + "type": "number" + }, + "min": { + "type": "number" + }, + "optional_call_count": { + "type": "number" + }, + "required_call_count": { + "type": "number" + } + }, + "required": [ + "min", + "expected", + "max", + "currency", + "basis", + "required_call_count", + "conditional_call_count", + "optional_call_count" + ], + "type": "object" + }, + "estimated_total_price_usd": { + "type": "number" + }, + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "next_required_step": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "condition": { + "type": [ + "string", + "null" + ] + }, + "tool": { + "type": "string" + }, + "type": { + "type": "string" + } + }, + "required": [ + "tool", + "type", + "condition" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "state_mode": { + "enum": [ + "client_managed" + ], + "type": "string" + } + }, + "required": [ + "id", + "name", + "estimated_total_price_usd" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / relevance_scoreAdded value: +{ + "type": "number" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
scan_arbitrage11 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - changed
Output schema / properties / meta / additionalPropertiesPrevious value: -falseNew value: +{} - removed
Output schema / properties / meta / propertiesRemoved value: -{ - "cache": { - "additionalProperties": false, - "properties": { - "age_ms": { - "minimum": 0, - "type": "number" - }, - "hit": { - "type": "boolean" - } - }, - "required": [ - "hit", - "age_ms" - ], - "type": "object" - }, - "failed_sources": { - "items": { - "additionalProperties": false, - "properties": { - "reason": { - "type": "string" - }, - "source": { - "type": "string" - } - }, - "required": [ - "source", - "reason" - ], - "type": "object" - }, - "type": "array" - }, - "latency_ms": { - "minimum": 0, - "type": "number" - }, - "partial": { - "type": "boolean" - }, - "sources": { - "items": { - "type": "string" - }, - "type": "array" - } -} - added
Output schema / properties / meta / propertyNamesAdded value: +{ + "type": "string" +} - removed
Output schema / properties / meta / requiredRemoved value: -[ - "sources", - "latency_ms", - "partial", - "failed_sources", - "cache" -] - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "success", - "tool", - "timestamp", - "data", - "meta" -]New value: +[ + "success", + "tool", + "timestamp", + "data" +]
- Changed
scan_content7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
simulate_transaction7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
- Changed
token_security_audit11 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - changed
Output schema / properties / meta / additionalPropertiesPrevious value: -falseNew value: +{} - removed
Output schema / properties / meta / propertiesRemoved value: -{ - "cache": { - "additionalProperties": false, - "properties": { - "age_ms": { - "minimum": 0, - "type": "number" - }, - "hit": { - "type": "boolean" - } - }, - "required": [ - "hit", - "age_ms" - ], - "type": "object" - }, - "failed_sources": { - "items": { - "additionalProperties": false, - "properties": { - "reason": { - "type": "string" - }, - "source": { - "type": "string" - } - }, - "required": [ - "source", - "reason" - ], - "type": "object" - }, - "type": "array" - }, - "latency_ms": { - "minimum": 0, - "type": "number" - }, - "partial": { - "type": "boolean" - }, - "sources": { - "items": { - "type": "string" - }, - "type": "array" - } -} - added
Output schema / properties / meta / propertyNamesAdded value: +{ + "type": "string" +} - removed
Output schema / properties / meta / requiredRemoved value: -[ - "sources", - "latency_ms", - "partial", - "failed_sources", - "cache" -] - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "success", - "tool", - "timestamp", - "data", - "meta" -]New value: +[ + "success", + "tool", + "timestamp", + "data" +]
- Changed
verify_claim7 fields changed- added
Output schema / properties / agent_uxAdded value: +{ + "additionalProperties": false, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "meta": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "next": { + "items": {}, + "type": "array" + }, + "payment": { + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" + }, + "result": {}, + "status": { + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "result", + "error", + "meta", + "payment", + "next" + ], + "type": "object" +} - added
Output schema / properties / errorAdded value: +{ + "anyOf": [ + {}, + { + "type": "null" + } + ] +} - added
Output schema / properties / metaAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / nextAdded value: +{ + "items": {}, + "type": "array" +} - added
Output schema / properties / paymentAdded value: +{ + "additionalProperties": false, + "properties": { + "execution_status": { + "enum": [ + "not_started", + "succeeded", + "failed", + "unknown" + ], + "type": "string" + }, + "status": { + "enum": [ + "not_required", + "required", + "settled", + "failed", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "execution_status" + ], + "type": "object" +} - added
Output schema / properties / resultAdded value: +{} - added
Output schema / properties / statusAdded value: +{ + "enum": [ + "succeeded", + "failed", + "partial", + "outcome_unknown" + ], + "type": "string" +}
1 tool update
- Changed
route_tool5 fields changed- removed
Output schema / properties / recommended_next / additionalPropertiesRemoved value: -false - added
Output schema / properties / recommended_next / anyOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "price": { + "type": [ + "string", + "null" + ] + }, + "reason": { + "type": "string" + }, + "tool": { + "type": "string" + }, + "workflow_id": { + "type": "string" + } + }, + "required": [ + "tool", + "reason", + "price" + ], + "type": "object" + }, + { + "type": "null" + } +] - removed
Output schema / properties / recommended_next / propertiesRemoved value: -{ - "price": { - "type": [ - "string", - "null" - ] - }, - "reason": { - "type": "string" - }, - "tool": { - "type": "string" - } -} - removed
Output schema / properties / recommended_next / requiredRemoved value: -[ - "tool", - "reason", - "price" -] - removed
Output schema / properties / recommended_next / typeRemoved value: -"object"
5 tool updates
- Changed
check_package1 field changed- added
Output schema / properties / recommended_nextAdded value: +{ + "additionalProperties": false, + "properties": { + "price": { + "type": [ + "string", + "null" + ] + }, + "reason": { + "type": "string" + }, + "tool": { + "type": "string" + } + }, + "required": [ + "tool", + "reason", + "price" + ], + "type": "object" +}
- Changed
check_url1 field changed- added
Output schema / properties / recommended_nextAdded value: +{ + "additionalProperties": false, + "properties": { + "price": { + "type": [ + "string", + "null" + ] + }, + "reason": { + "type": "string" + }, + "tool": { + "type": "string" + } + }, + "required": [ + "tool", + "reason", + "price" + ], + "type": "object" +}
- Changed
extract_structured1 field changed- added
Output schema / properties / recommended_nextAdded value: +{ + "additionalProperties": false, + "properties": { + "price": { + "type": [ + "string", + "null" + ] + }, + "reason": { + "type": "string" + }, + "tool": { + "type": "string" + } + }, + "required": [ + "tool", + "reason", + "price" + ], + "type": "object" +}
- Added
preflight_action - Changed
route_tool7 fields changed- added
Output schema / properties / best_toolAdded value: +{ + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / confidenceAdded value: +{ + "type": "number" +} - added
Output schema / properties / expected_total_cost_usdAdded value: +{ + "type": [ + "number", + "null" + ] +} - added
Output schema / properties / next_best_toolAdded value: +{ + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / recommended_nextAdded value: +{ + "additionalProperties": false, + "properties": { + "price": { + "type": [ + "string", + "null" + ] + }, + "reason": { + "type": "string" + }, + "tool": { + "type": "string" + } + }, + "required": [ + "tool", + "reason", + "price" + ], + "type": "object" +} - added
Output schema / properties / recommended_workflowAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "estimated_total_price_usd": { + "type": "number" + }, + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "estimated_total_price_usd" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / whyAdded value: +{ + "items": { + "type": "string" + }, + "type": "array" +}
1 tool update
- Removed
estimate_trade_execution
4 tool updates
- Changed
check_change1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "baseline_available": { + "type": "boolean" + }, + "cached": { + "type": "boolean" + }, + "change_score": { + "type": "number" + }, + "change_type": { + "items": { + "type": "string" + }, + "type": "array" + }, + "changed": { + "type": "boolean" + }, + "checked_at": { + "type": "string" + }, + "current_hash": { + "type": "string" + }, + "data_age_seconds": { + "type": "number" + }, + "diff": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "added": { + "items": { + "type": "string" + }, + "type": "array" + }, + "removed": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "added", + "removed" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "previous_hash": { + "type": "string" + }, + "success": { + "const": true, + "type": "boolean" + }, + "summary": { + "additionalProperties": false, + "properties": { + "price_changed": { + "type": [ + "boolean", + "null" + ] + }, + "stock_changed": { + "type": [ + "boolean", + "null" + ] + } + }, + "required": [ + "price_changed", + "stock_changed" + ], + "type": "object" + } + }, + "required": [ + "success", + "changed", + "baseline_available", + "current_hash", + "previous_hash", + "change_score", + "change_type", + "diff", + "summary", + "cached", + "data_age_seconds", + "checked_at" + ], + "type": "object" +}
- Changed
extract_structured1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "cached": { + "type": "boolean" + }, + "confidence": { + "additionalProperties": false, + "properties": { + "overall": { + "type": "number" + } + }, + "required": [ + "overall" + ], + "type": "object" + }, + "data": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "data_age_seconds": { + "type": "number" + }, + "extracted_at": { + "type": "string" + }, + "final_url": { + "type": "string" + }, + "provenance": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "source_type": { + "type": "string" + } + }, + "required": [ + "field", + "source_type" + ], + "type": "object" + }, + "type": "array" + }, + "success": { + "const": true, + "type": "boolean" + }, + "url": { + "type": "string" + }, + "validation": { + "additionalProperties": false, + "properties": { + "coercions": { + "items": { + "type": "string" + }, + "type": "array" + }, + "missing_fields": { + "items": { + "type": "string" + }, + "type": "array" + }, + "schema_valid": { + "type": "boolean" + } + }, + "required": [ + "schema_valid", + "missing_fields", + "coercions" + ], + "type": "object" + } + }, + "required": [ + "success", + "url", + "final_url", + "data", + "validation", + "confidence", + "provenance", + "cached", + "data_age_seconds", + "extracted_at" + ], + "type": "object" +}
- Changed
get_live_quote1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "availability": { + "additionalProperties": false, + "properties": { + "in_stock": { + "type": [ + "boolean", + "null" + ] + }, + "quantity_available": { + "type": "null" + }, + "stock_status": { + "enum": [ + "in_stock", + "out_of_stock", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "in_stock", + "stock_status", + "quantity_available" + ], + "type": "object" + }, + "cached": { + "type": "boolean" + }, + "confidence": { + "enum": [ + "high", + "low" + ], + "type": "string" + }, + "data_age_seconds": { + "type": "number" + }, + "delivery": { + "additionalProperties": false, + "properties": { + "estimated_days_max": { + "type": "null" + }, + "estimated_days_min": { + "type": "null" + } + }, + "required": [ + "estimated_days_min", + "estimated_days_max" + ], + "type": "object" + }, + "fetched_at": { + "type": "string" + }, + "product": { + "additionalProperties": false, + "properties": { + "canonical_url": { + "type": "string" + }, + "title": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "title", + "canonical_url" + ], + "type": "object" + }, + "quote": { + "additionalProperties": false, + "properties": { + "currency": { + "type": [ + "string", + "null" + ] + }, + "fees": { + "type": "null" + }, + "landed_total": { + "type": "null" + }, + "quantity": { + "type": "number" + }, + "shipping": { + "type": "null" + }, + "subtotal": { + "type": "number" + }, + "tax": { + "type": "null" + }, + "unit_price": { + "type": "number" + } + }, + "required": [ + "currency", + "unit_price", + "quantity", + "subtotal", + "shipping", + "tax", + "fees", + "landed_total" + ], + "type": "object" + }, + "sources": { + "items": { + "type": "string" + }, + "type": "array" + }, + "success": { + "const": true, + "type": "boolean" + }, + "variant": { + "additionalProperties": false, + "properties": { + "color": { + "type": [ + "string", + "null" + ] + }, + "size": { + "type": [ + "string", + "null" + ] + }, + "verified": { + "type": [ + "boolean", + "null" + ] + } + }, + "required": [ + "size", + "color", + "verified" + ], + "type": "object" + } + }, + "required": [ + "success", + "product", + "quote", + "availability", + "variant", + "delivery", + "confidence", + "sources", + "cached", + "fetched_at", + "data_age_seconds" + ], + "type": "object" +}
- Changed
verify_claim1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "cached": { + "type": "boolean" + }, + "claim": { + "type": "string" + }, + "confidence": { + "type": "number" + }, + "conflicting_evidence": { + "items": { + "additionalProperties": false, + "properties": { + "published_at": { + "type": [ + "string", + "null" + ] + }, + "snippet": { + "type": "string" + }, + "source": { + "type": "string" + }, + "source_quality": { + "type": "string" + }, + "supports": { + "const": false, + "type": "boolean" + }, + "title": { + "type": "string" + } + }, + "required": [ + "source", + "title", + "published_at", + "source_quality", + "supports", + "snippet" + ], + "type": "object" + }, + "type": "array" + }, + "degraded": { + "type": "boolean" + }, + "evidence": { + "items": { + "additionalProperties": false, + "properties": { + "published_at": { + "type": [ + "string", + "null" + ] + }, + "snippet": { + "type": "string" + }, + "source": { + "type": "string" + }, + "source_quality": { + "type": "string" + }, + "supports": { + "const": true, + "type": "boolean" + }, + "title": { + "type": "string" + } + }, + "required": [ + "source", + "title", + "published_at", + "source_quality", + "supports", + "snippet" + ], + "type": "object" + }, + "type": "array" + }, + "freshness": { + "additionalProperties": false, + "properties": { + "age_days": { + "type": [ + "number", + "null" + ] + }, + "newest_source_at": { + "type": [ + "string", + "null" + ] + }, + "status": { + "enum": [ + "fresh", + "stale", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "status", + "newest_source_at", + "age_days" + ], + "type": "object" + }, + "sources": { + "items": { + "type": "string" + }, + "type": "array" + }, + "success": { + "const": true, + "type": "boolean" + }, + "verdict": { + "enum": [ + "supported", + "contradicted", + "mixed", + "insufficient_evidence", + "stale" + ], + "type": "string" + }, + "verified_at": { + "type": "string" + }, + "warnings": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "success", + "claim", + "verdict", + "confidence", + "freshness", + "evidence", + "conflicting_evidence", + "warnings", + "sources", + "degraded", + "cached", + "verified_at" + ], + "type": "object" +}
2 tool updates
- Changed
check_package1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "cached": { + "type": "boolean" + }, + "checked_at": { + "format": "date-time", + "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$", + "type": "string" + }, + "data_freshness_seconds": { + "minimum": 0, + "type": "number" + }, + "degraded": { + "type": "boolean" + }, + "dependencies_analyzed": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "dependency_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "dependency_findings": { + "items": { + "additionalProperties": false, + "properties": { + "known_malicious": { + "type": [ + "boolean", + "null" + ] + }, + "package": { + "type": "string" + }, + "risk": { + "enum": [ + "low", + "medium", + "high", + "critical", + "unknown" + ], + "type": "string" + }, + "version": { + "type": "string" + }, + "vulnerabilities": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "package", + "version", + "known_malicious", + "vulnerabilities", + "risk" + ], + "type": "object" + }, + "type": "array" + }, + "dependency_risk": { + "enum": [ + "low", + "medium", + "high", + "unknown" + ], + "type": "string" + }, + "deprecated": { + "type": "boolean" + }, + "ecosystem": { + "const": "npm", + "type": "string" + }, + "install_script_risk": { + "enum": [ + "low", + "medium", + "high", + "critical", + "unknown" + ], + "type": "string" + }, + "known_malicious": { + "type": [ + "boolean", + "null" + ] + }, + "known_vulnerabilities": { + "items": { + "additionalProperties": false, + "properties": { + "affected": { + "const": true, + "type": "boolean" + }, + "fixed_version": { + "type": [ + "string", + "null" + ] + }, + "id": { + "type": "string" + }, + "severity": { + "enum": [ + "low", + "medium", + "high", + "critical", + "unknown" + ], + "type": "string" + }, + "summary": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "id", + "summary", + "severity", + "affected", + "fixed_version" + ], + "type": "object" + }, + "type": "array" + }, + "maintainer_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "maintainer_risk": { + "enum": [ + "low", + "medium", + "high", + "unknown" + ], + "type": "string" + }, + "malicious_confidence": { + "anyOf": [ + { + "enum": [ + "low", + "medium", + "high" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "new_package": { + "type": [ + "boolean", + "null" + ] + }, + "package": { + "type": "string" + }, + "package_age_days": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "recommendation": { + "enum": [ + "allow", + "caution", + "block" + ], + "type": "string" + }, + "reputation": { + "enum": [ + "good", + "neutral", + "suspicious", + "malicious", + "unknown" + ], + "type": "string" + }, + "requested_version": { + "type": [ + "string", + "null" + ] + }, + "resolved_version": { + "type": "string" + }, + "risk_confidence": { + "enum": [ + "low", + "medium", + "high" + ], + "type": "string" + }, + "risk_level": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "type": "string" + }, + "risk_score": { + "maximum": 100, + "minimum": 0, + "type": "integer" + }, + "similar_to": { + "type": [ + "string", + "null" + ] + }, + "similarity_score": { + "anyOf": [ + { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ] + }, + "sources": { + "items": { + "type": "string" + }, + "type": "array" + }, + "success": { + "const": true, + "type": "boolean" + }, + "suspicious_scripts": { + "items": { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "signals": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "name", + "signals" + ], + "type": "object" + }, + "type": "array" + }, + "typosquat_risk": { + "enum": [ + "low", + "medium", + "high", + "critical", + "unknown" + ], + "type": "string" + }, + "warnings": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "success", + "ecosystem", + "package", + "requested_version", + "resolved_version", + "risk_score", + "risk_level", + "risk_confidence", + "recommendation", + "known_malicious", + "malicious_confidence", + "known_vulnerabilities", + "typosquat_risk", + "similar_to", + "similarity_score", + "install_script_risk", + "suspicious_scripts", + "dependency_risk", + "dependency_count", + "dependencies_analyzed", + "dependency_findings", + "maintainer_risk", + "maintainer_count", + "reputation", + "package_age_days", + "new_package", + "deprecated", + "warnings", + "sources", + "degraded", + "cached", + "checked_at", + "data_freshness_seconds" + ], + "type": "object" +}
- Changed
check_url1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "cached": { + "type": "boolean" + }, + "checked_at": { + "type": "string" + }, + "degraded": { + "type": "boolean" + }, + "domain_age_risk": { + "const": "unknown", + "type": "string" + }, + "final_url": { + "type": [ + "string", + "null" + ] + }, + "https": { + "type": "boolean" + }, + "malware": { + "type": "boolean" + }, + "normalized_url": { + "type": "string" + }, + "phishing": { + "type": "boolean" + }, + "recommendation": { + "enum": [ + "allow", + "caution", + "block" + ], + "type": "string" + }, + "redirect_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "risk_level": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "type": "string" + }, + "risk_score": { + "maximum": 100, + "minimum": 0, + "type": "integer" + }, + "safe": { + "type": "boolean" + }, + "sources": { + "items": { + "type": "string" + }, + "type": "array" + }, + "success": { + "const": true, + "type": "boolean" + }, + "suspicious_domain": { + "type": "boolean" + }, + "suspicious_redirect": { + "type": "boolean" + }, + "threats": { + "items": { + "type": "string" + }, + "type": "array" + }, + "warnings": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "success", + "safe", + "risk_score", + "risk_level", + "recommendation", + "normalized_url", + "final_url", + "redirect_count", + "https", + "domain_age_risk", + "phishing", + "malware", + "suspicious_redirect", + "suspicious_domain", + "threats", + "warnings", + "sources", + "cached", + "degraded", + "checked_at" + ], + "type": "object" +}
20 tool updates
- First observed
analyze_whale_activity - First observed
backtest_strategy - First observed
check_change - First observed
check_package - First observed
check_url - First observed
check_wallet - First observed
estimate_trade_execution - First observed
extract_structured - First observed
get_live_quote - First observed
invoice_preflight - First observed
invoice_preflight_10_pages - First observed
invoice_preflight_50_pages - First observed
invoice_preflight_quote - First observed
mcp_server_inspect - First observed
route_tool - First observed
scan_arbitrage - First observed
scan_content - First observed
simulate_transaction - First observed
token_security_audit - First observed
verify_claim
Related MCP Connectors
DeFi safety layer for AI agents: wallet safety, token risk, tx decode/simulate. 20 tools.
Agentic AI runtime: persistent memory, vault, autonomous agents, deep research, DeFi execution.
Pay-per-call (x402/USDC-Base) web + crypto data tools for AI agents: audit, extract, crypto, DeFi.
Agent-native security, trust, reliability, data and procurement tools for AI workflows.
Related MCP Servers
- AlicenseCqualityDmaintenanceEnables AI agents to interact with cryptocurrency ecosystems through wallet management, trading operations (swaps, DCA, limit orders), staking, and multi-chain support starting with Solana.37GPL 3.0
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to perform complex crypto operations like cross-chain routing, contract decoding, portfolio management, and anti-rug security checks, returning unsigned transactions for safe signing by the agent.MIT
- AlicenseAqualityCmaintenance7-layer Solana safety oracle and security infrastructure for AI agents.1117 npm2MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.