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.2/5 across 9 of 9 tools scored. Lowest: 3.6/5.
Each tool serves a distinct function: billing, facet hierarchy, fused products, raw signals, related signals, data sources, facet values, filtering, and keyword search. Even where tools touch facets or signals, their purposes are clearly separated and the descriptions reinforce the differences.
All tools follow a consistent verb_noun pattern using snake_case. The verbs are get, list, scope, and search, each describing the action precisely. Minor singular/plural variations do not affect predictability.
With 9 tools, the server covers a complete workflow without bloat. Each tool is purposeful and earns its place, and the count is ideal for the scope of a live data wire.
The tool set is comprehensive for the domain. It covers metadata, retrieval, exploration, analytics, and account management, with no obvious gaps that would prevent an agent from accomplishing a task.
get_billing_profileAInspectRetrieve the active credit balance and billing tier of the agent. Returns a single CWF BILL line.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a key behavioral trait: 'Returns a single CWF BILL line.' However, the term 'CWF BILL' is jargon and not explained, and the description does not explicitly confirm read-only behavior or mention potential edge cases like missing profiles.
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, front-loaded with the action, and contains no fluff or repeated information. Every word contributes to understanding the tool's purpose and output.
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 zero-parameter getter with no output schema, the description covers the essential purpose and return format. The only gap is the unexplained 'CWF BILL' jargon and lack of notes on edge cases, but overall it is sufficiently complete for such a trivial 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, so the schema is trivially 100% covered. The description does not need to add parameter semantics, and the baseline for zero-parameter tools is 4. It adds no confusing or missing param info.
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 retrieves the active credit balance and billing tier of the agent. The verb 'Retrieve' specifies the action, and the resource (billing profile) is distinct from sibling tools which focus on signals, facets, and data sources.
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 purpose makes its usage context clear (billing queries), but the description does not explicitly state when to use this tool versus alternatives or mention any exclusions. Sibling tool names are unrelated, so the context is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_facet_manifestAInspectReturn the facet hierarchy of the live wire with signal counts. Each line states a domain, a topic under that domain, and how many signals are there. Read the manifest once. Then choose a scope offline and call scope_signals or search_signals once, instead of guessing a filter. 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 transparency burden. It discloses that the manifest is structural only, not signal content, and advises one-time use, implying a read-only snapshot. However, it does not explicitly state side effects or the nature of 'live wire' beyond the implication, so a small gap remains.
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 sentences, each adding value: purpose, output structure, usage advice, and scope. It is front-loaded and free of fluff, though slightly wordy in places.
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 tool with no output schema, the description thoroughly covers the return format (domain, topic, count), usage pattern, and limitations. It also names sibling tools for follow-up actions, making it complete in 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 tool has zero parameters, so the schema is trivially covered. The description adds no parameter details, but none are needed; the baseline of 4 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 it returns the facet hierarchy of the live wire with signal counts, using a specific verb and resource. It also distinguishes itself from siblings like list_facets by emphasizing that it shows structure, not signal content.
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 instructs when to use the tool: read the manifest once, then choose a scope offline and call scope_signals or search_signals. It also warns against guessing a filter, giving clear guidance on alternatives and workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fused_signalAInspectCompute the derived intelligence products from the live wire. Each product implements a published index or model, and every result states its formula citation and lists the source signals it was derived from.
Single-source products cover space weather, air quality, apparent temperature, occupational heat stress, sea state, earthquake energy, fire danger, and asteroid close-approach energy.
Macro products cover the 12-month recession probability from the yield curve and the Sahm rule recession-onset nowcast. These two disagree on purpose: the first forecasts, the second says a downturn has probably already begun. Read both.
Cross-source products exist only because independent publishers are time-aligned on one wire, and no upstream API emits them: grid carbon arbitrage, grid supply diversity, aviation network stress, sovereign debt dynamics, the Taylor rule policy gap, official FX reference-rate disagreement, the Preston curve of life expectancy against income, the measles immunity gap, and the share of world news coverage by topic and publishing country.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context: results state formula citations and source signals, and the two macro products intentionally disagree. However, it does not mention whether the operation is safe/read-only, rate limits, or any potential side effects. The return format is also unspecified, but the domain context is helpful.
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 and multi-paragraphed, with product enumerations that largely duplicate the schema's parameter values. It is well-structured by category but not optimally concise; the redundancy with the schema makes it longer than necessary, though the domain explanations add some value.
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 absence of an output schema, the description does a good job explaining the nature of the products, their interpretations, and the reasoning behind cross-source products. It gives substantial domain context. However, it leaves out the actual response format (e.g., list vs object, field details), which prevents a perfect score.
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 fully describes the optional 'product' parameter with all allowed values and its filter semantics, achieving 100% schema coverage. The tool description itself adds no new parameter-level information beyond what the schema provides, so the baseline score of 3 for high schema coverage is appropriate.
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: 'Compute the derived intelligence products from the live wire.' It clearly distinguishes this from sibling signal-focused tools by emphasizing derived/fused products and listing detailed categories (single-source, macro, cross-source). The purpose is unambiguous and well-scoped.
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?
Usage context is implied through the product categories, but the description never explicitly says when to use this tool vs alternatives like get_latest_signals or search_signals. It provides no exclusions or when-not-to-use guidance, though the focus on derived products hints at the appropriate scenario.
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) | |
| 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 carries the transparency burden. It discloses the source ('live signals from the wire'), the output format ('token-efficient CWF format'), and optional filtering. However, it does not describe ordering, pagination, or any potential side effects, though 'Fetch' implies a read-only operation.
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 a single, focused sentence that front-loads the core purpose ('Fetch the most recent live signals') and then adds essential qualifying details. Every phrase earns its place without redundancy or unnecessary elaboration.
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 read-only tool with two optional parameters and no output schema, the description is reasonably complete. It tells the agent what data source is used, the format, and the filtering option. Some lack of detail on return structure or CWF specifics is acceptable given the low complexity, but a bit more behavioral detail would have made it fully self-contained.
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 the baseline is 3. The description adds marginal value by emphasizing 'most recent' and 'optionally filtered to one collection', but these concepts are already largely represented in the parameter descriptions. No additional syntax or format details are provided beyond what the schema offers.
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 a specific action ('Fetch'), a resource ('live signals from the wire'), and a distinguishing scope ('most recent', 'token-efficient CWF format', optional filtering). It effectively differentiates from sibling tools like search_signals or get_related_signals by focusing on recency and live data.
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 when to use this tool: for the most recent live signals, with an optional collection filter. It also distinguishes itself from alternative tools by mentioning 'live' and 'token-efficient CWF format', though it does not explicitly name alternatives or state 'when not to use'.
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 every facet value currently present on the wire with its signal count and, for place ids, a human-readable label, so you can discover what is filterable right now instead of guessing. 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?
No annotations are provided, so the description carries the full burden. It discloses what the tool returns (every facet value, signal count, human-readable labels for place ids) and adds an important caveat about place facets being gazetteer ids. While it doesn't mention read-only behavior explicitly, the verb 'List' and the absence of side effects imply it. The contextual detail goes beyond a simple list 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: the first delivers the main action and rationale, the second provides a necessary caveat. It is front-loaded, free of filler, and every sentence contributes useful 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?
For a zero-parameter tool with no output schema, the description is fully adequate. It explains what the tool does, why it's useful, and how to handle place facets—covering all essential context for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is 4. The description adds value by explaining the output semantics (signal counts and labels), which is helpful given the lack of structured parameter information. No parameter clarification is needed.
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 identifies the resource as 'facet value' with details about signal count and human-readable labels. This clearly distinguishes it from siblings like get_facet_manifest, which likely focuses on definitions rather than current values.
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 frames the tool as a discovery mechanism ('so you can discover what is filterable right now instead of guessing') and provides a specific alternative: 'filter them by name with scope_signals rather than by the raw id.' This gives clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scope_signalsAInspectFilter the live wire to a precise slice with facet tags. Facets cover language, country, region, domain, topic, severity, provider, and coverage. 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly explains the OR/AND semantics for different facet keys and provides a concrete example, which is valuable beyond the schema. It does not mention rate limits or return structure, but for a filtering tool, the facet logic is the key behavioral trait.
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 concise at four sentences and front-loaded with the core purpose. The example is helpful and well-integrated. The metaphor 'live wire' is slightly informal but not confusing, so it earns a 4 rather than a 5.
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 tool with no output schema and moderate complexity from facet combination semantics, the description provides enough context to understand how to construct filters. It covers key behaviors like OR/AND grouping and gives an example. It could add explicit 'when to use' guidance, but overall it is fairly 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?
Schema coverage is 100%, and both parameters are described. The description adds meaning beyond the schema by explaining how the 'filter' string expression works, including the OR/AND combination rules and an example. This enriches the schema's brief expression template.
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 filters live signals using facet tags, with a specific verb ('Filter') and resource ('live wire'). It distinguishes itself from siblings by emphasizing facet-based slicing, but it does not explicitly contrast with search_signals or get_latest_signals, so it falls short of a 5.
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 multi-faceted filtering and gives an example to clarify when facet combinations are needed. However, it does not explicitly state when to prefer this tool over alternatives like search_signals or get_latest_signals, only noting that a locale filter alone is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_signalsAInspectSearch recent signals by keyword. 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?
With no annotations, the description carries full burden and delivers richly: it discloses lexical vs. semantic matching, inflection behavior, ranking priority, error behavior when no terms match, the meaning of empty results, and output format (CWF lines). No contradictions with annotations exist.
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?
Every sentence earns its place: one-sentence purpose, then compactly structured details on coverage, matching, ranking, error behavior, and return format. It is dense but not verbose, and front-loaded with the core purpose.
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 non-trivial search tool with no output schema and no annotations, the description thoroughly covers search scope, matching rules, ranking, error semantics, and return format. It is complete enough for an agent to invoke correctly and interpret results.
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 baseline is 3. The description adds value beyond schema by explaining how the query parameter behaves semantically (e.g., 'Japan' reaches non-English content) and emphasizing that exact word forms matter. This enhances understanding beyond basic field descriptions.
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+resource: 'Search recent signals by keyword.' It clearly differentiates from sibling tools by detailing what fields it covers (places, observations, summaries, identifiers, country/topic facets) and specific behaviors like inflection and synonym handling. This makes the purpose unmistakable and distinct.
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 usage context, like 'Use the words the source would have used' and explains matching semantics. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select it over non-search tools like get_latest_signals or get_fused_signal.
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!
