anyapi
Server Details
Hundreds of scraping & data APIs through one key. USD pay-per-request, normalized schemas, failover.
- Status
- Unhealthy
- 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.6/5 across 7 of 7 tools scored.
Every tool has a clearly distinct purpose: browsing, searching, retrieving full schemas, quoting, executing, reading cached results, and checking balance. No two tools overlap.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., list_apis, get_balance, run_api), making the set predictable and easy to navigate.
With 7 tools, the set is well-scoped for the domain of an API marketplace. Each tool handles a distinct step in the workflow without unnecessary bloat or missing essentials.
The tool surface covers the full lifecycle of discovering, quoting, executing, and retrieving results from APIs. Minor gaps include no tool for managing API keys or viewing past runs, but these are not critical for core functionality.
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?
The description discloses that heavy entries may return large responses, which is a key behavioral trait. No annotations are provided, but this disclosure partially compensates. However, it does not specify whether the operation is read-only or any authentication needs.
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, with the purpose front-loaded and no redundant information. 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 a simple single-parameter tool with an output schema mentioned, the description covers the purpose and a key behavioral note thoroughly. No critical gaps remain.
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 the single parameter sku_id adequately described. The description adds minimal extra meaning beyond the schema (mentioning SKU and heavy responses), so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full definition of one API by SKU, including normalized schemas. It distinguishes itself from siblings like list_apis and search_apis by focusing on a single API by SKU.
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 advises that heavy entries return large responses and suggests using run_api with fields/max_items/summary as an alternative, offering clear context for when to use this tool vs. run_api.
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?
With no annotations provided, the description fully discloses the behavior: it retrieves the remaining wallet balance (read-only operation) and requires a valid API key. For a simple 0-parameter tool, this is adequate 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?
The description is two sentences, front-loading the key action and resource, with no unnecessary words. 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 the tool has no parameters and an output schema exists (not shown but present), the description is complete. It covers the essential requirement and action, and the context from sibling tools makes it clear when to 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 input schema has zero parameters, so the baseline score is 4. The description does not need to add parameter semantics since there are none.
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 a specific verb 'Get' and resource 'remaining wallet balance' clearly indicating what the tool does. It is distinct from sibling tools like get_api, list_apis, and run_api which deal with APIs rather than wallet balance.
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 states the requirement 'Requires a valid AnyAPI key,' which gives clear context on prerequisites. It does not explicitly mention when to use or alternatives, but the simplicity of the tool and differentiation from siblings makes the usage context sufficiently clear.
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?
With no annotations, description carries full burden; it discloses return content (lightweight summaries, no descriptions/schemas) and cost implication, but lacks details on pagination or 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?
Two sentences: first sentence states core purpose and content, second provides filter options and sibling references. 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 output schema exists, description covers key info: what is returned, why it's cheap, filtering, and alternative tools. Complete for a listing 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 covers both parameters fully with descriptions; tool description restates them without adding extra meaning, so 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?
Clearly states the tool browses available APIs with specific fields (id, name, category, USD pricing) and distinguishes itself from siblings search_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 says when to use (for lightweight summaries, cheap across whole catalog) and when not to (use search_apis for descriptions or get_api for full schemas).
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?
With no annotations provided, the description fully discloses that the tool is free and safe (no charge, no execution), validates input, and returns specific cost fields. 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?
The description is highly concise (two sentences), front-loading the purpose and immediately useful information. Every sentence contributes meaning without waste.
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 the tool has only 2 parameters with full schema coverage, an output schema is implicitly described (returns maxCostUsd, minCostUsd, breakdown), and context signals indicate a well-defined tool, the description is complete and enhances understanding.
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 both parameters. The description adds value by explaining that sku_id and input should match those used for run_api, and that input is the exact payload for pricing validation, going 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 it gets the exact price of a run_api call before execution, emphasizing it is free, requires no key, and does not charge or execute. It distinguishes from siblings like run_api by highlighting the pre-execution, no-cost nature.
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 recommends using this tool before run_api to check pricing and validate input, and notes that it is free and requires no key. It could be more explicit about 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.
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?
With no annotations, the description carries the full burden. It discloses that results are cached ~15 min, private to the key, and that an expired id returns result_expired. It also states the operation is read-only and does not incur additional charges, which is critical behavioral info.
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 three sentences with no wasted words. The first sentence encapsulates the core value proposition, the second gives parameter usage, and the third adds caching details. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex input schema and an output schema, the description covers all essential aspects: purpose, parameter usage pattern, cache behavior, error condition (result_expired), and privacy. No gaps remain for an agent to misuse the 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%, so baseline is 3. The description adds value by explaining why these parameters exist (e.g., 'read the rest of the rows' for max_items, 'slice a large field with jq') and how they reshape results, providing practical use-case context beyond the schema definitions.
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: to dig deeper into a paid run without re-running or paying, by re-shaping the cached result. It distinguishes itself from sibling tools like run_api and get_api by focusing on result re-use.
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: use after a paid run to access cached data without extra cost. It specifies the result_id from run_api as input, which provides guidance on proper tool chaining. It does not explicitly list when not to use, but the 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?
No annotations provided, so description carries full burden. It discloses authentication, credit charging, response size concerns, and that trimming options do not affect cost. Also mentions jq sandbox limits (250ms/2MB) and failure behavior. However, lacks details on general error handling or rate limits, preventing a top score.
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 paragraph that efficiently covers purpose, prerequisites, behavior, optimization, and validation guidance. Every sentence adds value, though slightly verbose in listing trimming options. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no annotations, the description addresses authentication, costing, response trimming, and alternative (quote_api). Output schema exists, so return structure is not required. Minor missing details on error handling beyond jq, but overall sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds valuable context: dotted paths for 'fields', sandbox behavior for 'jq', definition of 'summary' as structural outline, and '_truncated' note for 'max_items'. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes an API by SKU with a normalized input payload, distinguishing it from siblings like quote_api and get_api. The verb 'Execute' and resource 'API by SKU' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions authentication requirements (AnyAPI key as Bearer token), cost behavior (charges credits on success), and response optimization (fields, max_items, summary). Provides clear directive: 'Use quote_api first... to see the exact price and validate your input without charging.' This effectively guides when to use this tool versus alternatives.
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 the description fully bears the burden. It discloses behavioral traits: returns descriptions (not schemas), relevance ranking, relevance floor dropping weak matches, ranking type (semantic vs keyword), and that heavy entries require specific parameters in run_api.
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 comprehensive yet well-structured, front-loading the core purpose and then detailing behavior, parameters, and context. It is slightly verbose but each sentence earns its place, with no superfluous 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?
Given the complexity of a search tool with ranking and relevance, and no annotations, the description covers all necessary aspects: purpose, usage, parameter semantics, behavioral nuances, and inter-tool relationships. It is complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: explains that limit caps matches and total reports relevant before cap, query is free-text over name/slug/description, and category is an optional slug. It clarifies the implications of relevance scoring and total count.
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 APIs by meaning and keyword, returns ranked matches with descriptions, and distinguishes itself from siblings (list_apis for browsing, get_api for full schemas). The verb 'Search' and resource 'APIs' are specific.
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 when to use this tool ('discover the right SKU'), mentions alternatives (list_apis, get_api), and provides guidance on narrowing queries with category and adjusting limit. It also suggests how to handle heavy results.
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!