AnyAPI
Server Details
Hundreds of scraping and data APIs through one gateway — one key, USD pay-per-request, normalized schemas, automatic failover.
- 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.4/5 across 7 of 7 tools scored. Lowest: 3.9/5.
Each tool has a clearly distinct purpose: getting API details, balance, listings, quotes, cached results, execution, and search. There is no ambiguity or overlap.
All tools follow a consistent verb_noun snake_case pattern (e.g., get_api, list_apis, run_api). No mixing of styles.
7 tools is well-scoped for an API marketplace, covering discovery, cost estimation, execution, and result retrieval without being too few or too many.
The tool set covers the core workflows (browse, search, get details, quote, execute, read results, check balance). Minor missing features like key management or run history, but not critical for the main purpose.
Available Tools
7 toolsget_apiAInspect
Get the full definition of one API by SKU, including its normalized input and output JSON schemas. Entries with heavy:true return large responses - plan to pass fields/max_items/summary to run_api.
| Name | Required | Description | Default |
|---|---|---|---|
| sku_id | Yes | the API SKU slug to describe |
Output Schema
| Name | Required | Description |
|---|---|---|
| scraper | Yes | the API definition with input/output schemas |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that entries with heavy:true return large responses and hints at output size management, but lacks details on authentication, rate limits, or error behavior. Provides moderate but not exhaustive transparency.
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, zero wasted words. Purpose is front-loaded, and the second sentence adds a valuable behavioral note. Ideal conciseness.
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 output schema exists, return values don't need elaboration. Description covers the key behavioral nuance (heavy responses) and the tool's single parameter. Minor gap: no mention of prerequisites (e.g., SKU must exist). Still largely 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 already describes sku_id as 'API SKU slug' with 100% coverage. Description reiterates the parameter's role but adds no new semantics beyond stating the purpose. Baseline score of 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?
Description clearly states the tool retrieves the full definition of one API by SKU, including input/output schemas. It uses a specific verb-resource pairing and distinguishes from sibling tools like list_apis (list all) and search_apis (search).
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?
Description provides context on when to use this tool (to get a specific API's definition) and offers a practical hint about heavy=true responses, suggesting next steps with run_api. However, it does not explicitly differentiate from alternatives like quote_api or read_result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceAInspect
Get the remaining wallet balance (in USD) for the AnyAPI key supplied as a Bearer token. Requires a valid AnyAPI key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| balanceUsd | Yes | remaining wallet balance for this API key, in USD |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral details. It states the authentication requirement and that the balance is in USD, but lacks information on error handling (e.g., invalid key), rate limits, or confirmation that it is a read-only operation. The description leaves significant gaps for an agent to infer behavior.
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, concise sentence that efficiently conveys the purpose and requirement. Every word is informative, with no redundancy or unnecessary detail.
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 (zero parameters, output schema present), the description sufficiently covers the essential information: what it does (gets balance), in what currency (USD), and the authentication requirement. The output structure is supported by an output schema, so no additional description of return values is needed.
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?
There are no parameters in the schema, so the parameter semantics dimension defaults to a baseline of 4. The description adds value by clarifying that the API key is supplied as a Bearer token, which is authentication-related, but not a parameter. This is adequate for zero-parameter tools.
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 that the tool retrieves the remaining wallet balance in USD for the AnyAPI key. It uses a specific verb ('Get') and resource ('wallet balance'), and the sibling tools (get_api, list_apis, run_api) are distinct in function, so differentiation 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 mentions that a valid AnyAPI key is required, which is a prerequisite. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. The context is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_apisAInspect
Browse available AnyAPI APIs as lightweight summaries (id, name, category, USD pricing) - no descriptions or schemas, so it stays cheap even across the whole catalog. Optionally filter by free-text query and/or category. Use search_apis to find APIs by keyword with descriptions, or get_api for one API's full schemas.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | optional free-text filter over API name and description | |
| category | No | optional category slug to filter by |
Output Schema
| Name | Required | Description |
|---|---|---|
| scrapers | Yes | matching APIs (lightweight summaries: no description or schemas) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses lightweight nature, cost efficiency, and that it excludes descriptions/schemas. Lacks mention of pagination or rate limits, but overall clear about behavior.
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, no fluff. Front-loaded with the tool's purpose and key differentiator (lightweight summaries). Clearly 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?
For a simple list tool with two optional parameters and an output schema, the description covers all needed context: returned fields, lightweight nature, filtering options, and alternatives. Complete enough for agent decision-making.
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 baseline 3. Description says 'optionally filter by free-text query and/or category', which merely restates schema descriptions without adding new meaning.
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?
Clearly states it lists APIs as lightweight summaries with specific fields (id, name, category, USD pricing). Distinguishes from siblings search_apis and get_api, which provide descriptions or full schemas.
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 when to use this tool (browsing lightweight summaries) and when to use alternatives (search_apis for keyword search with descriptions, get_api for full schemas). Also mentions optional filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_apiAInspect
Get the exact price of a run_api call BEFORE running it - free, no key required, nothing is charged or executed. Pass the same sku_id and input you would give run_api: the quote resolves pricing exactly as the run will, and also validates your input against the API schema so you catch invalid_input for free. Returns maxCostUsd (the ceiling reserved), minCostUsd (the likely charge), and the base/per-item breakdown explaining why they differ.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | the exact input payload you plan to pass to run_api; the quote resolves pricing the same way the run will | |
| sku_id | Yes | the API SKU slug to price |
Output Schema
| Name | Required | Description |
|---|---|---|
| exact | Yes | true when the price is exact (minCostUsd == maxCostUsd): a flat SKU or a sealed page |
| baseUsd | Yes | fixed cost per call in USD, charged regardless of count |
| pricing | Yes | a one-line human explanation of how this call is priced |
| maxCostUsd | Yes | the most this call can charge - the reserve held before running |
| minCostUsd | Yes | the likely charge - the cheapest route serves first |
| perItemUsd | Yes | marginal cost in USD per billable unit (see perItemUnit); 0 for a flat SKU |
| perItemUnit | No | the unit perItemUsd is charged per: 'result' (default) or an input unit like 'username' for input-priced SKUs |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses key behaviors: free, no key required, nothing is charged or executed, validates input. This is sufficient for an agent to understand the tool's safety and side effects.
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?
Description is concise and front-loaded with the core purpose. Every sentence adds value: free nature, usage guidance, validation, and return structure. No wasted 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?
Given the presence of an output schema, the description still provides complete context: purpose, safety, validation, and return fields. It covers all necessary aspects for an agent to decide when to use this 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% with descriptions for both parameters. The description adds value by linking parameters to run_api, but does not significantly extend beyond the schema's meaning. 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?
Description clearly states the tool gets the exact price of a run_api call before execution, distinguishing it from sibling tools like run_api. Specific verb 'get' and resource 'price of a run_api call' are mentioned.
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?
Description indicates to use this tool before running run_api, as it says 'BEFORE running it' and 'Pass the same sku_id and input you would give run_api'. It does not explicitly exclude other uses 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.
read_resultAInspect
Dig deeper into a paid run WITHOUT re-running or paying again. Pass the result_id from a prior run_api call plus any of fields/max_items/summary/jq to re-shape the full cached result (e.g. read the rest of the rows, or slice a large field with jq). Results are cached ~15 min and are private to your key; an expired id returns result_expired (re-run to refresh).
| Name | Required | Description | Default |
|---|---|---|---|
| jq | No | optional: a jq expression to reshape the result; its output replaces 'output'. Example: '.data | {title, description, md: .markdown[:3500]}'. Sandboxed 250ms/2MB budget | |
| fields | No | optional: keep only these keys on each result item (dotted paths like 'author.name' descend into nested objects) | |
| summary | No | optional: return only a structural outline (top-level keys, item counts, per-field byte sizes) instead of the full data | |
| max_items | No | optional: cap the number of result items returned; a _truncated note reports how many were withheld | |
| result_id | Yes | the resultId returned by a prior run_api call (cached ~15 min) |
Output Schema
| Name | Required | Description |
|---|---|---|
| hint | No | optional nudge, present only on large untrimmed results, suggesting fields/max_items/summary to keep future responses out of your context |
| items | Yes | number of result rows returned. For per-result SKUs the per-item cost is charged against this; for input-priced SKUs (perItemUnit != result) the charge is per submitted input, independent of this count |
| output | Yes | normalized output payload |
| costUsd | Yes | amount charged to the wallet in USD |
| jqError | No | present only when a jq expression failed; output then holds the full unshaped result and this explains why the reshape did not apply |
| provider | Yes | the provider serving the request (AnyAPI) |
| resultId | No | opaque handle to the full result, cached ~15 min; pass it to read_result to dig deeper for free (no re-run, no charge). Absent when the result was too large to cache |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses key behaviors: results are cached ~15 minutes, private to your key, and an expired id returns result_expired. It also states no re-running or paying is needed. This covers the main behavioral traits.
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 (3 sentences) and front-loaded with the most important purpose. Every sentence adds necessary information without fluff.
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 that an output schema exists, the description does not need to explain return values. It adequately covers caching, privacy, and error case (result_expired), making the tool's behavior fully understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining usage: 're-shape the full cached result', 'read the rest of the rows', 'slice a large field with jq'. It provides an example for jq and clarifies the function of each parameter 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's purpose: 'Dig deeper into a paid run WITHOUT re-running or paying again.' It specifies the resource (cached result from run_api) and distinguishes it from siblings like run_api and list_apis.
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 instructs to pass result_id from a prior run_api call and mentions optional parameters. It implies when to use (to avoid re-running) and what happens if result expires (re-run needed). Could be more explicit about not using for new runs, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_apiAInspect
Execute an API by SKU with a normalized input payload. Requires a valid AnyAPI key as a Bearer token. Charges credits on success. Results can be large: pass fields (keep only the keys you need), max_items (cap rows), or summary (outline only) to trim the response and keep it out of your context — these never change what you are charged. Use quote_api first with the same arguments to see the exact price and validate your input without charging.
| Name | Required | Description | Default |
|---|---|---|---|
| jq | No | optional: a jq expression to reshape the result; its output replaces 'output' (multiple outputs collect into an array). Example: '.data | {title, description, md: .markdown[:3500]}'. Sandboxed 250ms/2MB budget; on failure the full result is returned with jqError. Does not change cost | |
| input | Yes | normalized input payload matching the API input schema | |
| fields | No | optional: keep only these keys on each result item (dotted paths like 'author.name' descend into nested objects). Shrinks the response without changing cost | |
| sku_id | Yes | the API SKU slug to execute | |
| summary | No | optional: return only a structural outline (top-level keys, item counts, and per-field byte sizes) instead of the full data. Does not change cost | |
| max_items | No | optional: cap the number of result items returned; a _truncated note reports how many were withheld. Does not change cost |
Output Schema
| Name | Required | Description |
|---|---|---|
| hint | No | optional nudge, present only on large untrimmed results, suggesting fields/max_items/summary to keep future responses out of your context |
| items | Yes | number of result rows returned. For per-result SKUs the per-item cost is charged against this; for input-priced SKUs (perItemUnit != result) the charge is per submitted input, independent of this count |
| output | Yes | normalized output payload |
| costUsd | Yes | amount charged to the wallet in USD |
| jqError | No | present only when a jq expression failed; output then holds the full unshaped result and this explains why the reshape did not apply |
| provider | Yes | the provider serving the request (AnyAPI) |
| resultId | No | opaque handle to the full result, cached ~15 min; pass it to read_result to dig deeper for free (no re-run, no charge). Absent when the result was too large to cache |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses credit charges on success, jq sandbox limits, trimming options not affecting cost, and behavior on jq failure. Lacks explicit mention of idempotency or rate limits, but covers core behavioral traits.
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 paragraph of ~100 words, front-loaded with purpose, then prerequisites, cost, trimming options, and recommendation. Every sentence provides essential information without redundancy.
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 all key aspects for a complex tool with 6 parameters and an output schema. Mentions result size concerns and trimming. Does not detail return format since output schema exists, but could clarify typical response size. Still highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant meaning beyond schema descriptions: jq output replacement and sandbox details, field dotted path syntax, summary structural outline, max_items truncation notification.
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 'Execute an API by SKU with a normalized input payload', specifying the action, resource, and input format. It distinguishes from sibling 'quote_api' by recommending its use prior to execution.
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 advises to 'Use quote_api first with the same arguments to see the exact price and validate your input without charging' and notes the requirement for a valid AnyAPI key as a Bearer token. Also explains when to use trimming parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_apisAInspect
Search APIs by meaning and keyword across name, slug, and description, returning matches WITH their descriptions (schemas omitted), ranked most relevant first. The targeted lookup to discover the right SKU: pass query (required), optionally category to narrow and limit to cap matches (default 25). Each result carries a relevance score in (0,1] relative to the top match; a relevance floor drops the weakly-matching tail, so total counts the relevant matches (before the limit) - if it is large, narrow your query. ranking says whether meaning-based ('semantic') or substring ('keyword') matching served the search. Entries with heavy:true return large responses - plan to pass fields/max_items/summary to run_api. Use list_apis to browse everything, or get_api for full schemas.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | optional cap on matches returned (default 25); 'total' reports how many relevant matches there were before the cap | |
| query | Yes | free-text search over API name, slug, and description | |
| category | No | optional category slug to narrow the search |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | number of relevant matches (after the relevance floor), before the limit cap - if this is large, narrow your query |
| ranking | Yes | 'semantic' when meaning-based ranking served this search, 'keyword' when it fell back to substring matching (relevance is coarser) |
| results | Yes | matching APIs with descriptions (schemas omitted), most relevant first |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses relevance score range, ranking type (semantic/keyword), total count meaning, and heavy entry implications. 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?
Well-structured with front-loaded purpose, but packs many details in one paragraph. Could be slightly more concise, but all sentences are valuable.
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 complexity (3 params, output schema, sibling tools), description covers usage, parameter behavior, output details, and side effects (heavy entries). Complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds meaning: explains query as targeted, category as narrowing, limit as cap with default, and clarifies total and ranking in context. Goes beyond 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 searches APIs by meaning and keyword, returns matches with descriptions (schemas omitted) ranked by relevance, and distinguishes from siblings like list_apis and get_api.
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 states when to use (targeted lookup for SKU discovery), parameters required (query) and optional (category, limit), and alternatives (use list_apis for browsing, get_api for full schemas). Also advises on heavy entries.
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!