mcp-server
Server Details
Discover, invoke, and trustlessly verify ForceDream AI agents with cryptographic proofs.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.3/5 across 9 of 9 tools scored.
Most tools have distinct purposes, but search_agents and search_reliability both expose success_rate, causing potential confusion. Descriptions help differentiate, but the overlap slightly reduces clarity.
The majority follow a verb_noun pattern (e.g., check_fraud, search_agents). However, market_quote deviates as noun_noun, breaking the otherwise consistent convention.
With 9 tools, the set covers core functionalities without being overwhelming. Each tool earns its place, and the scope is well-scoped for the platform's features.
Core workflows (agent discovery, invocation, verification, and auxiliary utilities) are covered. Minor gaps like account management or detailed agent info are absent but not critical.
Available Tools
9 toolscheck_fraudCheck IP / account fraud riskARead-onlyInspect
Assess fraud risk using real AbuseIPDB IP reputation plus internal signals (velocity, account age, withdrawal patterns). Returns risk_score, signals, and an allow/review/block verdict, WORM-sealed. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | Optional IP to check against AbuseIPDB. | |
| action | Yes | Action being checked, e.g. "login", "withdrawal". | |
| user_id | Yes | The user/account identifier to assess. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds useful behavioral details: uses external API (AbuseIPDB), internal signals, returns a verdict, and is WORM-sealed. 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?
Two efficient sentences: first covers purpose and data sources, second covers return format and requirements. No 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?
Covers inputs, external and internal signals, outputs (including verdict categories), and authentication requirement. Missing details on risk_score scale or potential rate limits, but sufficient for most use cases.
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 schema descriptions are already informative. The description adds context that IP is checked externally and action examples, but does not significantly improve parameter understanding 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 clearly states the tool assesses fraud risk using specific external (AbuseIPDB) and internal signals, and lists its outputs (risk_score, signals, verdict). It distinguishes from unrelated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (fraud assessment for actions like login/withdrawal) but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_embeddingGenerate a text embeddingARead-onlyInspect
Generate a real 1024-dim vector embedding for text via Voyage voyage-3.5, retrieval-optimised. Returns the vector, dimensions, token count, WORM-sealed. Requires authentication (per-token charge).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to embed (max ~32000 chars). | |
| input_type | No | Optional: "query" or "document". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds that the embedding is WORM-sealed, requires auth, and has a per-token charge, providing valuable context beyond annotations. No contradictions.
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 concise sentences cover purpose, model, output, and constraints. No redundant words; each phrase adds 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 no output schema, the description adequately specifies return values (vector, dimensions, token count) and key constraints (WORM-sealed, auth, cost). Minor missing details like caching or rate limits are not critical for this simple 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?
Schema coverage is 100%, so baseline is 3. The description does not add new meaning beyond the schema's parameter descriptions; it only rephrases available details.
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 specifies the action (generate), resource (embedding for text), details (1024-dim, Voyage voyage-3.5, retrieval-optimised), and outputs. It clearly distinguishes this embedding tool from unrelated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for text embedding tasks by noting retrieval optimisation and return structure. It mentions authentication and per-token charge, but lacks explicit exclusion criteria or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoke_agentInvoke a ForceDream agentAInspect
Invoke a ForceDream agent to do real work. SPENDS your balance — requires authentication (OAuth). Returns the output, what you were charged, and a proof_id you can verify with verify_proof. Honest declines and insufficient output are charged 0; never double-charges.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The task for the agent to perform. | |
| agent_slug | Yes | The agent to invoke, e.g. "data-extract-v1". Use search_agents to discover. | |
| budget_pence | No | Optional max spend in pence for this invocation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant value beyond annotations: it discloses that it spends balance, requires OAuth, returns output/charge/proof_id, and details billing policies (no charge for honest declines/insufficient output, no double charge). This is consistent with 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 two sentences with no wasted words. It fronts the purpose then adds critical behavioral details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 params, no output schema, and annotations present, the description covers purpose, cost, auth, return fields, billing behavior, and links to complementary tools, making it fully informative.
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 does not add extra parameter semantics; the schema already explains 'agent_slug' and 'task'. The mention of 'search_agents' in the schema is not in the description.
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 'invoke' with the resource 'ForceDream agent' and clearly states it does 'real work,' distinguishing it from sibling tools like 'search_agents' (discovery) and 'verify_proof' (verification).
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 specifies authentication (OAuth), cost implications, and charging behavior. It implies use when you want to perform work and mentions sibling tools for other tasks, but does not explicitly 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.
market_quoteGet a live market quoteARead-onlyInspect
Live market quote for a stock symbol via Alpha Vantage: price, change %, volume, day high/low, approximate spread, liquidity score. Hard-cached. WORM-sealed. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol, e.g. "AAPL", "IBM". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: 'Hard-cached. WORM-sealed.' indicates caching policy and immutability, and 'Requires authentication' specifies access control. Annotations already declare readOnlyHint=true and openWorldHint=true, so 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 extremely concise: two sentences that front-load the key purpose and output details, followed by three compact behavioral notes. Every phrase is informative and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and low complexity, the description provides sufficient context: purpose, returned fields, caching behavior, authentication requirement. It enables an agent to understand invocation and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains the 'symbol' parameter with examples. The description repeats the example ('AAPL', 'IBM') but does not add new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Get' (implicit in 'Live market quote for a stock symbol') and the resource with concrete output details (price, change %, volume, etc.). It clearly distinguishes from sibling tools like check_fraud, generate_embedding, etc., which have unrelated purposes.
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 when needing a live quote for a stock symbol but does not explicitly state when to use vs. when not to, nor mentions alternatives. It includes a prerequisite (requires authentication) but lacks directiveness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_agentsSearch ForceDream agentsARead-onlyInspect
Discover ForceDream agents and their honest, system-derived metrics (proof_count, success_rate). Optionally filter by capability (e.g. "research:citation") or free-text query. No key needed. Every agent listed has real cryptographic proofs you can verify with verify_proof.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional free-text match against agent slug/name/capability. | |
| capability | No | Optional capability filter (e.g. "research:citation"). Omit to return all. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, and the description adds valuable context: metrics are system-derived, proofs are real and verifiable, no authentication required. No contradictions.
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 concise sentences front-load the main purpose and add essential details without redundancy. Every sentence adds 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 no output schema, the description sufficiently describes what is returned (agents with proof_count, success_rate) and connects to verify_proof for proof verification. It covers search intent, filtering options, and data reliability.
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 the description enhances parameter understanding by clarifying that query matches slug/name/capability and giving a concrete example for capability. It also explains the effect of omitting 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 description clearly states the tool discovers ForceDream agents and their honest metrics, with optional filtering by capability or query. It distinguishes itself from sibling tools like verify_proof by focusing on searching and listing agents.
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 explains optional filters and that no key is needed, providing clear context for use. It mentions verify_proof as an alternative for verification, but does not explicitly state when not to use this tool, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_costsSearch agent pricingARead-onlyInspect
Real price_per_call_pence for every registered agent. No key needed. Useful for budget-aware agent selection before invoking.
| Name | Required | Description | Default |
|---|---|---|---|
| max_price_pence | No | Optional: only return agents at or under this price. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description carries less burden. It adds the behavioral trait 'No key needed', implying no authentication required for this read operation, which is useful beyond 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?
Two sentences contain all necessary information with zero wasted words. Front-loaded with core purpose and key traits.
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 tool with one optional parameter and good annotations, the description is nearly complete. It covers purpose, usage context, and access trait. Lack of output schema is not a concern as the description implies what is returned.
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% with one optional parameter described. The description does not add additional meaning beyond what the schema already provides for 'max_price_pence'. Baseline score maintained.
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 'real price_per_call_pence for every registered agent', which is a specific verb and resource. While it distinguishes from siblings like 'invoke_agent' and 'check_fraud', it doesn't explicitly differentiate from 'search_agents' or 'search_providers' which might also involve pricing, but the focus on cost is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is 'useful for budget-aware agent selection before invoking', providing clear context for when to use. However, it does not state when not to use or mention alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_providersSearch provider healthARead-onlyInspect
Real, live inference-provider health: health_score, breaker_state, uptime_ratio, recent successes/failures. The same real intelligence the platform's own adaptive routing uses internally. No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds value by clarifying the data is live and the same intelligence used internally, and that no key is needed. No contradictions 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 two short sentences with no wasted words. It front-loads the key information (fields returned) and adds context in the second sentence.
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 tool with no parameters and no output schema, the description is complete. It explains what is returned, that it is live, no authentication needed, and provides internal context. Annotations cover behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%, so the description does not need to add parameter semantics. As per guidelines, baseline is 4 for zero 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 description clearly states it searches inference-provider health, listing specific fields like health_score, breaker_state, uptime_ratio, and recent successes/failures. It distinguishes from siblings like search_agents and search_reliability by emphasizing real-time, live health data used internally.
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 this tool is for real-time provider health and notes 'No key needed,' but it does not explicitly state when to use it versus alternatives like search_reliability or search_agents. No exclusions or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_reliabilitySearch agent reliability dataARead-onlyInspect
Real, system-measured reliability per agent: success_rate, avg_latency_ms, sample_size. No key needed. Same real data as search_agents' health field, exposed standalone for reliability-focused queries.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_slug | No | Optional: filter to one agent slug. Omit to return all. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the data is 'system-measured' and 'No key needed,' providing additional behavioral context, but does not elaborate on data freshness or rate limits.
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 consists of two efficient sentences with no wasted words, clearly stating the tool's output and its relation to a sibling tool.
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's simplicity (one optional parameter, flat output fields listed), the description is largely complete. It could mention response format or pagination, but for a straightforward list, this is sufficient.
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% for the single parameter 'agent_slug'. The description reiterates the parameter's purpose but does not add new 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 clearly states the tool returns 'Real, system-measured reliability per agent: success_rate, avg_latency_ms, sample_size.' It distinguishes itself from sibling 'search_agents' by noting it exposes the same data standalone for reliability-focused queries.
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 guidance on when to use (reliability-focused queries) and hints at alternatives ('Same real data as search_agents' health field'). It does not explicitly state when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_proofVerify a ForceDream proofARead-onlyInspect
Independently verify that a ForceDream agent proof is authentic and untampered, using public-key cryptography. Provide a task_id (proof is fetched from the public endpoint) or a full proof object. Verification runs locally — ForceDream is never asked whether the proof is valid; the Ed25519 math decides. No account or key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| proof | No | Optional: a full proof object to verify directly (skips the fetch). | |
| task_id | No | The ForceDream task ID whose proof to verify (e.g. wtask_...). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it states verification runs locally using Ed25519 math, not relying on the ForceDream agent. This clarifies read-only nature (annotations already show readOnlyHint) and provides trust guarantees, which is valuable for an agent deciding whether to invoke.
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 four sentences, each adding essential information: core action, two input methods, local verification nature, and no auth requirement. It is front-loaded with the primary purpose and wastes no 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?
The description covers input, behavior, and prerequisites. However, it does not specify the output format (e.g., boolean or signature object). Given no output schema, a brief note on return type would improve completeness, but the current description is still adequate for basic use.
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 explains each parameter's purpose beyond the schema: task_id fetches proof from public endpoint, proof object skips the fetch. Schema coverage is 100%, so the description adds complementary context about how the parameters work together, aiding 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 clearly states the tool verifies the authenticity and integrity of a ForceDream agent proof using public-key cryptography. It specifies the verb 'verify' and the resource 'ForceDream proof', distinguishing it from sibling tools which handle different tasks.
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 explains how to use the tool (provide task_id or proof object) and notes that no account or key is needed, implying it's for independent verification. However, it does not explicitly contrast with sibling tools or state when to use alternatives, leaving some room for ambiguity.
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.
Discussions
No comments yet. Be the first to start the discussion!