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.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 13 of 13 tools scored. Lowest: 3.6/5.
Each tool has a clearly distinct purpose: account/plan info, facet discovery, signal retrieval by id/recency/facet/text, related links, fusion catalogue/computation, and registration. Even the two facet-listing tools are explicitly differentiated as abbreviated manifest versus exhaustive listing, so no two tools are ambiguous.
All tool names follow a consistent verb_noun snake_case pattern, using get_* for direct retrieval, list_* for enumerations, and scope_/search_/register_ for specific actions. There is no mixed casing or inconsistent verb styles.
13 tools is well within the ideal 3-15 range and each tool earns its place, covering discovery, retrieval, computation, and account management without redundancy. The count feels proportionate to the server's apparent scope.
The tool surface covers the full domain of a live signal wire: discovery (facets, data sources, fusion products, plans), retrieval (latest, by id, via scope, via search, related), derived intelligence (fused signal), and account/identity management (registration, billing). No obvious dead ends or missing lifecycle operations.
get_billing_profileAInspectReport 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what the tool returns (BILL, CREDIT, NOTE lines) and under what circumstances the NOTE line appears (unauthenticated or not claimed), providing useful behavioral context beyond a simple 'get profile' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the primary purpose front-loaded in the first phrase. Every detail adds value: identity, account, plan, limits, and edge cases. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description is thorough: it covers the resolved identity, plan grants, specific limits, and error states. It could mention the exact format of the returned lines, but the provided depth is sufficient for an agent to select and 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 tool has zero parameters, so the baseline is 4. The description does not need to elaborate on parameters. It correctly focuses on output and behavior instead.
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 reports the resolved agent identity, funded account, plan, and various limits. It uses a specific verb ('Report') and resource ('billing profile'), and distinguishes itself from sibling tools like get_plans by focusing on the caller's current entitlements rather than plan catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (check what you are entitled to before proceeding), but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The purpose is clear, but guidance on selection is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_facet_manifestAInspectRead 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?
With no annotations, the description carries the full burden and does it well: it discloses scope ('covers two facet keys only'), truncation ('truncates the topic tail under each domain'), ranking, and the fact that it returns structure, not signal content. This gives the agent a clear behavioral model beyond the empty input 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 three sentences, each serving a distinct purpose: what the response is, how to use it in a workflow, and when to switch to list_facets. It is slightly metaphorical ('map to read first', 'shape of the wire') but front-loaded with the core result and free of redundant 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 parameterless tool with no output schema, the description fully covers the expected return shape (two-level tree, counts, ranking), its limitations (only domain/topic, truncated), and the recommended workflow. It also clarifies what the tool does not provide (signal content), making it complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so no parameter documentation is needed. Baseline for 0 params is 4; the description also makes clear there is no filter input required.
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: '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.' It clearly distinguishes this tool from sibling list_facets by stating the manifest covers only domain and topic, while list_facets provides 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?
It explicitly states when to use: '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 also names an alternative for when the full facet vocabulary is needed: 'call list_facets instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fused_signalAInspectCompute 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?
No annotations provided, so description carries full burden. It discloses that results cite sources, absent products have no live inputs, cross-source products are derived from time-alignment, and some indicators are from Team plan with NOTE lines for withheld ones. It doesn't mention rate limits or auth, but for a data computation tool this is strong behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, front-loading the core purpose and then providing specific usage examples. It's longer than typical but every sentence adds value, explaining edge cases and product-specific nuances. Slightly verbose but justified by the complexity of the product enum.
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 tool has 1 optional parameter, no output schema, and no annotations, the description is remarkably complete. It explains the output format (method + citations), absence semantics, cross-source derivation, product-specific guidance, and plan-based withholding behavior. An agent can use this tool effectively without additional context.
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% (the only parameter 'product' is fully described with enum and description). The description adds meaning by explaining the omit behavior and the significance of certain products (e.g., seismic_solution_consensus, recession indicators), going beyond the schema's enum 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 clearly states the tool computes derived intelligence products from the live wire, with each result citing its method and source signals. It distinguishes from siblings by noting list_fusion_products lists the catalogue, while this tool computes products for the current window.
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 guidance: pick one product or omit for all; a product absent means no live inputs; list_fusion_products for full catalogue; read seismic_solution_consensus before acting on single magnitude; read both recession indicators; NOTE line explains withheld indicators. This is exemplary 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.
get_latest_signalsAInspectFetch the most recent live signals from the wire in token-efficient CWF format, optionally filtered to one collection.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of signals to return (default 20, max 100) | |
| 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. | |
| 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?
No annotations are provided, so the description must carry the burden. It mentions the token-efficient CWF return format and optional collection filtering, but does not disclose pagination behavior, limit defaults, or the effect of the relate option.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core action ('Fetch the most recent live signals') and efficiently packs in format and filtering details without any unnecessary 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?
With three optional parameters and no output schema, the description covers the main purpose and return format (CWF) but could be more explicit about limit and relate behaviors. However, those are already in the schema, so the description is reasonably 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 three parameters are well described in the schema (100% coverage). The description's phrase 'optionally filtered to one collection' simply restates the collection parameter, adding little 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 uses a specific verb 'Fetch' and names the resource 'most recent live signals from the wire', with an optional collection filter. This clearly differentiates from siblings like search_signals and get_related_signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving latest live signals but does not explicitly contrast with alternatives like search_signals or get_fused_signal. There is no 'when to use' or '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.
get_plansAInspectList 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 whether a refusal is worth escalating to your principal instead of parsing a pricing page. Returns one CWF PLAN line per plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the return format (one CWF PLAN line per plan) and the data fields included. It implies a read-only operation via 'List', which is sufficient for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: the first states the main function, the second provides use-case context, and the third specifies the return format. No redundant wording.
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 covers purpose, return content, format, and rationale. It is complete and self-contained for its complexity.
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 is empty with 0 parameters, so the baseline is 4. The description adds context by emphasizing the tool is machine-readable and requires no input parameters, which is helpful.
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 lists plans, their costs, and what they raise (call ceiling, row budget, commercial indicator set). This is specific and differentiates from sibling tools like get_billing_profile or get_facet_manifest, which focus on other aspects.
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 provides context on when to use it: to decide whether a refusal is worth escalating, avoiding manual parsing of a pricing page. It doesn't explicitly mention alternatives among siblings, but the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_signalAInspectFetch 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?
With no annotations, the description carries full behavioral disclosure. It clearly explains the row-budget rationale, the two-minute live window turnover, and that the error message distinguishes between aging-out and a typo—important behavioral context for an AI agent deciding whether to trust a result or retry.
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 provides rationale, alternatives, and error semantics in a structured two-paragraph format. Every sentence contributes meaningful guidance; there is no filler or repetition that could be removed.
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 lacking an output schema and annotations, the description is self-contained: it explains the tool's unique value, parameter format, live-window behavior, error handling, and sibling alternatives. This is sufficient for an agent to select and invoke the tool correctly without further context.
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 describes the parameter with 100% coverage, including the accepted formats. The description repeats this information without adding new semantic details beyond the schema, so it meets the baseline for high schema coverage.
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 'Fetch one signal by its id, when you already know which one you want', which is a specific verb and resource with clear intent. It explicitly distinguishes from siblings by contrasting this tool's single-row return with other read tools that return bounded sets, and it names alternatives like search_signals and scope_signals for finding signals.
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 provides explicit when-to-use guidance: 'when you already know which one you want'. It also tells the agent when not to use it and what to use instead ('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') and even warns about time-based staleness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_data_sourcesAInspectList 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?
With no annotations, the description carries the full burden. It discloses the output format ('Returns one SRC line per source') and scope ('feeding the wire'), but does not mention safety, rate limits, or failure behavior. The verb 'List' implies read-only, but concrete behavioral details are limited.
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?
Two sentences with no wasted words. The first sentence states the core purpose and fields, the second specifies the return format. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers purpose and return format adequately. The term 'SRC line' is unexplained, and sorting/pagination are not addressed, but the tool is simple enough that this is a minor gap.
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% for the single optional parameter (signal_type), with a clear description in the input schema. The tool description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('data-source endpoints feeding the wire'), and specifies the included fields (provider, signal type, country, cadence, license). This specificity distinguishes it from sibling tools like list_facets or get_latest_signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for enumerating data sources but provides no explicit when-to-use guidance or alternatives. It does not mention exclusions or compare with related list tools, relying on the verb 'List' to convey context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_facetsAInspectList 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?
With no annotations, the description carries full behavioral burden. It discloses the exhaustive and potentially long nature (hundred-odd values), the flat list structure with counts, labels for place ids, and guarantees all returned values are accepted by scope_signals. This goes beyond basic listing and sets accurate expectations about token cost and output shape.
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?
Although longer than a typical description, every sentence earns its place: first sentence states purpose and output, second provides critical usage caveats and alternatives. The structure is front-loaded with the main definition and then rich guidance, with no redundant content.
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 no output schema and no annotations, the description fully compensates by explaining return contents (flat list, counts, labels), scope of keys, length expectations, and relationship to sibling tools. It is complete enough for an agent to understand what the tool returns and when to use it.
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 schema coverage is 100% by default. The baseline for 0 parameters is 4; the description appropriately uses space to explain output semantics rather than parameters, which adds value for consumers.
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 lists the full filter vocabulary, enumerates all keys (lang, country, region, domain, topic, severity, provider, coverage, place), and specifies output format (flat list with signal counts and human-readable labels). It also distinguishes itself from sibling get_facet_manifest by emphasizing it is the exhaustive listing.
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?
Provides explicit usage guidance: use when the manifest is insufficient or counts are needed, otherwise prefer get_facet_manifest. Also gives specific advice on handling place facet ids by recommending scope_signals for filtering by name rather than raw id. This clearly covers when to use and when not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_fusion_productsAInspectList 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?
With no annotations, this description carries the full burden. It discloses that the tool reads no signals and returns the same answer (static catalogue), explains attribution types ('published' vs 'composed'), and clarifies plan-gating behavior that prevents 'gated' products from being mistaken for missing ones. This goes well beyond basic expectations.
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 strictly necessary, but every sentence carries distinct information: purpose, usage vs sibling, behavioral contrast, attribution meanings, and plan-gating rules. Some phrases ('wire that is still warming up') are metaphorical but memorable. It is not front-loaded in the most terse way, rewards careful reading, yet earns its length.
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 must explain what the tool returns. It does: each row includes index/model, signal collections, plan requirement, and attribution type. It also explains how to interpret the row set and the NOTE line for gated products. This gives a complete picture for a zero-parameter catalogue 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 tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds no parameter-specific meaning (none exist) but does describe the content of returned rows, which is more relevant to output semantics than parameters.
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 clearly specifies the verb 'List' and the resource 'every derived intelligence product pronto can compute,' with attributes (index/model, signal collections, plan requirement). It also distinguishes this catalogue tool from get_fused_signal, making the purpose unmistakable.
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?
Explicitly tells the reader to read this tool to discover whether pronto computes a needed product, then call get_fused_signal to compute it. Contrasts the two tools ('different questions') and explains when a product might appear here but not in get_fused_signal, providing clear decision-making guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_agentAInspectCreate 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; what raises them is being claimed by a funded account. The response includes a claim code and a URL — hand those to whoever holds the budget, and 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 no annotations provided, the description carries the full burden of disclosing behavior. It reveals that registration creates a new identity, returns an API key, includes a claim code/URL, and that unauth-less limits apply until claimed. It also explains credential rotation and the inability to rotate without a public key, adding valuable context beyond a simple 'registers an agent' statement.
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 organized into three focused paragraphs: purpose, plan implications, and optional key behavior. Each sentence adds important information, and the first sentence front-loads the core purpose. While slightly long, it remains efficient given the complexity of the authorization/claiming model.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description is the sole source of behavioral and return-value information. It covers what the response includes (API key, claim code, URL), the initial limits, and the process for upgrading via a funded account. The rotation guidance further rounds out the picture, making the description effectively complete for an agent to understand 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 schema already fully describes both parameters with 100% coverage. The description supplements the public_key parameter by explaining why you would provide it (rotation) and the consequences of not providing it (must re-register). It does not add anything for label, but the schema's label description is already self-sufficient. This extra rationale warrants a 4.
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 clearly identifies the tool's function: 'Create your own identity on pronto and receive an API key.' This distinguishes it from the sibling tools, all of which are read-only data retrieval endpoints. The description further clarifies that registration does not grant a plan, removing ambiguity about its 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 description provides strong contextual guidance: it explains when to use the tool (to obtain an identity/API key for cross-session recognition) and what to do next (claim code for plan activation). It also warns about the consequences of not providing a public key. However, it does not explicitly mention when not to use it or compare it to alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scope_signalsAInspectSelect 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) | |
| filter | No | Facet expression, e.g. "country:JP domain:climate severity:high". Call list_facets to see 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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: facet combination semantics (same-key OR, cross-key AND), the fact that matching is on metadata not text, and that the whole slice is returned regardless of wording. It does not describe ordering, pagination, or error behavior, but the core filtering behavior is well explained.
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 reasonably concise for a tool with subtle semantics, leading with the core purpose and then giving usage guidance. The final sentence 'A locale filter alone cannot answer this question' is cryptic and seems out of place, but otherwise content is purposeful and well-ordered.
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 covers the core concepts necessary to use the tool: what facets are, how they combine, and how it differs from search. The schema covers parameter details including the hint to call list_facets. With no output schema and no required params, this is adequately complete. The only minor gap is not mentioning the relate parameter, but that is in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds meaningful extra semantics for the filter parameter, explaining the OR/AND combination rules with a concrete example. It does not discuss limit or relate, but the schema handles those.
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 gives a clear purpose: selecting a slice of signals by facet metadata rather than full-text search. It explicitly contrasts with search_signals, saying this tool is for when you can name the slice, while search is for subject words. That is strong differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('Use this when you can name the slice you want') and when to use search instead ('reach for search when you have a subject word and no category to name'). It also gives concrete examples and names the alternative sibling. The final fragment about locale filter is slightly cryptic, but the main guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_signalsAInspectFind 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 |
|---|---|---|---|
| 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' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full disclosure. It reveals detailed behaviors: coverage of facets and multilingual text, inflection matching, lexical (not semantic) matching, ranking by query overlap, and error-on-no-match behavior. This far exceeds typical descriptions.
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 yet well-structured, with each paragraph covering a distinct aspect (usage boundary, covered fields, matching rules, ranking/errors). The purpose is front-loaded, and no sentence is superfluous.
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 covers usage, behavior, ranking, errors, and mentions the return format as 'CWF lines'. However, without an output schema, the return format is left vague; a bit more detail on what CWF lines contain would make it fully complete. Still, the coverage is strong.
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 fully documents both parameters (100% coverage), so the baseline is 3. The description adds meaning beyond the schema by explaining the query's lexical nature, inflection handling, and facet coverage, but the limit parameter remains schema-only. This elevates the score to 4.
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 'Find signals by the words in them', clearly identifying the verb and resource. It also explicitly differentiates from the sibling scope_signals by contrasting category-based slicing versus word-based search, so the tool's 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool ('Use this when you are looking for a subject... and cannot name it as a category') and when not to, naming scope_signals as the alternative with reasoning. This is a model of usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
