Prediction market probability oracle for AI agents. 26 tools across 1000+ live markets from Kalshi and Polymarket. No install required, connect directly via streamable HTTP.
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 3.8/5 across 9 of 9 tools scored.
Most tools have distinct purposes, but list_markets and search_markets overlap in market discovery. However, list_markets is for browsing with filters while search_markets is for keyword/natural language queries, so the distinction is clear enough.
All tools follow a consistent verb_noun pattern, with most using 'get_' for data retrieval and a couple using 'list_' and 'search_' for market discovery. The naming is uniform and predictable.
With 9 tools, the server is well-scoped for its purpose of providing prediction market data. Each tool serves a distinct function, and the count is within the ideal range.
The tool surface covers core operations: authentication, market listing/search, real-time probability, historical data, sentiment, trending, aggregate stats, and usage monitoring. A minor gap is the lack of a dedicated market detail endpoint, but get_probability already returns metadata.
generate_api_keyAInspectGenerate a free TeleKash API key. Free tier: 100 calls/day. Save the key — shown once.
| Name | Required | Description | Default |
|---|---|---|---|
| owner_id | Yes | Agent or user identifier | |
| owner_email | No | Contact email (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It adds important non-obvious behaviors: 'Save the key — shown once' (one-time display) and 'Free tier: 100 calls/day' (rate limit). These go beyond the basic 'generate' action. However, it does not mention whether the key is tied to the owner, if it can be regenerated, or what happens if lost—details that could be relevant for a credential-creating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and every word earns its place: it states the action, the resource, the free-tier limit, and the critical 'shown once' warning. No filler, no redundancy. It is concise and front-loaded with the primary 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 the tool's simplicity (2 params, no output schema), the description covers the essential context: what is generated, the free tier limit, and the one-time display behavior. It does not explicitly describe the return value format (e.g., 'returns the key as a string'), but 'shown once' implies the key is returned. It could also mention how the key should be used with other TeleKash tools, but the brief scope makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage for both parameters (owner_id: 'Agent or user identifier', owner_email: 'Contact email (optional)'). The description adds no additional parameter-level meaning beyond what the schema provides. Per the guidance, a baseline of 3 is appropriate when schema coverage is high and the description doesn't compensate further.
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 verb and resource: 'Generate a free TeleKash API key.' It also adds scope ('free tier: 100 calls/day') and distinguishes this tool from all siblings, which are read-only get/list/search operations. The purpose is unambiguous and clearly differentiated.
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: you call this when you need an API key. It includes useful context about the free tier and rate limit, but does not explicitly state when to use this vs alternatives (e.g., 'use this to obtain credentials before calling other TeleKash endpoints') or mention any prerequisites or exclusions. The usage context is present but mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_historyAInspectGet historical probability changes and trend data for a market over 1h/24h/7d/30d.
| Name | Required | Description | Default |
|---|---|---|---|
| market_id | Yes | Market UUID or external_id | |
| timeframe | No | Time range (default: 24h) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the operation is a 'Get' (read-only) and lists timeframes, which conveys the core behavior. However, it does not mention data freshness, pagination, or the structure of 'trend data,' leaving some behavioral details undisclosed.
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 sentence, front-loaded with the verb and key resource, and contains no wasted words. It is concisely structured and easy to scan.
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?
No output schema exists, so the description should explain return values. It mentions 'historical probability changes and trend data' but does not detail the shape, units, or components of the trend data. This leaves some ambiguity, though it is adequate for a simple two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, including descriptions for market_id and an enum with a default for timeframe. The description repeats the timeframe enums ('1h/24h/7d/30d') but adds no extra meaning beyond what the schema already provides, so the baseline 3 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 begins with 'Get,' a specific verb, and identifies the resource as 'historical probability changes and trend data for a market' with explicit timeframes (1h/24h/7d/30d). This clearly distinguishes it from sibling tools like get_probability (which likely returns current values) and get_market_stats.
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 historical trend analysis with timeframe options, providing clear context on when to use it. However, it does not explicitly name alternatives or state when not to use it, but the word 'historical' effectively differentiates it from current-probability tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_statsAInspectGet aggregate statistics — total markets, categories, sources, and volume.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It explains the returned data categories but does not mention side effects, authentication, rate limits, or whether the stats are computed in real-time. The verb 'Get' implies read-only, but this is not explicit.
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 sentence, front-loaded with the action and resource, and immediately lists concrete output components. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately explains what is returned. It could be slightly more precise about what 'volume' refers to (e.g., trading volume) or whether stats are global across all markets, but given the low complexity, it is largely 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?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter-specific information because there are none to document; it instead lists what the returned statistics contain, which is not parameter semantics but contributes to overall clarity.
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 a clear action ('Get') and resource ('aggregate statistics'), enumerating the exact components returned (total markets, categories, sources, volume). This distinguishes it from siblings like list_markets and search_markets, which are likelier to return individual market records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a high-level market overview, and the term 'aggregate' contrasts with sibling tools, but there is no explicit guidance on when to choose this tool over alternatives or any exclusions. The context is sufficient for a simple stats endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_probabilityAInspectGet real-time probability for any prediction market outcome. Returns YES/NO probabilities (0-100%), volume, liquidity, and market metadata from Kalshi and Polymarket.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Natural language search query (alternative to market_id) | |
| market_id | No | Market UUID or external_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing the output data (YES/NO probabilities, volume, liquidity, metadata) and data sources (Kalshi and Polymarket). It does not disclose potential rate limits or auth requirements, but it provides sufficient behavioral context for a read-only data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core purpose, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description adequately covers the return values and sources. It doesn't specify exact response structure, but it provides enough context for expected 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?
Schema coverage is 100% (both 'query' and 'market_id' have descriptions), so the baseline is 3. The tool description adds no additional parameter semantics 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 names a specific verb ('Get') and resource ('real-time probability for any prediction market outcome') and distinguishes itself from siblings like get_market_stats and get_sentiment by focusing on YES/NO probabilities, volume, liquidity, and metadata from Kalshi and Polymarket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool: when real-time probabilities for prediction market outcomes are needed. However, it does not explicitly name alternative tools or state when not to use it, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sentimentAInspectGet AI-powered sentiment analysis (-1 to 1), recommendation, and confidence for a market.
| Name | Required | Description | Default |
|---|---|---|---|
| market_id | Yes | Market UUID or external_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the output range and components, which is useful, but lacks details about possible side effects, errors, latency, or external dependencies. For a simple read-like tool this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly written sentence conveys all required information without redundancy. 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?
With only one parameter and no output schema, the description sufficiently conveys the primary return values. It could be improved by mentioning the response format or potential errors, but overall it is complete enough for a straightforward sentiment analysis 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 description coverage is 100% with the market_id parameter well documented. The description reinforces that the parameter identifies a market but adds no extra semantic detail 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 specifies the action ('Get'), the resource ('sentiment analysis'), and the output scope including range (-1 to 1), recommendation, and confidence. It clearly distinguishes from siblings like get_probability or get_market_stats.
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 a market') but does not state when to use this tool versus alternatives or any exclusions. No explicit comparison to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trendingBInspectMarkets with biggest probability swings — momentum detection for trending events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max markets (default: 10, max: 25) | |
| timeframe | No | Lookback window (default: 24h) |
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 not disclose whether this is a read-only operation, any rate limits, or what the response format looks like beyond implying a list of markets. The term 'probability swings' is undefined, leaving room for ambiguity about sorting and thresholds.
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, front-loaded sentence that conveys the core idea without unnecessary words. It is appropriately brief for a simple 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?
Despite the lack of an output schema, the description sufficiently implies the return value is a list of markets ranked by probability swings. Given the tool's low complexity (two optional parameters, no nested objects), the description is nearly complete, though it could benefit from mentioning that results are likely sorted by swing magnitude.
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%: both parameters (limit and timeframe) have descriptions, including defaults and constraints. The tool description adds no additional parameter context, but the schema already provides sufficient 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 states it returns 'Markets with biggest probability swings' and adds 'momentum detection for trending events,' which clearly identifies the tool's function as identifying trending markets by probability changes. It distinguishes from siblings like list_markets or get_market_stats by focusing on probability swings, though it could be more explicit with a 'Get' verb.
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 phrase 'momentum detection for trending events' implies the tool is for detecting trending markets, but there is no explicit guidance on when to use it versus alternatives such as get_market_stats or get_sentiment. It does not mention any exclusions or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageAInspectCheck API usage, rate limits, and tier status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. The verb 'check' implies a read-only operation, but it does not explicitly state safety, response format, or any side effects. Additional context like authentication or rate limit behavior is absent.
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 sentence that directly states the purpose without any filler or redundancy. It is concise and front-loaded, mentioning all key aspects.
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 lists the three main output areas (usage, rate limits, tier status), which is adequate. However, it could mention the response format or whether it applies to the current authentication context, but this is not critical given the tool's simplicity.
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 trivially 100%. The description does not need to add parameter semantics; the baseline of 4 applies since no parameters exist to document.
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 'check' and identifies the exact resources: 'API usage, rate limits, and tier status.' This clearly distinguishes it from sibling tools like get_market_stats or get_sentiment, which focus on different 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 provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_marketsBInspectBrowse prediction markets across 7 categories with filtering and sorting. 500+ markets from Kalshi, Polymarket, and Metaculus.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max markets (default: 10, max: 50) | |
| source | No | Filter by source | |
| sort_by | No | Sort order | |
| category | No | Filter by category (default: all) | |
| jurisdiction | No | Filter by jurisdiction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful context like '500+ markets from Kalshi, Polymarket, and Metaculus' and mentions filtering/sorting capabilities. However, it does not disclose behavior such as pagination, return format, or rate limits, which is a moderate gap for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains zero fluff. Every clause adds value: the scope (browse prediction markets), features (filtering/sorting), and scale (500+ markets from three sources). It is highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters, no output schema, and no annotations. The description gives a high-level overview but falls short on providing enough context for an agent to anticipate the response shape or how to combine parameters effectively. It is adequate for a simple browse endpoint, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'filtering and sorting' is generic and does not add meaning beyond what each parameter's description already provides. It does not explain the semantics of any specific parameter, so it neither improves nor degrades the schema's clarity.
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 'Browse prediction markets' which is a specific verb and resource. It mentions 7 categories, filtering, sorting, and sources. However, it doesn't explicitly distinguish from the sibling 'search_markets' beyond the broader 'browse' concept, so it's clear but not fully differentiated.
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 given about when to use this tool versus alternatives like 'search_markets'. The description only states what it does ('Browse... with filtering and sorting') but provides no exclusions, prerequisites, or context for when it's preferred. This leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_marketsAInspectSearch 500+ prediction markets by keyword or natural language query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 10, max: 50) | |
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It accurately implies a read-only search operation but does not mention result ordering, pagination, or that it returns only matching markets. This is adequate for a simple search tool but lacks explicit safety or performance details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that immediately communicates the tool's function and input type. No filler or redundant 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?
The description is sufficient for a simple 2-parameter search tool, but since there is no output schema, it would be helpful to mention what the response contains (e.g., market IDs, titles, probabilities). Without that, the agent may not know what to expect.
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 describes both parameters (query and limit) with 100% coverage. The description adds semantic value by specifying that the query accepts natural language, not just keywords—which goes beyond the schema's 'Search query' placeholder.
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 the action ('Search'), the resource ('prediction markets'), and the scope ('500+'). It also distinguishes from sibling tools like list_markets by emphasizing keyword or natural language querying, 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?
The description gives clear context for when to use this tool: when searching markets by keyword or natural language. It does not explicitly mention when not to use it or name alternative tools like list_markets for browsing, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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!
