Machine-native tools for autonomous agents with free routing and x402 USDC pay-per-call.
Scored across 5 tools
Each tool has a distinct purpose: preflight (payment/recipient safety), market_execution_intel (swap quote analysis), signal_layer_catalog and signal_layer_router (discovery/navigation), and structured_extract (webpage extraction). The only mild overlap is between signal_layer_catalog and signal_layer_router, but descriptions explicitly differentiate them ('not a task router' / 'not a full catalog').
All names use snake_case, which is consistent throughout. Two tools carry a signal_layer_ prefix while the others (agent_preflight, market_execution_intel, structured_extract) do not, a minor prefix inconsistency but still readable and predictable.
Five tools is well within a healthy range and each earns its place: two paid action primitives, one extraction tool, plus a free catalog and router for discovery. The set feels tightly scoped to the x402 signal-layer domain with no filler.
The surface covers the key pre-action decision points (payments, swaps, extraction) plus discovery via catalog and router, which is coherent for a signaling service. There is no obvious create/update/delete lifecycle to fill, though the domain is fairly narrow and lacks any post-action verification or feedback tool.
Inspects public x402 terms or a Base recipient and returns decision.verdict, score, confidence, payment observations, evidence, warnings, freshness and nextActions. It identifies observable mismatches but cannot guarantee safety or authorize spending. Before paying, transferring to, or interacting with an unfamiliar machine resource, x402 endpoint, recipient, or Base address. Do NOT use when: You only need market execution conditions or webpage extraction. Price: $0.01 USDC per call via x402 V2 with separately authorized payment. If unsure, use the free signal_layer_router.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | pay | |
| target | Yes | ||
| routingId | No | ||
| maxPriceUsd | No | ||
| expectedNetwork | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| meta | No | |
| tool | No | |
| status | No | |
| decision | No | |
| evidence | No | |
| warnings | No | |
| freshness | No | |
| requestId | No | |
| nextActions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the description must add value beyond that. It does: it discloses the $0.01 USDC x402 V2 cost model with separately authorized payment, and states the tool's limits ('identifies observable mismatches but cannot guarantee safety or authorize spending'). It stops short of any latency, rate-limit, or freshness-of-evidence detail beyond the returned 'freshness' field name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The paragraph is front-loaded with purpose, then conditions, then cost, then a fallback — a sensible order with no filler prose. The one weak sentence is the enumerated return-field list, which duplicates what the existing output schema already declares and could be cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema is present, so not explaining return values is acceptable, yet the description still names the key verdict fields for quick triage. Combined with explicit when/when-not guidance, cost disclosure, and a fallback route, an agent has enough to decide and call it; the missing parameter-level semantics is the only substantive hole.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across five parameters, so the description carries the full burden and does not meet it. It never explains what 'target' accepts (URL vs. Base address), what 'routingId' is for, how 'maxPriceUsd' gates the $0.01 charge, or what 'expectedNetwork'/'intent' change in behavior. The 'intent' enum values are only inferable from the usage sentence, not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Inspects public x402 terms or a Base recipient') and enumerates the decision payload it returns (verdict, score, confidence, evidence, warnings, freshness, nextActions). It is immediately distinguishable from market_execution_intel and structured_extract, which it explicitly contrasts itself against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the trigger condition precisely ('Before paying, transferring to, or interacting with an unfamiliar machine resource, x402 endpoint, recipient, or Base address'), gives explicit exclusions ('Do NOT use when: You only need market execution conditions or webpage extraction'), and routes uncertain callers to a named free alternative, signal_layer_router.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes current Base ERC-20 exact-in swap quotes without executing trades. Returns quote-derived buy amount, network-cost bps, size-impact estimate, decision, evidence, warnings and freshness. Quotes can change; no signing or investment advice. Before an exact-in ERC-20 swap on Base when current quote-derived execution conditions, network cost, and size sensitivity matter. Do NOT use when: You need generic historical prices, personalized investment advice, or a signed transaction. Price: $0.03 USDC per call via x402 V2 with separately authorized payment. If unsure, use the free signal_layer_router.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| buyToken | Yes | ||
| routingId | No | ||
| sellToken | Yes | ||
| buyTokenDecimals | Yes | ||
| sellTokenDecimals | Yes |
| Name | Required | Description |
|---|---|---|
| data | No | |
| meta | No | |
| tool | No | |
| status | No | |
| decision | No | |
| evidence | No | |
| warnings | No | |
| freshness | No | |
| requestId | No | |
| nextActions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the response payload (buy amount, network-cost bps, size-impact estimate, decision, evidence, warnings, freshness), the staleness caveat ('Quotes can change'), the absence of signing/advice, and the monetization model ($0.03 USDC per call via x402 V2 with separately authorized payment). That cost/auth/freshness context is exactly what annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then use conditions, exclusions, pricing, and a fallback, each in a clause that earns its place. Dense but with zero filler and a clear priority order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return-value detail is not needed, and the description covers purpose, usage, cost, staleness, and safety. The one real gap is per-parameter semantics for the 6-param input, which matters for a swap tool with required token addresses and decimals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and 6 parameters (5 required) are present, so the description carries the full burden — but it only implies that 'amount' is the exact-in sell amount and never explains routingId, the two token addresses, or the decimals fields. Parameter meaning is largely left to the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Analyzes current Base ERC-20 exact-in swap quotes without executing trades' — and pins the scope by explicitly ruling out execution. An agent can distinguish it from signal_layer_router and the other siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('Before an exact-in ERC-20 swap on Base when... execution conditions, network cost, and size sensitivity matter'), explicit exclusions ('Do NOT use when: generic historical prices, personalized investment advice, or a signed transaction'), and names an alternative ('use the free signal_layer_router'). This is full when/when-not/alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free inventory returning service, version, defaultEntryPoint and the four actionable primitives with capabilities and prices; the catalog tool itself is omitted. This is not a task router. If the correct tool is uncertain, prefer signal_layer_router.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tools | No | |
| service | No | |
| version | No | |
| defaultEntryPoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is handled. The description adds genuinely new context: the call is free, and the catalog tool itself is omitted from the returned list — a non-obvious output quirk. It does not mention auth or rate limits, so it falls just 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the inventory contents, then the two routing sentences. The first sentence is dense and slightly run-on, but every clause carries information (fields returned, prices, self-omission) and nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description helpfully previews the key ones. With annotations covering safety and no parameters to document, there is no gap an agent would need filled before calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline of 4 applies; there is no parameter semantics to explain and the description correctly spends no space on them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (free inventory/catalog) and enumerates exactly what it returns: service, version, defaultEntryPoint, and the four actionable primitives with capabilities and prices. It explicitly separates itself from the sibling signal_layer_router ('This is not a task router'), so an agent can choose between them 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit negative condition ('not a task router') and names the alternative to use when the right tool is uncertain ('prefer signal_layer_router'). That is a concrete when-not plus routing rule, not implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free deterministic task-to-tool router, not a full catalog. Returns match, recommendedTool, routingConfidence, reason, missingRequiredInputs and readyToCall HTTP/MCP arguments for the best eligible primitive, or an explicit no_match when nothing fits. It may recommend a paid tool but never authorizes payment; check the live x402 challenge and obtain user approval before spending.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| amount | No | ||
| fields | No | ||
| target | No | ||
| network | No | ||
| buyToken | No | ||
| sellToken | No | ||
| maxPriceUsd | No | ||
| buyTokenDecimals | No | ||
| sellTokenDecimals | No |
| Name | Required | Description |
|---|---|---|
| match | No | |
| reason | No | |
| readyToCall | No | |
| recommendedTool | No | |
| routingConfidence | No | |
| missingRequiredInputs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds the important operational trait that a paid recommendation is never an authorization, plus the requirement to check the live x402 challenge and get user approval. Listing the response fields is partly redundant given an output schema exists, but the payment-authorization disclosure is genuinely beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with no filler; the core identity leads, followed by outputs and the payment caveat. Enumerating the return fields is slightly redundant with the output schema, but it costs little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema means return values need not be explained, and annotations carry the safety profile, so the behavioral story is adequate. However, for a 10-parameter tool with no schema descriptions, the total absence of parameter guidance leaves a real gap in how to actually invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 10 parameters, so the description carries the full burden — and it explains none of them. task, amount, fields, target, network, buyToken/sellToken, maxPriceUsd and the decimals are all undefined in both schema and description, leaving the agent unable to know how to populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('task-to-tool router') and immediately scopes it ('Free deterministic', 'not a full catalog'), which cleanly separates it from the sibling signal_layer_catalog. An agent can identify the tool's role 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'not a full catalog' framing implies catalog browsing is a different tool, and the description gives concrete operating conditions: it returns an explicit no_match when nothing fits, and may recommend a paid tool without authorizing payment. It stops short of naming signal_layer_catalog as the alternative explicitly, so it is clear context rather than full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extracts requested fields from public webpages, returning structured values, field-level evidence, confidence, freshness and partial-result warnings. Missing facts remain null. When requested facts exist on a public webpage but compact structured JSON is needed instead of browsing and parsing the page. Do NOT use when: The source is already structured or the task is generic web search. Price: $0.02 USDC via x402. Use signal_layer_router for free tool selection.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| fields | Yes | ||
| routingId | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| meta | No | |
| tool | No | |
| status | No | |
| decision | No | |
| evidence | No | |
| warnings | No | |
| freshness | No | |
| requestId | No | |
| nextActions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description goes beyond them by disclosing a paid cost ($0.02 USDC via x402), null-on-missing behavior, and partial-result warnings, which materially affect invocation decisions. It stops short of explaining payment/auth mechanics or latency behavior, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short and the core purpose plus exclusions are front-loaded before pricing and routing details. The 'When requested facts exist...' sentence is grammatically clipped and slightly awkward, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so not explaining return values is acceptable, and annotations cover the safety profile. What is present (cost, null semantics, exclusions, fallback router) is enough to call the tool correctly; only routingId semantics and any payment/auth prerequisite remain unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning, and it only implicitly covers 'url' (public webpages) and 'fields' (requested fields). The third parameter, routingId, is never explained, and there is no hint about the field-format or count limits (1-20 fields, 120 chars) that the schema enforces without description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('extracts requested fields from public webpages') and names the return shape (structured values, evidence, confidence, freshness, partial-result warnings). It also explicitly separates itself from generic web search and from already-structured sources, so an agent can distinguish it from siblings like signal_layer_router.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when ('requested facts exist on a public webpage but compact structured JSON is needed instead of browsing and parsing the page') and explicit when-not ('source is already structured or the task is generic web search'). It also names an alternative path (signal_layer_router for free tool selection), leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
agent_preflight1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "data": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "decision": {
+ "additionalProperties": {},
+ "properties": {
+ "confidence": {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ "score": {
+ "type": "number"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "evidence": {
+ "items": {},
+ "type": "array"
+ },
+ "freshness": {
+ "additionalProperties": {},
+ "properties": {
+ "checkedAt": {
+ "type": "string"
+ },
+ "maxAgeSeconds": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "meta": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "nextActions": {
+ "items": {},
+ "type": "array"
+ },
+ "requestId": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "warnings": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "type": "object"
+}market_execution_intel1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "data": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "decision": {
+ "additionalProperties": {},
+ "properties": {
+ "confidence": {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ "score": {
+ "type": "number"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "evidence": {
+ "items": {},
+ "type": "array"
+ },
+ "freshness": {
+ "additionalProperties": {},
+ "properties": {
+ "checkedAt": {
+ "type": "string"
+ },
+ "maxAgeSeconds": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "meta": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "nextActions": {
+ "items": {},
+ "type": "array"
+ },
+ "requestId": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "warnings": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "type": "object"
+}signal_layer_catalog1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "defaultEntryPoint": {
+ "type": "string"
+ },
+ "service": {
+ "type": "string"
+ },
+ "tools": {
+ "items": {},
+ "type": "array"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}signal_layer_router1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "match": {
+ "type": "boolean"
+ },
+ "missingRequiredInputs": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "readyToCall": {},
+ "reason": {
+ "type": "string"
+ },
+ "recommendedTool": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "routingConfidence": {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "type": "object"
+}structured_extract1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "data": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "decision": {
+ "additionalProperties": {},
+ "properties": {
+ "confidence": {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ "score": {
+ "type": "number"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "evidence": {
+ "items": {},
+ "type": "array"
+ },
+ "freshness": {
+ "additionalProperties": {},
+ "properties": {
+ "checkedAt": {
+ "type": "string"
+ },
+ "maxAgeSeconds": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "meta": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "nextActions": {
+ "items": {},
+ "type": "array"
+ },
+ "requestId": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "warnings": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "type": "object"
+}agent_preflightmarket_execution_intelsignal_layer_catalogsignal_layer_routerstructured_extractPay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Pay-per-call agent tools over x402 (USDC on Base) — no signup or API key.
63 pay-per-call tools for agents: vision, text, data, web, blockchain. USDC on Base via x402.
Pay-per-use tool API for AI agents. Free tier, x402 USDC micropayments, or API key.
Add one secure layer between your agents and this server.