Skip to main content
Glama

pronto-stream

by io.github.nmxmxh
OverviewDiscussionsAdmin

Server Details

Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.

Ownership verified
Status
Healthy
Uptime
99.7% over 41 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 15 tools

Disambiguation5/5

Every tool targets a clearly distinct operation, and the descriptions actively cross-reference the tools they compete with. get_signal, get_latest_signals, search_signals, scope_signals, get_related_signals, and get_fused_signal are carefully separated, and get_facet_manifest is explicitly distinguished from list_facets.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun convention, with get_ used for retrievals and state lookups and list_ for catalog enumeration. The pattern is predictable enough that an agent can infer the shape of a tool from its name.

Tool Count5/5

Fifteen tools is at the upper end of the ideal range but each one earns its place: roughly ten cover signal reading, searching, faceting, and derived products, and five cover the identity, plan, and payment lifecycle. No tool is redundant, and the count matches the stated scope of the server.

Completeness5/5

The tool surface covers the full read/compute workflow for the signal wire, including single-row retrieval, filtered views, search, related links, facet discovery, and fused products. The commercial lifecycle is also complete: register_agent creates an identity, get_plans/open_payment/settle_payment handle purchasing, and get_billing_profile reports ongoing entitlement.

Available Tools

15 tools
get_billing_profileA
Read-onlyIdempotent
Inspect

Report who you are resolved as and what your plan grants: the agent identity behind this call, the funded account it acts for, the plan, the per-minute call ceiling, the per-response row budget, and which indicator set you may compute. Returns a CWF BILL line, a CREDIT line when a metering balance exists, and a NOTE line naming your state and its remedy when you are not entitled — unauthenticated, or registered but not yet claimed by a funded account. If unauthenticated, call register_agent next: it creates an identity with no human present. From there you can either buy your own plan with open_payment, or hand the claim code it returns to whoever holds your budget.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description goes well beyond them by disclosing the exact line types returned (BILL, CREDIT, NOTE), state-dependent behavior for unauthenticated/unclaimed callers, and the remedy path.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then structured into output-line details and follow-up guidance. Each sentence adds distinct operational information with no filler.

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?

For a zero-parameter tool with no output schema, the description is self-sufficient: it covers the report contents, conditional return lines, entitlement states, and next steps. Nothing an agent needs to call it correctly appears to be missing.

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?

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds value by explaining what the report contains, compensating for the absence of any parameter documentation.

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 uses a specific verb ('Report') and a clear resource (the agent's resolved identity, funded account, plan, and entitlements). It differentiates from siblings like get_plans by focusing on the caller's resolved identity and current grant, not on available plans.

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?

Provides clear context and explicit conditional branching ('If unauthenticated, call register_agent next') and describes when a NOTE is returned. It does not explicitly compare against sibling alternatives like get_plans, but the described next steps are actionable.

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

get_facet_manifestA
Read-onlyIdempotent
Inspect

Read the shape of the wire in one small response: a two-level tree of domain and the topics under it, each with a signal count, ranked so the busiest lead. This is the map to read first — read it once, choose a scope offline, then make one precise call to scope_signals or search_signals instead of guessing a filter.

It covers two facet keys only, domain and topic, and truncates the topic tail under each domain, so it stays short enough to read in full. When you need the rest of the vocabulary — the languages, countries, providers, severities, coverages and place ids you can also filter by, exhaustively and with counts — call list_facets instead. The manifest states structure, not signal content.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses the two-key limitation, the truncation behavior ('truncates the topic tail under each domain'), the ranking order, and a negative scope ('The manifest states structure, not signal content'). These are exactly the behavioral traits an agent would be surprised by, and they are not in the structured hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Each of the five sentences earns its place: purpose, usage workflow, limitation, alternative routing, and negative scope. The core purpose is front-loaded in the first sentence, and the detailed list of alternative facet keys is concrete rather than padding.

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?

For a zero-parameter read tool with no output schema, the description compensates well: it describes the response shape (two-level tree, signal counts, ranking), the truncation limitation, and what the response is not. The rich annotations carry the safety profile, so nothing an agent needs to call it correctly is missing.

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?

Zero parameters with 100% schema coverage, so the baseline is 4. The description correctly implies no inputs are needed and has no parameter semantics to clarify; nothing is missing here.

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: 'Read the shape of the wire... a two-level tree of domain and the topics under it, each with a signal count, ranked so the busiest lead.' It explicitly contrasts with list_facets (the exhaustive version), so an agent can distinguish them without inspecting 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 an explicit workflow: 'read it once, choose a scope offline, then make one precise call to scope_signals or search_signals instead of guessing a filter.' It also names the exact exclusion case and alternative: 'When you need the rest of the vocabulary... call list_facets instead.' 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.

get_fused_signalA
Read-onlyIdempotent
Inspect

Compute derived intelligence products from the live wire. Each result states the method it implements and cites the signals it was computed from; a source row with no citation is labelled as such.

Pick one from the product enum, or omit it for everything the current window supports. A product absent from the output has no live inputs right now — list_fusion_products states the whole catalogue and does not depend on the window.

Cross-source products exist only because independent publishers are time-aligned on one wire; no upstream API emits them. seismic_solution_consensus is the sharpest case: several national agencies locate one earthquake and it reports how far apart their solutions are, in magnitude, depth and true three-dimensional hypocentre. Read it before acting on any single magnitude — agencies routinely differ by half a unit while an event is still being located, which is a factor of five in energy.

recession_risk_12m and sahm_recession_indicator disagree on purpose: the first forecasts, the second says a downturn has probably already begun. Read both.

Some indicators are included from the Team plan. A response that withheld one says so on a NOTE line naming what and why, so an absence is never mistaken for a quiet wire.

ParametersJSON Schema
NameRequiredDescriptionDefault
productNoOne product to compute. Omit for every product the current window supports.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover readOnly, idempotent, and openWorld. The description adds significant behavioral context: each result states its method and citations, source rows without citations are labelled, withheld products are announced on a NOTE line, and cross-source products exist only due to time-alignment. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and multi-paragraph, with a detailed paragraph on seismic_solution_consensus. While informative, it could be more concise. The structure is logical but not front-loaded; the key product-selection guidance appears later. Every sentence has value but the overall length is somewhat excessive.

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?

For a tool with 35 enum options and no output schema, the description covers output format, absence handling, plan restrictions, and provides product examples. It lacks explicit mention of pagination or rate limits, but those are likely covered by annotations or are not critical for a read-only compute tool. Overall, quite complete.

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?

The schema description already explains the product parameter ('One product to compute. Omit for every product...'). The description reinforces this and adds value by explaining specific enum semantics (e.g., recession_risk_12m vs sahm_recession_indicator) and clarifying that absent products mean no live inputs. This goes beyond the schema's generic 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 'Compute derived intelligence products' and resource 'live wire', clearly distinguishing from the sibling list_fusion_products by contrasting compute vs catalogue. The purpose is unambiguous and not a tautology.

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?

Explicitly contrasts with list_fusion_products for the catalogue and gives conditional usage: pick a product or omit for all. Provides product-specific advice (e.g., read seismic_solution_consensus before acting, read both recession indicators). Does not explicitly say when to use get_signal, but that is not required for this tool.

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

get_latest_signalsA
Read-onlyIdempotent
Inspect

Fetch the most recent live signals from the wire in token-efficient CWF format, optionally filtered to one collection.

The all-collections view is diversified: no provider may exceed its share of the page, no collection may take more than half of it, and what overflows is named on a note line rather than dropped silently — so a burst of tickers cannot crowd out earthquakes. Pass collection to read one collection at full depth.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of signals to return (default 20, max 100)
cursorNoPage token from META cursor: of the previous response. Omit for the first page.
relateNoAlso return the link graph over the rows in this response, as REL and CLUSTER lines, so repeats of one story collapse into one line without a second call. Off by default.
collectionNoSignal collection to filter by, e.g. climate, sentiment, security, health, cosmic, energy, macro, market, crypto, knowledge, prediction, logistics. Omit for all collections.

TDQS

A3.6/5.0
Behavior4/5

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

The description discloses behavioral traits beyond the annotations: the all-collections view is diversified with provider/cap limits, overflow is named on a note line rather than dropped, and passing collection yields full depth. These details are not in the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) and meaningfully inform caller expectations about response composition and tradeoffs.

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 purpose is front-loaded in the first sentence, and the second paragraph explains important behavioral constraints. The prose is reasonably compact for the behavioral detail it conveys, though the second paragraph could be tightened without losing meaning.

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?

There is no output schema, so the description should compensate by explaining what the response looks like. It names 'CWF format' but does not expand the acronym or describe the line structure, pagination via META cursor beyond the schema, or error behavior. The diversification explanation helps, but gaps remain for an agent to fully predict the response shape.

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 100%, so the baseline is 3. The description adds a small nuance for the collection parameter (full depth when passed) but says nothing about limit, cursor, or relate beyond what the schema already provides. The added value is marginal and confined to one parameter.

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 clearly states the tool fetches the most recent live signals from the wire in a specific token-efficient CWF format, optionally filtered by collection. This distinguishes it from sibling tools like get_signal (single signal), get_related_signals (related signals), and search_signals (search), while also conveying the unique all-collections diversification behavior.

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 description provides guidance on choosing between all collections vs. a single collection (full depth) but does not explicitly say when to use this tool versus its siblings. No alternative tools are named, and there is no when-not-to-use guidance, so the agent must infer selection criteria from tool names alone.

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

get_plansA
Read-onlyIdempotent
Inspect

List what can be bought — call credits, day and week passes, and plans — what each costs, and what each raises — the call ceiling, the row budget, and whether the commercial indicator set is included. Machine-readable, so you can decide what to do about a refusal without parsing a pricing page: buy the plan yourself with open_payment, or escalate to whoever holds your budget. Returns a CREDITS line, one CWF PLAN line per plan with its pass and period prices, and a SETTLE line naming the asset, network and address to pay.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds genuine value beyond them: it discloses the machine-readable output format, the three line types (CREDITS, CWF PLAN, SETTLE), and that a payment destination is provided. This is useful behavioral context not present in the annotations.

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 dense and front-loaded with the core purpose, followed by the use case and return structure. Every sentence carries functional information, though it is longer than strictly minimal.

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?

With no output schema, the description compensates by specifying the returned lines and their meaning. Combined with the use case, the buy-or-escalate guidance, and the payment details, the agent has everything needed to invoke and interpret the tool.

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?

The tool has zero parameters and schema coverage is 100%, so the description has no parameter semantics to convey. Baseline 4 is appropriate for a parameterless tool.

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 clearly states a specific verb and resource ('List what can be bought') and enumerates the plan types and their attributes. It is easy for an agent to distinguish this catalog tool from payment or settlement siblings like open_payment and settle_payment.

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 description explicitly frames the tool's use in a decision workflow: after a refusal, use this to get machine-readable pricing, then either buy via open_payment or escalate. It names the relevant alternative action, though it does not enumerate exclusions among the other get/list siblings.

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

get_signalA
Read-onlyIdempotent
Inspect

Fetch one signal by its id, when you already know which one you want. Every other read tool returns a set and bounds it, so re-reading a single row through them means re-running a query and hoping the row survives the row budget a second time; this returns that row and nothing else.

Takes either the full correlation id or the short handle in column 2 of any CWF row — cite the handle, pass it back here. The live window turns over in about two minutes, so a signal read several calls ago may have aged out; the error says which of the two happened rather than leaving you to look for a typo. To find signals rather than re-read one, use search_signals or scope_signals; to reach the ones about the same subject, use get_related_signals.

ParametersJSON Schema
NameRequiredDescriptionDefault
correlation_idYesId of the signal to fetch. Accepts either the full correlation id or the short handle in column 2 of any CWF v3 row.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: the live window turnover (~2 minutes) and the error message behavior that distinguishes aging out from typos. It also clarifies the tool returns only that row. This goes beyond annotations, though it does not detail the return format or any rate limits, which are not covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a compact paragraph with no filler. The purpose is front-loaded, and every sentence contributes: purpose, comparison to siblings, parameter guidance, behavioral note, and alternative routing. No redundancy.

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?

Given the tool's low complexity (one parameter) and the rich annotations covering safety, the description is largely complete. It explains the single-row return, the time-window behavior, and error messages. The only minor gap is that it does not explicitly state the return format or object structure, but since there is no output schema, a more explicit statement would be helpful. Still, the description covers the critical operational aspects.

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 parameter correlation_id is already fully described in the schema, including accepting the full id or short handle. The description reiterates this and adds a usage hint ('cite the handle, pass it back here') but does not introduce new semantic information beyond the schema. Baseline 3 is appropriate.

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 clearly states the verb ('Fetch') and resource ('one signal by its id'), and immediately adds the condition 'when you already know which one you want.' It distinguishes from siblings by explaining that other read tools return sets and bound them, while this returns a single row. This is specific and non-tautological.

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 provides when to use (when you already know the id) and when not to, naming alternatives: 'To find signals rather than re-read one, use search_signals or scope_signals; to reach the ones about the same subject, use get_related_signals.' This is direct routing guidance with no ambiguity.

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

list_data_sourcesA
Read-onlyIdempotent
Inspect

List the data-source endpoints feeding the wire, with provider, signal type, country, cadence, and license. Returns one SRC line per source.

ParametersJSON Schema
NameRequiredDescriptionDefault
signal_typeNoFilter by signal type, e.g. climate, security, health. Omit for all sources.

TDQS

A4/5.0
Behavior4/5

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

Annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond annotations by specifying the output shape: 'Returns one SRC line per source' and enumerating the fields included. No contradictions exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently state the resource, the fields, and the output format. There is no redundant padding, and the core action is front-loaded.

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?

For a simple list tool with one optional parameter and no output schema, the description covers the returned fields and line format. It is nearly complete, though a brief note on the optional filtering behavior in the description itself would remove reliance on 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?

The schema has 100% description coverage for the only parameter, signal_type, including an example and an 'omit for all sources' note. The description adds no parameter syntax or format details beyond the schema, so the baseline of 3 is appropriate.

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 verb and resource: 'List the data-source endpoints feeding the wire,' and enumerates the returned attributes. This clearly distinguishes it from sibling tools like search_signals or list_facets, which concern signals and facets rather than data-source endpoints.

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 implies the tool lists all data sources, with the optional signal_type filter visible in the schema, but it does not explicitly state when to choose this over alternatives or when not to use it. Usage context is clear at a basic level, yet there are no exclusions or comparisons to siblings.

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

list_facetsA
Read-onlyIdempotent
Inspect

List the full filter vocabulary: every facet value currently on the wire, across every key — lang, country, region, domain, topic, severity, provider, coverage and place — as one flat list with a signal count each, and a human-readable label for place ids. Every value it returns is a value scope_signals will accept right now.

This is the exhaustive listing and it is long, running to a hundred-odd values on a busy wire. If all you need is to pick a domain and a topic, get_facet_manifest answers that in a fraction of the tokens; come here when you need a value the manifest does not carry, or the counts behind one. Place facets are gazetteer ids; filter them by name with scope_signals rather than by the raw id.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark the tool as read-only, open-world, idempotent, and non-destructive. The description adds valuable behavior beyond that: output can be long (hundred-odd values on a busy wire), every returned value is currently accepted by scope_signals, and place facets are gazetteer ids. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and uses a second paragraph for usage guidance. Each sentence adds value—warning about length, routing to get_facet_manifest, and explaining place id handling—though it is somewhat longer than strictly necessary.

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?

For a zero-parameter tool with no output schema, the description covers result shape (flat list, counts, labels), the scope of keys, token-cost warning, and integration with scope_signals. This fully equips an agent to call it correctly without additional inference.

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?

There are zero parameters and schema coverage is 100% (empty object), so the baseline is 4. The description adds no parameter meaning because none exist, and instead focuses on output semantics, which is appropriate.

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 explicitly states the tool lists the full filter vocabulary and enumerates all keys (lang, country, region, domain, topic, severity, provider, coverage, place). It also specifies the output shape (flat list with signal counts and human-readable labels for place ids), which clearly separates it from siblings like get_facet_manifest.

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?

The description gives explicit routing guidance: use get_facet_manifest when only a domain and topic are needed, and list_facets when needing values not in the manifest or counts behind them. It also instructs to use scope_signals for filtering place facets by name instead of raw ids.

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

list_fusion_productsA
Read-onlyIdempotent
Inspect

List every derived intelligence product pronto can compute, with the published index or model each one implements, the signal collections it consumes, and whether it needs a plan. Read this to find out whether pronto computes the thing you need, then call get_fused_signal to actually compute it.

The two tools answer different questions and the difference matters. This one states the catalogue, reads no signals, and returns the same answer on a wire that is still warming up. get_fused_signal states what the current window can support, so a product missing from its output means the inputs are not flowing right now, not that the product does not exist.

Each row states its attribution: "published" is a faithful implementation of an external, citable index, "composed" is authoritative published inputs combined by a rule that is pronto's own and disclosed in the method. Rows marked plan:team are the commercial macro and energy models; when your plan does not include them a NOTE line names them, so a gated product is never mistaken for a missing one.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive, but the description adds important behavior: it 'reads no signals' and 'returns the same answer on a wire that is still warming up,' indicating the output is static and not dependent on current input flow. It also discloses the attribution model and gating behavior, providing context beyond the annotations. No contradiction.

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 dense and front-loaded with the core purpose, then covers differentiation and attribution. It is well-structured but slightly wordy (e.g., 'on a wire that is still warming up' is figurative and not essential). Overall, every sentence earns its place, but a more streamlined phrasing would improve conciseness.

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?

Given there are no parameters and no output schema, the description fully explains what the tool returns, how it differs from get_fused_signal, and how to interpret gated products. An agent has everything needed to decide whether and when to call it, and what to expect in response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the schema carries no semantic load, and the baseline for 0 params is 4. The description goes beyond the baseline by describing what the returned list contains (index/model, signal collections, plan flag), which helps an agent interpret the output even without a formal output 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 description states a specific action (list) and resource (derived intelligence products) with explicit detail on what each row contains (index/model, signal collections, plan requirement). It also explicitly distinguishes itself from the sibling get_fused_signal by saying they answer different questions, making the purpose unambiguous.

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 gives direct guidance: read this to check if a product exists, then call get_fused_signal to compute it. It contrasts the two tools' semantics (catalogue vs. current window support) and explains the plan:team gating so a gated product is not mistaken for a missing one. This is explicit when-to-use and when-not-to-use guidance.

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

open_paymentA
Idempotent
Inspect

Buy access for yourself, with no human involved. Step one of two: this quotes the exact amount and binds the purchase to the wallet you will pay from.

Three things can be bought. Call credits: plan "credits" with amount_usd from 1 to 100, at $0.001 a call — one credit per successful tool call, Builder's limits while the balance lasts, no expiry, failed calls not charged. A pass: plan "builder" or "team" with cycle "day" or "week". A plan period: the same plans with cycle "monthly" or "yearly". Nothing renews automatically; buying the same plan again before it ends extends it.

You must already have an identity — call register_agent first and send the key as an Authorization header. Call get_plans for the ladder and what each option raises.

from_address is required and is the wallet the USDC will leave. It is bound now, before the payment exists, because a transaction hash is public the moment it is mined: without the binding, anyone watching the settlement address could take your transfer and redeem it as their own. Only a transfer from the wallet you name here, redeemed with a signature from that same wallet, will settle this purchase.

Returns PAY lines with the atomic amount, the token, the network and the address to pay. Transfer it, then call settle_payment with the transaction hash.

ParametersJSON Schema
NameRequiredDescriptionDefault
planYesWhat to buy: call credits, or a plan. Enterprise is a design partner engagement and cannot be bought here.
cycleNoPeriod for a plan. Defaults to monthly. Ignored for credits.
amount_usdNoWhole dollars of credits to buy, at $0.001 a call. Required when plan is credits.
from_addressYesThe EVM address the USDC will be sent from, 0x followed by 40 hex characters. Binding, and required.

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations, the description discloses critical behavioral traits: the purchase is bound to the from_address before payment, repeated purchases extend existing plans, nothing renews automatically, called credits do not expire, failed calls are not charged, and returns PAY lines with the atomic amount. The security rationale for binding is also explained. This is unusually transparent for a payment tool.

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 each section earns its place: overview, product options, prerequisites, binding rationale, and next step. It is organized and front-loaded with the core purpose. Some sentences could be tightened, but the density is justified by the complexity of a two-step payment flow.

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?

With no output schema, the description still enumerates what the return value contains ('PAY lines with the atomic amount, the token, the network and the address to pay'). It also covers prerequisites, edge cases around plan renewal, invalid plan types, and the follow-up call. An agent has enough context to invoke open_payment correctly and proceed to settle_payment.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial meaning: it details the credits plan pricing ($0.001 per call, one credit per successful call, Builder's limits, no expiry), explains that cycle defaults to monthly and is ignored for credits, and clarifies that from_address is required and binding for security reasons. This goes well beyond the schema's field descriptions.

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?

Description opens with 'Buy access for yourself, with no human involved' and immediately scopes itself as 'step one of two' in a payment flow, naming the exact quote-and-bind behavior. It clearly distinguishes itself from the sibling settle_payment by describing the two-step sequence, so an agent can tell them apart.

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?

Provides explicit when-to-use context: prerequisites ('call register_agent first'), discovery ('call get_plans'), and the next step ('then call settle_payment'). It also rules out enterprise plans ('cannot be bought here') and explains what is not covered, leaving no ambiguity about when this tool is appropriate.

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

register_agentAInspect

Create your own identity on pronto and receive an API key, with no human present. Send the key back as an Authorization header on later calls and you will be recognised across sessions.

Registering grants no plan. A new identity has exactly the limits an unauthenticated caller has. There are two ways to raise them, and you can take either. If you hold your own funds, call get_plans and then open_payment — you buy your own plan and no person is involved at any point. If your costs belong to someone else, hand them the claim code and URL in this response; once they claim you, your calls resolve to their plan with no change on your side.

Supply an Ed25519 public key (base64) if you can keep the private half: it lets you rotate your own credential before it expires without anyone's help. Without one you cannot rotate, and you must register again when the key expires.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNoA name for this agent, for whoever reviews the account later.
public_keyNoBase64-encoded Ed25519 public key, 32 bytes. Optional, but without it you cannot rotate your own credential.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark this as non-read-only and non-idempotent; the description goes beyond them by disclosing that registration grants no plan, that limits match an unauthenticated caller, that the API key must be sent as an Authorization header, and the rotation/expiration consequence of omitting the Ed25519 public key. No annotation contradiction is present.

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 purpose is front-loaded and each paragraph covers a distinct concern: core identity/API key, plan/limit/billing options, and key-rotation tradeoffs. It is long but not bloated; slight repetition of the no-human theme costs it a perfect score.

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?

With no output schema, the description still names the response elements (API key, claim code, URL), explains the auth header mechanics, states default limits, and lays out both plan-raising paths. An agent has enough to invoke register_agent and know what to do with the result.

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 100%, so the baseline is 3. The description adds meaningful param context for the public key by explaining why it matters—credential rotation without help and the forced re-registration if omitted—giving agents deeper understanding beyond the raw schema text.

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 states a specific action and outcome: 'Create your own identity on pronto and receive an API key'. It is clearly distinct from the sibling get_/list_/payment tools, and the registration purpose is unambiguous.

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 clarifies when to use this tool: when an identity/API key is needed without human involvement. It also provides post-registration branching guidance—get_plans/open_payment for self-funded plans, or sharing the claim code/URL for third-party coverage—and warns when re-registration is required, though it does not explicitly contrast register_agent with a direct alternative.

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

scope_signalsA
Read-onlyIdempotent
Inspect

Select a slice of the live wire by facet tags — the structured metadata each signal carries, not the words in its text. Use this when you can name the slice you want: every high-severity climate signal in Japan, everything from one provider, everything in one language. It returns the whole slice whatever words the signals happen to use, which is what separates it from search_signals; reach for search when you have a subject word and no category to name.

Facets cover language, country, region, domain, topic, severity, provider, coverage, and place. Facets that share a key combine with OR. Facets with different keys combine with AND. The filter "country:JP,country:CL domain:climate" selects Japan or Chile, and climate. A locale filter alone cannot answer this question.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum signals to return (default 25, max 200)
cursorNoPage token from META cursor: of the previous response. Omit for the first page.
filterNoFacet expression: space- or comma-separated key:value pairs. Keys are fixed vocabulary — lang, country, region, domain, topic, severity, provider, coverage, place. Same key = OR, different keys = AND. Examples: "country:jp domain:climate" (Japanese climate signals), "country:us,country:cl severity:high" (US or Chile, high severity), "place:Tokyo" (resolved to a gazetteer id). Call list_facets for live values.
localeNoOptional BCP-47 language code (e.g. 'ja', 'zh', 'de', 'ar'). When set, response metadata is returned in the requested language context.
relateNoAlso return the link graph over the rows in this response, as REL lines, so repeats of one story can be collapsed without a second call. Off by default.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds value beyond that: it discloses the matching behavior ('returns the whole slice whatever words the signals happen to use') and the exact OR/AND combination semantics with a worked example. No contradiction with annotations; the read-only claim is supported by 'select' language.

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?

Every sentence earns its place: purpose, usage examples, differentiation, facet list, and combination rules. It front-loads the core purpose and the differentiation from search_signals early. The closing locale note ('A locale filter alone cannot answer this question') is slightly cryptic and the least clearly motivated sentence, which keeps it from a 5.

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?

For a tool with nontrivial filter semantics and five parameters, the description covers purpose, usage context, sibling differentiation, the facet vocabulary, and combination behavior. There is no output schema, and the description doesn't detail return format, but given the read-only, idempotent nature disclosed by annotations and the rich filter documentation, the agent has what it needs to call correctly. Minor gaps: return shape and how relate/limit interplay are 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 coverage is 100%, so the schema already documents all five parameters, including the filter's key vocabulary and OR/AND rules. The description reinforces the filter semantics with its own example ('country:JP,country:CL domain:climate') and adds the conceptual facet-vs-text framing, which is genuinely useful. But much of the filter detail is duplicated in the schema, so the description's marginal addition over the schema is modest — the baseline 3 applies.

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: 'Select a slice of the live wire by facet tags.' It defines what 'facet tags' mean (structured metadata, not text words), and explicitly separates this tool from search_signals by the matching mechanism. An agent can immediately tell what this does and how it differs from the sibling search 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 gives explicit when-to-use guidance: 'Use this when you can name the slice you want' with concrete examples (high-severity climate in Japan, one provider, one language). It also names the alternative and the condition that selects it: 'reach for search when you have a subject word and no category to name.' This is a textbook when/when-not pairing.

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

search_signalsA
Read-onlyIdempotent
Inspect

Find signals by the words in them. Use this when you are looking for a subject — a storm name, a company, a phrase a report would print — and cannot name it as a category. When you can name it as a category instead (a country, a domain, a severity), scope_signals selects that slice exactly and does not depend on any particular word appearing; this tool ranks by word overlap and will miss a matching signal that phrased it differently.

The search covers places, observations, summaries, identifiers, and the country and topic facets of each signal, so "Japan" reaches a Japanese-language article that never writes the word.

A signal is returned when it contains the words you asked for. Inflections count: "flood" reaches "flooding" and "quake" reaches "quakes". Synonyms do not: the match is lexical, not semantic, so "car" does not reach "automobile" and "downturn" does not reach "recession". Use the words the source would have used.

Results are ranked by how much of your query each signal contains, exact phrase matches first. When nothing contains your terms the tool returns an error rather than the closest available rows; an empty result means the wire does not carry it, not that the search gave up. Returns CWF lines.

ParametersJSON Schema
NameRequiredDescriptionDefault
sortNorelevance (default): word coverage, exact phrase first. significance: the server's composed attention score, which lifts severity and connectivity over freshness — use it when looking for consequence rather than currency.
limitNoMaximum matches to return (default 10, max 50)
queryYesKeywords describing the anomaly or topic, e.g. 'earthquake pacific' or 'solar flare'
cursorNoPage token from META cursor: of the previous response.
localeNoOptional BCP-47 language code (e.g. 'ja', 'zh', 'de', 'ar'). When set, response metadata is returned in the requested language context.
min_severityNoDrop results below this published band. Unrated rows are dropped too, because absence of a rating is not evidence of safety.

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond the readOnly/openWorld/idempotent annotations by disclosing match semantics (inflections count, synonyms don't), ranking order (exact phrase first, word coverage), error behavior (returns error rather than closest rows), and return format ('Returns CWF lines'). This is rich behavioral context the agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and usage rule, then organized into focused paragraphs on coverage, matching semantics, and result behavior. Each sentence adds distinct value with no filler.

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?

For a 6-parameter search tool with no output schema, the description covers usage, alternative selection, matching behavior, ranking, error handling, and return format. The domain-specific 'CWF lines' is a minor shorthand but the behavioral guidance is otherwise comprehensive.

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. The description adds interpretive meaning for the query parameter (matching behavior across inflections, no synonyms) and for sort (ranking details not fully in the schema), elevating it above baseline.

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 states a specific verb and resource: 'Find signals by the words in them.' It explicitly names the sibling scope_signals as the alternative for category-based lookup, so an agent can differentiate the tools 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.

Usage Guidelines5/5

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

The description gives explicit when-to-use: 'Use this when you are looking for a subject — a storm name, a company, a phrase a report would print — and cannot name it as a category.' It also names the alternative and the condition that selects it, explaining the lexical-match limitation that matters for tool choice.

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

settle_paymentA
Idempotent
Inspect

Redeem a payment you have made and activate what it bought — a plan, a pass or call credits. Step two of two, after open_payment and the transfer.

Prove the payment is yours: sign the SIGN message from open_payment with the paying wallet (personal_sign; smart wallets via ERC-1271) and pass it as signature. A transaction hash is public once mined, so without the signature anyone who saw your transfer could redeem it.

The payment is verified by reading Base: the transfer must have reached the settlement address, from the wallet this purchase was opened with, for at least the amount owed, and be five blocks deep. A payment that is real but not yet deep enough returns a pending error naming that — the money has moved, so do not pay again: it settles on its own once deep enough, and calling this again with the same hash reads the outcome. One transaction pays for one purchase, once.

On success your existing API key resolves to the new plan with nothing to change on your side: you become your own principal, and no person holds the subscription.

ParametersJSON Schema
NameRequiredDescriptionDefault
signatureYes65-byte hex signature (0x…) from the paying wallet, made with personal_sign (EIP-191) over the SIGN message open_payment returned, with your lower-case transaction hash filled in. Smart-contract wallets are checked with ERC-1271.
transaction_hashYesThe Base transaction hash of your USDC transfer: 0x followed by 64 hex characters.

TDQS

A4.3/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing the exact Base verification rules, the five-block depth requirement, the pending-error behavior, idempotent re-invocation, and the signature rationale. It also explains the success side effect on the API key.

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 and then organized around signature, verification, pending behavior, and success. It is long, but the length is justified by the number of critical caveats and each paragraph earns its place.

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 covers prerequisites, verification conditions, pending errors, idempotency, and the successful outcome. With no output schema, however, the exact response/error shape is left implicit and failure cases such as bad signature or wrong sender are not enumerated.

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 schema already documents the hex format, personal_sign/ERC-1271, the SIGN message, and the transaction hash format. The description reinforces these details but does not add new parameter-level meaning beyond what the schema provides.

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 states a specific action ('Redeem a payment') on a specific resource and the outcomes it activates: a plan, a pass, or call credits. 'Step two of two, after open_payment' clearly distinguishes it from the sibling open_payment.

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 clearly places the tool in the flow: after open_payment and the transfer, and it gives retry guidance for pending payments. It does not explicitly enumerate alternatives or prohibitions beyond 'do not pay again', so the when-not-to-use edge is slightly implicit.

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.

  1. 2 tool updates
    • Changedscope_signals1 field changed
      • addedInput schema / properties / locale
        Added value: +{
+  "description": "Optional BCP-47 language code (e.g. 'ja', 'zh', 'de', 'ar'). When set, response metadata is returned in the requested language context.",
+  "type": "string"
+}
    • Changedsearch_signals1 field changed
      • addedInput schema / properties / locale
        Added value: +{
+  "description": "Optional BCP-47 language code (e.g. 'ja', 'zh', 'de', 'ar'). When set, response metadata is returned in the requested language context.",
+  "type": "string"
+}
  2. 2 tool updates
    • Changedopen_payment5 fields changed
      • addedInput schema / properties / amount_usd
        Added value: +{
+  "description": "Whole dollars of credits to buy, at $0.001 a call. Required when plan is credits.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
      • changedInput schema / properties / cycle / description
        Previous value: -"Billing cycle. Defaults to monthly."New value: +"Period for a plan. Defaults to monthly. Ignored for credits."
      • changedInput schema / properties / cycle / enum
        Previous value: -[
-  "monthly",
-  "yearly"
-]New value: +[
+  "day",
+  "week",
+  "monthly",
+  "yearly"
+]
      • changedInput schema / properties / plan / description
        Previous value: -"The plan to buy. Enterprise is a design partner engagement and cannot be bought here."New value: +"What to buy: call credits, or a plan. Enterprise is a design partner engagement and cannot be bought here."
      • changedInput schema / properties / plan / enum
        Previous value: -[
-  "builder",
-  "team"
-]New value: +[
+  "credits",
+  "builder",
+  "team"
+]
    • Changedsettle_payment2 fields changed
      • addedInput schema / properties / signature
        Added value: +{
+  "description": "65-byte hex signature (0x…) from the paying wallet, made with personal_sign (EIP-191) over the SIGN message open_payment returned, with your lower-case transaction hash filled in. Smart-contract wallets are checked with ERC-1271.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "transaction_hash"
-]New value: +[
+  "transaction_hash",
+  "signature"
+]
  3. 2 tool updates
    • Addedopen_payment
    • Addedsettle_payment
  4. 4 tool updates
    • Changedget_latest_signals2 fields changed
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Page token from META cursor: of the previous response. Omit for the first page.",
+  "type": "string"
+}
      • changedInput schema / properties / relate / description
        Previous value: -"Also return the link graph over the rows in this response, as REL lines, so repeats of one story can be collapsed without a second call. Off by default."New value: +"Also return the link graph over the rows in this response, as REL and CLUSTER lines, so repeats of one story collapse into one line without a second call. Off by default."
    • Changedget_related_signals1 field changed
      • changedInput schema / properties / correlation_id / description
        Previous value: -"Correlation id of the signal to start from. Accepts either the full id or the short handle in column 2 of any CWF v3 row."New value: +"Correlation id of the signal to start from. Accepts either the full id or the short handle in column 2 of any CWF v3 row. Aliases accepted for robustness: id, signal_id."
    • Changedscope_signals4 fields changed
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Page token from META cursor: of the previous response. Omit for the first page.",
+  "type": "string"
+}
      • changedInput schema / properties / filter / description
        Previous value: -"Facet expression, e.g. \"country:JP domain:climate severity:high\". Call list_facets to see live values."New value: +"Facet expression: space- or comma-separated key:value pairs. Keys are fixed vocabulary — lang, country, region, domain, topic, severity, provider, coverage, place. Same key = OR, different keys = AND. Examples: \"country:jp domain:climate\" (Japanese climate signals), \"country:us,country:cl severity:high\" (US or Chile, high severity), \"place:Tokyo\" (resolved to a gazetteer id). Call list_facets for live values."
      • addedInput schema / properties / filter / examples
        Added value: +[
+  "country:jp domain:climate",
+  "severity:high,critical domain:security",
+  "provider:usgs"
+]
      • addedInput schema / properties / filter / pattern
        Added value: +"^([a-z]+:[^ ,]+([ ,]+|$))+$"
    • Changedsearch_signals3 fields changed
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Page token from META cursor: of the previous response.",
+  "type": "string"
+}
      • addedInput schema / properties / min_severity
        Added value: +{
+  "description": "Drop results below this published band. Unrated rows are dropped too, because absence of a rating is not evidence of safety.",
+  "enum": [
+    "info",
+    "low",
+    "medium",
+    "high",
+    "critical"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / sort
        Added value: +{
+  "description": "relevance (default): word coverage, exact phrase first. significance: the server's composed attention score, which lifts severity and connectivity over freshness — use it when looking for consequence rather than currency.",
+  "enum": [
+    "relevance",
+    "significance"
+  ],
+  "type": "string"
+}
  5. 1 tool update
    • Changedget_fused_signal1 field changed
      • changedInput schema / properties / product / enum
        Previous value: -[
-  "air_quality_health_index",
-  "aviation_network_stress",
-  "compound_hazard_convergence",
-  "crypto_cross_rate_dislocation",
-  "cyber_exploitation_risk",
-  "cyber_physical_exposure",
-  "epidemic_growth_rate",
-  "felt_intensity",
-  "fire_danger_index",
-  "fx_reference_rate_consistency",
-  "generation_mix_diversity",
-  "global_news_attention",
-  "grid_carbon_arbitrage",
-  "macro_stress_index",
-  "measles_immunity_gap",
-  "neo_kinetic_energy",
-  "news_response_latency",
-  "preston_health_efficiency",
-  "recession_risk_12m",
-  "research_momentum",
-  "sahm_recession_indicator",
-  "sea_state_index",
-  "seismic_activity_cluster",
-  "seismic_energy_release",
-  "seismic_population_exposure",
-  "seismic_solution_consensus",
-  "sovereign_debt_dynamics",
-  "space_weather_ops",
-  "taylor_rule_policy_gap",
-  "thermal_stress_index",
-  "uv_exposure_index",
-  "wbgt_heat_stress"
-]New value: +[
+  "air_quality_health_index",
+  "aviation_network_stress",
+  "compound_hazard_convergence",
+  "crypto_cross_rate_dislocation",
+  "cyber_exploitation_risk",
+  "cyber_physical_exposure",
+  "disease_burden_distribution",
+  "epidemic_growth_rate",
+  "felt_intensity",
+  "fire_danger_index",
+  "fx_fixing_drift",
+  "fx_reference_rate_consistency",
+  "generation_mix_diversity",
+  "global_news_attention",
+  "grid_carbon_arbitrage",
+  "insider_filing_cluster",
+  "macro_stress_index",
+  "measles_immunity_gap",
+  "neo_kinetic_energy",
+  "news_response_latency",
+  "preston_health_efficiency",
+  "recession_risk_12m",
+  "research_momentum",
+  "sahm_recession_indicator",
+  "sea_state_index",
+  "seismic_activity_cluster",
+  "seismic_energy_release",
+  "seismic_population_exposure",
+  "seismic_solution_consensus",
+  "sovereign_debt_dynamics",
+  "space_weather_ops",
+  "taylor_rule_policy_gap",
+  "thermal_stress_index",
+  "uv_exposure_index",
+  "wbgt_heat_stress"
+]
  6. 1 tool update
    • Changedget_fused_signal2 fields changed
      • changedInput schema / properties / product / description
        Previous value: -"Filter to one product: space_weather_ops, recession_risk_12m, sahm_recession_indicator, air_quality_health_index, cyber_exploitation_risk, cyber_physical_exposure, thermal_stress_index, wbgt_heat_stress, sea_state_index, seismic_energy_release, seismic_activity_cluster, seismic_solution_consensus, felt_intensity, seismic_population_exposure, news_response_latency, macro_stress_index, uv_exposure_index, grid_carbon_arbitrage, generation_mix_diversity, sovereign_debt_dynamics, taylor_rule_policy_gap, fx_reference_rate_consistency, crypto_cross_rate_dislocation, fire_danger_index, aviation_network_stress, epidemic_growth_rate, measles_immunity_gap, preston_health_efficiency, neo_kinetic_energy, research_momentum, global_news_attention, or compound_hazard_convergence. Omit for all available products."New value: +"One product to compute. Omit for every product the current window supports."
      • addedInput schema / properties / product / enum
        Added value: +[
+  "air_quality_health_index",
+  "aviation_network_stress",
+  "compound_hazard_convergence",
+  "crypto_cross_rate_dislocation",
+  "cyber_exploitation_risk",
+  "cyber_physical_exposure",
+  "epidemic_growth_rate",
+  "felt_intensity",
+  "fire_danger_index",
+  "fx_reference_rate_consistency",
+  "generation_mix_diversity",
+  "global_news_attention",
+  "grid_carbon_arbitrage",
+  "macro_stress_index",
+  "measles_immunity_gap",
+  "neo_kinetic_energy",
+  "news_response_latency",
+  "preston_health_efficiency",
+  "recession_risk_12m",
+  "research_momentum",
+  "sahm_recession_indicator",
+  "sea_state_index",
+  "seismic_activity_cluster",
+  "seismic_energy_release",
+  "seismic_population_exposure",
+  "seismic_solution_consensus",
+  "sovereign_debt_dynamics",
+  "space_weather_ops",
+  "taylor_rule_policy_gap",
+  "thermal_stress_index",
+  "uv_exposure_index",
+  "wbgt_heat_stress"
+]
  7. 1 tool update
    • Changedget_fused_signal1 field changed
      • changedInput schema / properties / product / description
        Previous value: -"Filter to one product: space_weather_ops, recession_risk_12m, sahm_recession_indicator, air_quality_health_index, cyber_exploitation_risk, cyber_physical_exposure, thermal_stress_index, wbgt_heat_stress, sea_state_index, seismic_energy_release, seismic_activity_cluster, macro_stress_index, uv_exposure_index, grid_carbon_arbitrage, generation_mix_diversity, sovereign_debt_dynamics, taylor_rule_policy_gap, fx_reference_rate_consistency, crypto_cross_rate_dislocation, fire_danger_index, aviation_network_stress, epidemic_growth_rate, measles_immunity_gap, preston_health_efficiency, neo_kinetic_energy, research_momentum, global_news_attention, or compound_hazard_convergence. Omit for all available products."New value: +"Filter to one product: space_weather_ops, recession_risk_12m, sahm_recession_indicator, air_quality_health_index, cyber_exploitation_risk, cyber_physical_exposure, thermal_stress_index, wbgt_heat_stress, sea_state_index, seismic_energy_release, seismic_activity_cluster, seismic_solution_consensus, felt_intensity, seismic_population_exposure, news_response_latency, macro_stress_index, uv_exposure_index, grid_carbon_arbitrage, generation_mix_diversity, sovereign_debt_dynamics, taylor_rule_policy_gap, fx_reference_rate_consistency, crypto_cross_rate_dislocation, fire_danger_index, aviation_network_stress, epidemic_growth_rate, measles_immunity_gap, preston_health_efficiency, neo_kinetic_energy, research_momentum, global_news_attention, or compound_hazard_convergence. Omit for all available products."
  8. 1 tool update
    • Changedget_fused_signal1 field changed
      • changedInput schema / properties / product / description
        Previous value: -"Filter to one product: space_weather_ops, recession_risk_12m, sahm_recession_indicator, air_quality_health_index, cyber_exploitation_risk, cyber_physical_exposure, thermal_stress_index, wbgt_heat_stress, sea_state_index, seismic_energy_release, seismic_activity_cluster, macro_stress_index, uv_exposure_index, grid_carbon_arbitrage, generation_mix_diversity, sovereign_debt_dynamics, taylor_rule_policy_gap, fx_reference_rate_consistency, fire_danger_index, aviation_network_stress, epidemic_growth_rate, measles_immunity_gap, preston_health_efficiency, neo_kinetic_energy, research_momentum, global_news_attention, or compound_hazard_convergence. Omit for all available products."New value: +"Filter to one product: space_weather_ops, recession_risk_12m, sahm_recession_indicator, air_quality_health_index, cyber_exploitation_risk, cyber_physical_exposure, thermal_stress_index, wbgt_heat_stress, sea_state_index, seismic_energy_release, seismic_activity_cluster, macro_stress_index, uv_exposure_index, grid_carbon_arbitrage, generation_mix_diversity, sovereign_debt_dynamics, taylor_rule_policy_gap, fx_reference_rate_consistency, crypto_cross_rate_dislocation, fire_danger_index, aviation_network_stress, epidemic_growth_rate, measles_immunity_gap, preston_health_efficiency, neo_kinetic_energy, research_momentum, global_news_attention, or compound_hazard_convergence. Omit for all available products."
  9. 13 tool updates
    • First observedget_billing_profile
    • First observedget_facet_manifest
    • First observedget_fused_signal
    • First observedget_latest_signals
    • First observedget_plans
    • First observedget_related_signals
    • First observedget_signal
    • First observedlist_data_sources
    • First observedlist_facets
    • First observedlist_fusion_products
    • First observedregister_agent
    • First observedscope_signals
    • First observedsearch_signals

Related MCP Connectors

Related MCP Servers

  • isocast-mcp

    jcislo
    A
    license
    A
    quality
    C
    maintenance
    MCP server providing Polymarket weather-market bucket-transition signals for AI agents, with free city/signal inspection tools and paid signal bundles via USDC on Base using x402.
    5
    3 npm
    MIT

  • BrunoSan AI News MCP Server

    DowellUG
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that exposes real-time AI news intelligence to AI agents and MCP-compatible clients, with 9 deterministic tools for search, trending, signals, and risk analysis.
    Apache 2.0

  • Gravitas-Core-MCP

    ahmed-coding
    A
    license
    B
    quality
    C
    maintenance
    Production-grade, autonomous Model Context Protocol (MCP) server that elevates AI models from stateless code generators into persistent, self-verifying software engineers.
    21
    1
    MIT

  • signalis-mcp

    jcislo
    A
    license
    A
    quality
    C
    maintenance
    MCP server for Signalis, providing AI agents with pay-per-call global intelligence including Master Intelligence digests and Pulse narratives, with payments settled in USDC on Base via x402.
    10
    2 npm
    MIT
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.

Resources