The first low-latency wire service purpose-built for AI agents. Ingests 54+ public APIs and 71k RSS feeds across 232 countries, outputs CWF (Cognitive Wire Format) – 80% shorter than JSON, sub-second WebSocket delivery.
9 MCP tools: get_latest_signals, search_signals, get_fused_signal, scope_signals, get_facet_manifest, list_facets, get_related_signals, list_data_sources, get_billing_profile.
26 citable fusion products with verifiable formulas – no black-box scores.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint false, and the description agrees. It adds valuable state-dependent behavior: it returns a BILL line, a CREDIT line only when a metering balance exists, and a NOTE line for unauthenicated or unclaimed callers. This goes well beyond the annotations and creates a clear behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then details return line types and entitlement chaining. Every sentence earns its place: no filler, no repeated schema facts, and the conditional next-step guidance is packaged efficiently.
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?
There is no output schema, so the description carries the burden of explaining what comes back. It covers the success case (BIL lines, plan limits), the balance case (CREDIT line), and failure cases (NOTE line with remedy). It also explains what an agent should do next in the unauthenicated path. This is complete for an agent to select and invoke the 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?
The input schema requires no parameters, so the 0-parameter baseline of 4 applies. The parameter dimension is therefore not a burden; the description appropriately explains that resolution is subordinate to the agent identity rather than to input arguments.
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 is highly specific: it says the tool 'reports' who the agent is resolved as, the founded account, plan, per-minute call ceiling, per-response row budget, and indicator set. This is substantially more than a restatement of the name. However, it does not explicitly distinguish itself from sibling getter tools such as get_plans or 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: if unauthenicated, call register_agent next; after that, use open_payment or pass the claim code to a budget holder. It also explains what the tool does when the caller is not entited. It does not explicitly state when to prefer get_plans or other siblings, but the workflow guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag read-only, idempotent, and open-world behavior. The description adds genuinely useful behavioral context: response is intentionally small, topic tails are truncated, only two facet keys are covered, and the result is structure rather than signal content.
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 output shape before adding positioning and exclusions. Every sentence provides actionable guidance; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description gives enough to know what the response contains, how it is sorted, what is truncated, and which alternative to use when broader facets are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 and there is little to document. The description does not need to explain input semantics because no inputs exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a facet manifest: a two-level tree of domain and topic with signal counts, ranked by busiest. It also differentiates itself from siblings by noting it covers only domain and topic, whereas list_facets covers the full vocabulary.
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?
Explicit when-to-use guidance is provided: read this map first, choose a scope offline, then make a precise call to scope_signals or search_signals. It also names the alternative for exhaustive vocabulary, list_facets, and states what the manifest does not contain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | One product to compute. Omit for every product the current window supports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations: each result cites its method and source signals, missing citations are labelled, absent products indicate no live inputs, cross-source products require time-aligned publishers, and suppressed Team-plan indicators are explained with a NOTE line. There is no contradiction with the read-only, open-world, or idempotent annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every paragraph earns its place: it front-loads the core purpose, gives the omit-versus-select usage rule, clarifies absence semantics, and then presents useful interpretive warnings about specific products and plan-based exclusions. It is dense but decision-relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, a read-only idempotent operation, no output schema, and rich annotations, the description is complete. It explains what the output contains, what absence means, how to discover unavailable products, and how plan-based exclusions are disclosed — an agent has enough information to invoke the tool 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?
The input schema already provides the full enum and a base description at 100% coverage, so the baseline is a 3. The description adds extra semantic value by explaining omission behavior, absent-product meaning, and the relationship to the current window, which goes beyond what the schema itself documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Compute derived intelligence products') and the resource ('the live wire'). It further distinguishes itself from the sibling list_fusion_products by noting that a product absent from the output has no live inputs right now, so an agent immediately knows what this tool offers versus its closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to pick one product or omit the parameter for everything the window supports, and it explains what an omitted result means. It also names list_fusion_products as the way to see the full catalogue and clarifies that it does not depend on the window, giving clear conditions for choosing between the two tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of signals to return (default 20, max 100) | |
| cursor | No | Page token from META cursor: of the previous response. Omit for the first page. | |
| relate | No | 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. | |
| collection | No | Signal collection to filter by, e.g. climate, sentiment, security, health, cosmic, energy, macro, market, crypto, knowledge, prediction, logistics. Omit for all collections. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful non-obvious behavior beyond the readOnly/openWorld/idempotent annotations: CWF format, provider and collection diversification caps, and overflow being named on a note line instead of silently dropped. This gives the caller a realistic model of how results are shaped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not bloated: the first sentence gives the operational core, and the second sentence is a substantive addition about result distribution. The middle clause is long, but every phrase carries useful signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent tool with no required parameters and complete schema descriptions, the description covers the key decision that affects output shape. A short nod to alternatives such as search_signals or scope_signals would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters are already well described in the schema, so the baseline is 3. The description adds real semantic value for collection, explaining that omitting it produces a diversified all-collections view while passing it yields full-depth results.
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 opening sentence states a specific action — fetch the most recent live signals from the wire — and adds the format and filtering dimension. It is clearly distinguished from single-signal getters like get_signal and from search_signals by emphasizing 'latest from the wire' and CWF format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance for when to pass collection: the all-collections view is intentionally diversified, while collection reads a single collection at full depth. It does not explicitly name alternatives to exclude, so it narrowly misses the top end of the scale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 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 one CWF PLAN line per plan, and a SETTLE line naming the asset, network and address to pay.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral detail beyond the annotations: it describes the machine-readable output format, the one CWF PLAN line per plan, and the SETTLE line naming asset, network, and address. This is a meaningful enhancement over the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then efficiently delivers the purpose, the decision context, and the return format in two sentences. Every sentence adds distinct value: what the tool does, why an agent would use it, and what the result looks like. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is complete: it states the tool's purpose, its role in refusal handling, and the structure of its output. An agent has enough context to call the tool and interpret the result without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so schema description coverage is 100%. There is no parameter burden for the description to carry; the baseline of 4 applies because there are no parameters requiring explanation.
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 opens with a specific verb and resource: 'List the plans, what each costs, and what each raises', then names the concrete outputs (call ceiling, row budget, commercial indicator set). This clearly identifies the tool's scope and distinguishes it from sibling tools like get_billing_profile or list_fusion_products without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is useful: 'so you can decide what to do about a refusal without parsing a pricing page'. It also mentions related actions (open_payment, escalating to budget holder), but it does not explicitly state when not to use this tool versus a sibling. Clear context is present, though exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| correlation_id | Yes | Id of the signal to fetch. Accepts either the full correlation id or the short handle in column 2 of any CWF v3 row. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful runtime behavior beyond the annotations: the live-window turns over in about a minute, a previously read signal may have aged out, and the error message tells you whether the id is stale or malformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long, but every clause has purpose: it states the trigger condition, why reuse is unsafe, what input format is accepted, the time-window caveat, and explicit sibling routing. It is front-loaded with the core use case and the additional detail is supportive rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool, this description is contextually complete. It tells the agent what the operation is, what input forms are accepted, what runtime caveat to expect, how errors behave, and which sibling tools to use for different needs. Even without an output schema, the agent understands what comes back: the single requested row.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage, stating that correlation_id accepts either a full correlation id or the short handle in column 2 of a CWF v3 row. The description repeats this with the phrase 'cite the handle, pass it back here' but adds no materially new semantic meaning beyond the schema.
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 opens with a specific verb and object: 'Fetch a signal by its id, when you already know which one you want.' It marks the boundary against sibling read tools by saying 'every other read tool returns a set and bounds it' while this one 'returns that row and nothing else.'
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 explicitly says to use this tool when you already know the id, and tells the agent to use search_signals or scope_signals to find signals, and get_related_signals for signals about the same subject. It also explains why re-reading through set-returning tools is wasteful, which further supports the right tool choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the data-source endpoints feeding the wire, with provider, signal type, country, cadence, and license. Returns one SRC line per source.
| Name | Required | Description | Default |
|---|---|---|---|
| signal_type | No | Filter by signal type, e.g. climate, security, health. Omit for all sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that the tool is read-only, idempotent, and closed-world. The description adds value beyond these annotations by specifying the output shape: 'Returns one SRC line per source,' and by listing the included fields, giving the agent a concrete expectation of the result despite the absence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the core action and resource, then follows with the output format and content. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter), strong safety annotations, and the description's coverage of purpose, output format, and fields, the definition is complete enough for an agent to invoke the tool correctly without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full (100%) parameter description coverage, so the baseline is 3. The schema already explains that signal_type filters by examples and can be omitted; the tool's description does not add any additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'data-source endpoints feeding the wire,' enumerating the returned fields: provider, signal type, country, cadence, and license. It also states the output form, 'one SRC line per source,' which distinguishes it from sibling list tools like list_facets and list_fusion_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case: when an agent needs a catalog of data-source endpoints and their associated metadata. However, it does not explicitly mention when not to use this tool or name alternatives such as search_signals or get_signal, leaving some routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, and the description adds real behavioral detail: the result is a flat list, each value has a signal count, place ids get human-readable labels, and the list can be long with many values. It also reveals dynamic freshness: values are those 'scope_signals will accept right now.'
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 main purpose and output shape are front-loaded in the first sentence. The later sentences add routing and behavioral nuance that earns their place, even though the description is a bit more verbose than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description is complete: it says what comes back, how long the result can be, how it relates to scope_signals, and how to handle place facet ids. No output schema exists, but the description satisfies the need for return-value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description confirms no invocation parameters are needed by framing the tool as an exhaustive, unfiltered dump of all current facet values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'List the full filter vocabulary' and enumerates the exact facet keys (lang, country, region, domain, topic, severity, provider, coverage, place). It is clearly distinguished from get_facet_manifest and scope_signals by explaining the difference in scope.
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 tool gives explicit when-to-use guidance: use get_facet_manifest if you only need a domain and a topic, since it is cheaper; use list_facets when you need a value not in the manifest or need backed counts. It also explains place facets should be filtered with scope_signals by name instead of raw id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior beyond what annotations already state: it reads no signals, returns the same catalogue even when ingestion is warming up, and distinguishes 'published' from 'composed' product attributions. It also documents plan gating behavior and the NOTE line. Nothing here contradicts the readOnlyHint/idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the catalogue's purpose and contents, followed by the sibling-tool distinction and plan-gating nuance. Each paragraph earns its place, and no sentence is redundant with schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-input catalogue tool with no output schema, the description is fully self-sufficient: it covers what the output lists, how to interpret attribution types, how plan-gated rows appear, and how to decide between this tool and its primary sibling. There is no key behavior left undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no input schema to explain. The description reinforces this by noting it 'reads no signals' and returns the same answer independent of the current data window. With 0 params, the description is already sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List every derived intelligence product pronto can compute' and enumerates the attributes returned (published index/model, signal collections, plan requirement). It also explicitly contrasts itself with the sibling get_fused_signal, so an agent can distinguish the two tools without inspecting 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?
The description explicitly tells the agent when to use this tool: 'Read this to find out whether pronto computes the thing you need, then call get_fused_signal to actually compute it.' It also explains the semantic difference between the two tools, including the consequence for missing products, and clarifies that plan-scoped products are gated, not absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy a plan 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.
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 plan 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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | The plan to buy. Enterprise is a design partner engagement and cannot be bought here. | |
| cycle | No | Billing cycle. Defaults to monthly. | |
| from_address | Yes | The EVM address the USDC will be sent from, 0x followed by 40 hex characters. Binding, and required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations, explaining that the wallet is bound before payment exists, why that binding is needed (public transaction hashes), and what the returned PAY lines contain. There is no contradiction with the annotations: readOnlyHint=false is consistent with buying, and idempotentHint=true is not contradicted by the described behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well structured: purpose, prerequisites, key parameter rationale, and next step each get their own section. The security explanation is detailed but relevant to why from_address is required. It earns its length without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-step payment tool with no output schema, the description covers the prerequisites, the exact result (PAY lines with amount, token, network, address), and the next action (transfer then call settle_payment). Nothing needed to invoke the tool correctly is missing.
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 coverage is 100%, so the baseline is 3. The description adds meaningful extra meaning for from_address by explaining that it is the wallet the USDC will leave, that it is binding, and why this matters. It does not add much for plan or cycle, but the schema already documents those clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Buy a plan') with a clear resource and scope ('for yourself'), and differentiates itself from settle_payment as 'Step one of two'. It also references register_agent and get_plans as prerequisites, making it easy to distinguish from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call register_agent first, use get_plans for available plans, and settle_payment afterward with the transaction hash. This gives clear when-to-use and sequencing guidance that is not inferable from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | A name for this agent, for whoever reviews the account later. | |
| public_key | No | Base64-encoded Ed25519 public key, 32 bytes. Optional, but without it you cannot rotate your own credential. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only indicating non-read-only, open-world, and non-idempotent, the description adds substantial behavioral detail: no human involvement, authentication via Authorization header, unauthenticated limits by default, claim-code flow, and credential expiration/rotation consequences. This goes well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every paragraph adds necessary context: purpose, authentication, plan options, and key rotation. It is front-loaded with the core action and API key usage. Minor redundancy and dense phrasing keep it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description mentions the important response elements: the API key, claim code, and URL. It covers the identity lifecycle, plan implications, and rotation. It omits explicit error behavior and expiry duration, but the tool can be invoked correctly with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers parameter meanings, so the baseline is 3. The description adds valuable semantics for the public key parameter, explaining the base64 format, the private-half requirement, and the rotation implications, which exceeds what the schema alone communicates.
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 opens with a specific verb and outcome: create an identity and receive an API key. It clearly distinguishes this tool from the sibling billing and plan tools by focusing on registration and credential issuance.
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 explains when to use the tool (to create an identity) and what to do afterward, including alternatives for raising limits via get_plans/open_payment or a claim code. It does not explicitly state when not to use it, but the context is clear and routes the agent to relevant siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum signals to return (default 25, max 200) | |
| cursor | No | Page token from META cursor: of the previous response. Omit for the first page. | |
| filter | No | 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. | |
| relate | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, and idempotent, so the bar is lower. The description adds genuine behavioral context beyond those flags: the OR/AND composition semantics, the fact that the result slice is independent of the words used, and the caveat that a locale filter alone cannot answer a language question.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded: first sentence states purpose, first paragraph gives when-to-use and sibling differentiation, second paragraph adds filter semantics with a worked example. It loses slight points because the facet list and OR/AND rule are repeated nearly verbatim in the schema's filter parameter description, making the wording mildly redundant overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required, parameter-light tool, this is largely complete: what it does, when to prefer it, how filter combination works, and what a successive cursor needs are all documented. The one gap is that with no output schema, the description never specifies the shape of a returned signal object; it says what the slice is but not its structure.
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 coverage is 100%, so the heavy lifting is already done by the input schema (limit defaults, cursor semantics, filter pattern, relate meaning). The description adds meaningful semantics on top: walking through 'country:JP,country:CL domain:climate' as Japan-or-Chile AND climate, and warning that locale does not subsume language, which goes beyond the schema's own key list.
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 opens with a specific verb and resource — 'Select a slice of the live signal by facet tags' — and immediately clarifies that matching is by structured metadata, not text content. It explicitly differentiates itself from search_signals ('which is what separates it from search_signals'), so an agent can distinguish sibling tools without inspecting their 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?
It states the when-to-use condition directly: 'Use this when you can name the slice you want', with concrete examples (high-severity climate signals in Japan, one provider, one language). It also gives the exclusion rule by routing to the alternative: 'reach for search when you have a subject word and no category to name.' Selection guidance is explicit and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | 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. | |
| limit | No | Maximum matches to return (default 10, max 50) | |
| query | Yes | Keywords describing the anomaly or topic, e.g. 'earthquake pacific' or 'solar flare' | |
| cursor | No | Page token from META cursor: of the previous response. | |
| min_severity | No | Drop results below this published band. Unrated rows are dropped too, because absence of a rating is not evidence of safety. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, openWorld, and idempotent behavior, and the description goes well beyond them: it discloses lexical matching, inflection handling, lack of synonym support, ranking by word coverage, error-on-empty behavior, and the meaning of an empty result. It also adds search-field coverage details without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense paragraphs, each sentence earns its place: use case, scope-limitations, field coverage, matching semantics, ranking, error semantics, and output type. It is front-loaded with the core decision and keeps warnings precise rather than padded.
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 description handles the tool's complexity well: usage, matching limitations, error states, and output type are all covered. The only real gap is that 'CWF lines' is introduced without explaining what CWF lines look like, which is more consequential because there is no output schema to fill the void.
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 100%, so baseline is 3, but the description adds meaningful parameter-level semantics beyond the schema: query words are matched lexically, inflections count, synonyms do not, and ranking depends on word overlap. It does not go deeper into cursor or limit semantics, but the schema already covers their mechanics.
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's first sentence, 'Find signals by the words in them,' names the exact tool purpose with a clear verb and resource. It goes further and differentiates from the sibling scope_signals by contrasting word-based lookup with category-based selection, so an agent can tell them apart without inspecting their 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?
Explicit when-to-use guidance is present: use this tool when looking for a subject that cannot be named as a category, and use scope_signals when a category (country, domain, severity) is available. It also warns about this tool's weakness, missing equivalent phrasing, which sets expectations for when it is not the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redeem a payment you have made and activate your plan. Step two of two, after open_payment and the transfer.
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 call this again with the same hash rather than paying twice. One transaction settles one subscription.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_hash | Yes | The Base transaction hash of your USDC transfer: 0x followed by 64 hex characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses concrete verification criteria (settlement address, originating wallet, amount owed, five blocks deep), the pending-error behavior, that one transaction settles one subscription, and the success outcome for the API key. None of this contradicts the readOnlyHint=false, openWorldHint=true, or idempotentHint=true annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured in three tight paragraphs: what the tool does, how verification works and what to do on pending, and what happens on success. Each sentence carries distinct operational information, and the highest-level purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation tool with no output schema, the description is complete: it explains prerequisites, verification rules, error behavior, retry semantics, cardinality, and postconditions. An agent has enough context to invoke it correctly and to distinguish a pending outcome from a failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter, including the exact format ('0x followed by 64 hex characters'). The description reinforces that the same hash should be reused on retry, but adds no new syntactic meaning beyond what the schema already documents.
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 opens with a specific verb and resource: 'Redeem a payment you have made and activate your plan.' It also clarifies its place in a workflow as 'Step two of two, after open_payment and the transfer,' which clearly distinguishes it from sibling tools like open_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states exactly when to call this tool: only after open_payment and the transfer, and when the transfer has reached the settlement address at sufficient depth. It also gives explicit retry guidance by telling users to call it again with the same hash instead of paying twice when a pending error is returned.
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. Dates show when Glama detected each change.
open_paymentsettle_paymentget_latest_signals2 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Page token from META cursor: of the previous response. Omit for the first page.",
+ "type": "string"
+}Input schema / properties / relate / descriptionPrevious 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."get_related_signals1 field changedInput schema / properties / correlation_id / descriptionPrevious 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."scope_signals4 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Page token from META cursor: of the previous response. Omit for the first page.",
+ "type": "string"
+}Input schema / properties / filter / descriptionPrevious 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."Input schema / properties / filter / examplesAdded value: +[
+ "country:jp domain:climate",
+ "severity:high,critical domain:security",
+ "provider:usgs"
+]Input schema / properties / filter / patternAdded value: +"^([a-z]+:[^ ,]+([ ,]+|$))+$"search_signals3 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Page token from META cursor: of the previous response.",
+ "type": "string"
+}Input schema / properties / min_severityAdded 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"
+}Input schema / properties / sortAdded 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"
+}get_fused_signal1 field changedInput schema / properties / product / enumPrevious 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"
+]get_fused_signal2 fields changedInput schema / properties / product / descriptionPrevious 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."Input schema / properties / product / enumAdded 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"
+]get_fused_signal1 field changedInput schema / properties / product / descriptionPrevious 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."get_fused_signal1 field changedInput schema / properties / product / descriptionPrevious 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."get_latest_signals1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of signals to return (default 100, max 500)"New value: +"Maximum number of signals to return (default 20, max 100)"get_related_signals1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum neighbours (default 20, max 100)"New value: +"Maximum neighbours (default 5, max 10)"scope_signals1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum signals to return (default 200, max 1000)"New value: +"Maximum signals to return (default 25, max 200)"search_signals1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum matches to return (default 50, max 250)"New value: +"Maximum matches to return (default 10, max 50)"get_fused_signal1 field changedInput schema / properties / product / descriptionPrevious 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, 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, 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."get_latest_signals1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of signals to return (default 20, max 100)"New value: +"Maximum number of signals to return (default 100, max 500)"get_related_signals1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum neighbours (default 5, max 20)"New value: +"Maximum neighbours (default 20, max 100)"scope_signals1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum signals to return (default 25, max 200)"New value: +"Maximum signals to return (default 200, max 1000)"search_signals1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum matches to return (default 10, max 50)"New value: +"Maximum matches to return (default 50, max 250)"get_signallist_fusion_productsget_plansregister_agentget_latest_signals1 field changedInput schema / properties / relateAdded value: +{
+ "description": "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.",
+ "type": "boolean"
+}get_related_signals1 field changedInput schema / properties / correlation_id / descriptionPrevious value: -"Correlation id of the signal to start from, taken from any CWF line"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."scope_signals1 field changedInput schema / properties / relateAdded value: +{
+ "description": "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.",
+ "type": "boolean"
+}Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: get_signal re-reads a known row, get_latest_signals fetches by time, scope_signals filters by facets, search_signals matches words, and get_related_signals follows links. The overlapping pairs like get_facet_manifest/list_facets and get_fused_signal/list_fusion_products are explicitly differentiated in their descriptions, so an agent should not confuse them.
The naming follows a consistent snake_case verb_noun pattern: get_ for direct fetches, list_ for catalog-style enumeration, register_ for identity creation, and scope_/search_ for query actions. The slight difference between get_fused_signal and list_fusion_products is meaningful and the verbs remain predictable.
Thirteen tools is well within the sweet spot and each one covers a distinct capability: live reads, lookup by id, lexical search, facet filtering, related signals, fused products, catalogues, plans, billing, and agent registration. There is no obvious padding or excessive fragmentation.
The surface fully covers the domain: discovering the vocabulary, selecting signals, searching, fetching by id, following relationships, computing derived products, listing sources, and checking billing/plans. The only gaps would be account claiming and credential rotation, but those are explicitly deferred to external parties, so they are not tool-set gaps.