Real-time crypto market intelligence for AI agents. Live price, funding rate, open interest, buy/sell ratio, fear/greed, orderflow, and OHLCV history across 20 exchanges and 24 tokens. Address risk scoring included.
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 7 of 7 tools scored.
The five market_* tools overlap in purpose—all provide market analysis for tokens—but each has a distinct focus (macro regime, full diligence, light coverage, orderflow, snapshot). The overlap is manageable, but an agent could hesitate between market_snapshot and market_orderflow since both include orderflow data. address_risk and api_info are clearly distinct.
Naming conventions are inconsistent: address_risk, api_info, market_orderflow, and market_snapshot are noun_noun compounds, while market_analyze is noun_verb, and market_full/market_light are noun_adjective. There's no consistent verb_noun or pattern, making it harder to infer tool behavior from names alone.
Seven tools is well-scoped for a market analysis server. Each tool covers a reasonable slice of functionality without excessive redundancy, and the count fits the typical 3-15 tool sweet spot.
The tool set covers the major aspects of market structure analysis: macro regime, snapshot, orderflow, full due diligence, lightweight coverage for any token, wallet risk, and API info. Minor gaps exist—such as no dedicated historical data tool or token-level risk beyond what market_full provides—but agents can work around them.
address_riskABefore you transact, know who you're dealing with. Paste any wallet address — EVM or Solana, auto-detected — and get entity label (exchange, protocol, flagged mixer), risk level, account age, transaction history, and top holdings. Flags: new_account, unverified_contract, dormant, high_throughput. REST equivalent: POST /analyze/address (0.25 USDC).
Args:
address: EVM address (0x...) or Solana address (base58)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value beyond this by disclosing output specifics (entity label, risk level, flags like 'new_account', 'dormant'), auto-detection of chain, and even the API cost (0.25 USDC). This enriches the behavioral model without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a use-case hook, a clear list of outputs, flag examples, cost/REST info, and an args line. Every sentence adds relevant detail, and the length is appropriate for a tool with one parameter and rich output. The only slight redundancy is the 'Args' section repeating the schema, but it adds format specifics.
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 an output schema present, the description needn't detail all return fields, but it still lists key outputs and flags. It covers cross-chain support, example flags, and cost, making it sufficiently complete for a single-parameter read-only tool. Minor omissions like rate limits or error handling are not critical given the annotations and output 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?
Schema coverage is 0%, so the description carries full responsibility for the single parameter. It provides the accepted formats: 'address: EVM address (0x...) or Solana address (base58)' and notes auto-detection. This goes beyond the schema's bare string type and gives the agent concrete input guidance.
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's function: 'get entity label, risk level, account age, transaction history, and top holdings' for any wallet address. It explicitly covers both EVM and Solana with auto-detection, and the 'REST equivalent' line adds a concrete action. The purpose is distinct from the market-focused sibling tools, making this 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 opening phrase 'Before you transact, know who you're dealing with' provides a clear when-to-use context, positioning this as a pre-transaction risk assessment. It does not explicitly name alternatives or when-not-to-use scenarios, but the siblings are all market-related, so the differentiation is implied. The cost and REST reference also give practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
api_infoAREST API access for autonomous agents — pricing, quick start, and migration guide.
Call this when: building a trading bot, deploying an autonomous agent, hitting
the MCP rate limit, or running 24/7 without a human in the loop. The MCP tier
(what you're using now) is free via Smithery, rate-limited to 60 calls/minute
per IP, and good for testing. The REST API is for production: pay per call in
USDC; paid endpoints are rate-limited to 60 calls/minute and 200 calls/hour
per wallet. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds context that it is a guide/informational tool, explains the free vs paid tiers, rate limits (60/min per IP, 200/hour per wallet), and that no API key is required. This enriches the behavioral picture beyond the annotations without contradiction.
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 paragraphs, first sentence states purpose. Additional sentences provide concrete use cases and tier comparisons. Each sentence earns its place, though it could be slightly tightened without losing 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?
For a zero-parameter informational tool with an output schema, the description fully covers when to use it, why, pricing details, rate limits, and migration path. No significant gaps given the low complexity and existing structured metadata.
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%. Baseline for 0-param tools is 4; the description adds contextual value by explaining what the info covers (pricing, quick start, migration), even though parameter-level semantics are not applicable.
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 provides 'REST API access for autonomous agents — pricing, quick start, and migration guide.' It goes beyond a generic verb+resource by listing specific contents and explicit use cases (building a trading bot, hitting the MCP rate limit). This distinguishes it from sibling market-data 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?
Explicit 'Call this when' section lists concrete scenarios (building trading bot, deploying autonomous agent, hitting rate limit, running 24/7). It also contrasts the MCP tier (free/testing) with the REST API (production/paid), giving clear guidance on when this informational tool is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_analyzeAIs macro with you or against you? Get the current regime (bull/bear/risk_on/risk_off/choppy), directional signal and confidence, and macro context (DXY, VIX, fear/greed) before entering a position. Data-only, no LLM latency. coverage disclosed per token. REST equivalent: POST /analyze/market (0.25 USDC).
Args:
token: Token symbol (BTC, ETH, SOL, XRP, ADA, DOGE, AVAX, LINK, BNB, ATOM,
DOT, ARB, SUI, OP, LTC, AMP, ZEC)
context: Optional historical context window ('7d' or '30d'). Adds percentile rankings.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| context | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare it read-only, idempotent, and non-destructive. The description adds behavioral context: it is 'data-only, no LLM latency,' covers cost via 'REST equivalent: POST /analyze/market (0.25 USDC),' and discloses data coverage per token. These details go beyond the annotations and help the agent understand performance and cost implications.
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 well-structured, starting with a purpose question, listing outputs, key features, cost, and then arguments. It is slightly longer than necessary due to the rhetorical question, but every sentence adds value. It earns a 4.
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 an output schema present and a clear description covering purpose, usage context, params, and performance/cost, the tool description is sufficiently complete. The agent can confidently decide when and how to invoke 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 schema provides only types and requiredness. The description adds meaning: it lists the accepted token symbols and explains that context is an optional window ('7d' or '30d') that adds percentile rankings. This fully compensates for the 0% schema description 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 clearly states the tool's function: it provides the current market regime (bull/bear/risk_on/risk_off/choppy), directional signal, confidence, and macro context. The verb 'get' and resource 'current regime' make the purpose explicit, distinguishing it from sibling tools like market_snapshot or market_light by focusing on macro analysis.
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 a clear use case: 'before entering a position.' It also mentions it is 'data-only, no LLM latency' which suggests suitability for quick pre-trade checks. However, it does not explicitly compare with alternatives or state when not to use it, so it gets a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_fullAFull pre-trade diligence in one call. Gets all market and orderflow data, then makes a grounded judgment: BULLISH/BEARISH/NEUTRAL stance, ACCUMULATION/DISTRIBUTION signal, LOW/MODERATE/HIGH/CRITICAL risk level, and a verdict that cites actual data values — not vibes. Use when you want a single answer rather than assembling the pieces yourself. coverage disclosed per token. REST equivalent: POST /analyze/full (0.75 USDC).
Args:
token: Token symbol (BTC, ETH, SOL, XRP, ADA, DOGE, AVAX, LINK, BNB, ATOM,
DOT, ARB, SUI, OP, LTC, AMP, ZEC)
context: Optional context window ('7d' or '30d').
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| context | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds value by disclosing the tool makes a grounded judgment (not just raw data), cites actual data values, discloses coverage per token, and includes cost/REST info. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear intro, use-case sentence, and delimiter-separated args. It is informative without being excessively verbose, though the fragment 'coverage disclosed per token' is slightly awkward.
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 an output schema present and annotations covering safety, the description sufficiently covers purpose, usage, parameters, and cost. It could elaborate on the response structure, but the output schema likely handles that. The ambiguous coverage statement 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 0%, but the description compensates with an Args section listing supported token symbols and the optional context window ('7d' or '30d'). It adds meaning beyond the schema, though it could clarify default behavior when context is omitted.
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 performs full pre-trade diligence, aggregating market and orderflow data to produce a stance, signal, risk level, and verdict. It distinguishes itself from siblings by emphasizing a single consolidated answer rather than assembling pieces manually.
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 'Use when you want a single answer rather than assembling the pieces yourself,' giving clear usage context. It does not name specific alternatives or provide when-not guidance, but the context is sufficient for distinguishing from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_lightAStructured coverage for ANY listed token — price, momentum, extremes, signals, project info, exchange listings, and optional LLM brief. Broader coverage than market_snapshot (which is limited to 26 supported tokens), shallower data (no orderflow, whale, liquidation, or signal fields). Use for tokens outside the BTC/ETH/SOL/etc. core set. Symbol disambiguation is automatic (top-by-volume match). REST equivalent: POST /data/light (0.05 USDC).
Rate limit: 10 calls / minute per IP (lower than other tools — this fans out to
a paid upstream provider). Cached responses up to 24h are served without
refetching; agents needing fresher data should use the paid REST endpoint.
Args:
symbol: Token ticker — 1 to 10 alphanumeric characters (e.g. PEPE, WIF,
FLOKI, BONK). Case-insensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | full | |
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses rate limits (10 calls/min per IP), 24h caching behavior, automatic symbol disambiguation (top-by-volume match), and that it fans out to a paid upstream provider. These are meaningful behavioral details not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear paragraphs for purpose, usage, rate limits, and args. It is somewhat lengthy but every sentence adds value (comparison, rate limit, caching, param details). No fluff, but could be slightly more compact.
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 an output schema exists, return values are covered. The description addresses what the tool does, when to use it, limitations (no orderflow etc.), rate limits, caching, and symbol format. The only notable gap is the undocumented 'brief' parameter, 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 description thoroughly explains the symbol parameter (1-10 alphanumeric, case-insensitive, examples), but does not explain the 'brief' parameter at all. Since schema coverage is 0%, the description should compensate for both parameters; it covers symbol but leaves 'brief' ambiguous, resulting in only partial compensation.
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 what the tool does: 'Structured coverage for ANY listed token — price, momentum, extremes, signals, project info, exchange listings, and optional LLM brief.' It also differentiates from sibling market_snapshot by noting broader coverage but shallower data, making its purpose 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?
Explicitly says 'Use for tokens outside the BTC/ETH/SOL/etc. core set,' and contrasts with market_snapshot (limited to 26 tokens, lacks certain fields). It also advises using the paid REST endpoint for fresher data, providing clear 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.
market_orderflowAIs this move backed by real buyers, or is it two venues painting tape? See CVD direction, buy/sell ratio, whale clustering, liquidation pressure, and how many of 20 live exchanges are accumulating vs distributing. Volume concentration (HHI > 0.6) flags wash trading or thin manipulation. Data-only. orderflow coverage disclosed per token. REST equivalent: POST /analyze/orderflow (0.50 USDC).
Args:
token: Token symbol (BTC, ETH, SOL, XRP, ADA, DOGE, AVAX, LINK, BNB, ATOM,
DOT, ARB, SUI, OP, LTC, NEAR, TRX, BCH, SHIB, HBAR, TON, XLM, UNI, AAVE,
AMP, ZEC)
context: Optional context window ('7d' or '30d'). Adds percentile rankings.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| context | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable context beyond annotations by disclosing that orderflow coverage varies per token and that HHI > 0.6 flags wash trading, providing useful data-quality caveats. No contradiction found.
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 includes a rhetorical question upfront, which adds engagement but is not strictly necessary. The metrics list and Args section are concise and well-organized, though the question could be trimmed for tighter structure. Overall 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?
With an output schema present, the description does not need to detail return values. It covers purpose, key metrics, REST equivalent, parameter semantics, and data coverage caveats. The only missing element is explicit usage guidance relative to siblings, but the tool is otherwise well-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by listing all valid token symbols and explaining the context parameter's meaning ('Adds percentile rankings'). This goes well beyond the schema, giving the agent everything needed to manually construct correct 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 clearly identifies an orderflow analysis tool with specific metrics (CVD direction, buy/sell ratio, whale clustering, liquidation pressure) and explicitly notes it as 'Data-only'. It distinguishes itself from sibling tools by focusing exclusively on orderflow, making its 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?
No guidance is provided on when to use this tool versus alternatives like market_analyze or market_full. The description mentions data-only and coverage but does not state selection criteria or contrast it with siblings, leaving usage context ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_snapshotAWhat's the market doing right now? Price, funding rate, CVD, whale activity, and liquidation pressure in one call — 16 fields, no LLM overhead. Feed directly into your own models or decision logic. orderflow coverage disclosed per token. REST equivalent: POST /data (0.20 USDC).
Args:
token: Token symbol (BTC, ETH, SOL, XRP, ADA, DOGE, AVAX, LINK, BNB, ATOM,
DOT, ARB, SUI, OP, LTC, NEAR, TRX, BCH, SHIB, HBAR, TON, XLM, UNI, AAVE,
AMP, ZEC)
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond these: the exact field count (16), the REST equivalent (POST /data) with a specific cost (0.20 USDC), and a per-token orderflow coverage disclosure, which hints at potential data limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a question-led opening, a summary of contents, a REST equivalence note, and an Args section. It avoids verbose explanations, though the phrase 'orderflow coverage disclosed per token' is somewhat cryptic and could be clearer.
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 one parameter and an output schema provided, the description doesn't need to detail return values. It includes practical details like cost, token list, and coverage disclosure, making it sufficiently complete for a simple snapshot tool. However, it doesn't explicitly map to sibling alternatives, which could be improved.
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 only defines 'token' as a string with no description (0% schema coverage). The description compensates fully by listing all supported token symbols (BTC, ETH, SOL, etc.) and implying uppercase format, which is essential for correct invocation.
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 immediately answers 'What's the market doing right now?' and enumerates specific data categories (Price, funding rate, CVD, whale activity, liquidation pressure). It distinguishes itself from sibling market tools by emphasizing raw data ('16 fields, no LLM overhead') suitable for feeding into models, implying a snapshot tool rather than an analysis or orderflow-specific tool.
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 clear context for when to use it: when you need raw market data directly for models or decision logic without LLM overhead. However, it does not explicitly state when not to use it or name alternatives like market_analyze or market_orderflow, leaving the choice among siblings somewhat implicit.
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!
