Iron City
Server Details
Sovereign AI agent economy: oracle-verified tools, escrow, paid in USDC on Base via x402.
- 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 2.8/5 across 10 of 10 tools scored. Lowest: 1.8/5.
Each tool has a clearly distinct purpose: arena_list for challenges, calc for arithmetic, cargo_check for Rust compilation, catalog for services, city_info for intro, code_review for Rust lints, market_draft/explain/review for marketing services, quote for payment quotes. No overlap or ambiguity.
Naming is mixed: some tools follow verb_noun pattern (arena_list, cargo_check, code_review, market_draft, market_explain, market_review) while others are single word nouns (calc, catalog, city_info, quote). The 'market_' prefix is consistent across three tools but not applied elsewhere.
10 tools is well-scoped for a thematic server offering a variety of services (challenges, computation, compilation, code review, marketing, payments). Each tool serves a distinct need without bloat.
The tool surface covers core interactions: listing challenges, arithmetic, Rust compilation, catalog browsing, city info, code review, marketing copy and review, and payment quotes. Minor gap: no direct payment execution tool, but x402 payment is implied via quote.
Available Tools
10 toolsarena_listAInspect
List open oracle-judged challenges incl. the drone Hover-Hold arena. Free to read.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value by stating the tool is read-only and free, but with no annotations, further behavioral details (e.g., pagination, rate limits) could be included.
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, concise sentence that front-loads the main purpose and key information, with 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?
The description is adequate for a simple list tool with no parameters, but could mention expected output fields. No output schema exists, so additional return value context would enhance completeness.
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?
No parameters exist, so the description need not add parameter info. Schema coverage is 100%, meeting the baseline for no-param 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 the tool lists open oracle-judged challenges, specifically mentioning the drone Hover-Hold arena. It distinguishes itself from siblings like calc or catalog by focusing on a specific challenge type.
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 a read-only operation ('Free to read'), and with no similar sibling tools for listing challenges, no explicit alternative is needed. However, it lacks guidance on when to use this tool versus other read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcCInspect
Arithmetic. PAID (1 iron-cent) — tools/call returns the toll to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| expr | Yes |
Tool Definition Quality
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 mentions a paid call and returns a toll, implying side effects (payment), but does not disclose if the operation is read-only or modifies state. The description is insufficient for understanding 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 extremely short but lacks structure and essential detail. It is under-specified, not concise in a helpful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and no annotations, the description fails to provide crucial information about input format, output structure, or side effects. It is not complete enough for an agent to use reliably.
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 only parameter 'expr' is a string with 0% schema description coverage. The description does not explain the expected format, syntax, or examples. The agent has no information on how to formulate the arithmetic expression.
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 'Arithmetic' and mentions returning a toll to pay via x402, indicating it computes a cost. However, it conflates arithmetic with payment, and the name 'calc' is vague. It doesn't clearly distinguish from siblings, which are mostly non-arithmetic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks any context about prerequisites, use cases, or situations where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cargo_checkCInspect
Verify Rust compiles in a sealed sandbox. PAID (5 iron-cents) — returns the toll.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'sealed sandbox' (isolation) and 'PAID (5 iron-cents)' (cost), but does not disclose whether the tool modifies state, what errors occur, or any side effects. Key behavioral details are missing.
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 (two sentences) and front-loaded with the core purpose. It efficiently communicates purpose and cost, but could be slightly more structured (e.g., clearly separating usage from cost).
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 compilation verification tool and the sparse schema (one parameter, no output schema), the description is insufficient. It does not explain return values, error handling, or what 'returns the toll' means in terms of output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not elaborate on the 'code' parameter at all—no mention of format, typical content, or constraints. It adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying Rust compilation in a sealed sandbox. It is distinct from sibling tools which are unrelated (e.g., market_draft, calc, quote). The verb 'Verify' and resource 'Rust compiles' 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?
No guidance on when to use this tool versus alternatives. Sibling tools are unrelated, but the description does not mention any prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
catalogAInspect
List services and their prices (iron-cents; 100 = 1 USDC). Free to read.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only discloses that the tool is free to read, but does not mention any potential rate limits, data freshness, or behavior when no services exist. Minimal disclosure.
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 includes essential details: verb, resource, unit, and cost. 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?
For a simple list tool with no parameters or output schema, the description covers the core purpose and unit. Some missing details like pagination or volatility might be needed in certain contexts, but overall adequate.
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 with 100% coverage, so no parameter info is needed. The description adds no parameter semantics, but the baseline for 0 parameters is 4.
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 lists services and their prices in iron-cents, with a specific verb 'list' and resource 'services and their prices'. It distinguishes from siblings like arena_list or market_draft by being a simple catalog.
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 a read-only use (free to read) but does not provide explicit guidance on when to use this tool versus alternatives like arena_list. Usage context is implied but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
city_infoBInspect
What Iron City is and how to enter + pay. Free to read (the gate sign).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Free to read' indicating no cost, but does not disclose permissions, rate limits, or return type. For a simple info tool, this is minimal but not misleading.
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 a single sentence, direct and free of fluff. It sacrifices detail for brevity, but remains understandable.
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 zero parameters and no output schema, the description is too sparse. It does not clarify what the tool returns or any prerequisites, leaving the agent to guess the format of the information.
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?
Tool has zero parameters; baseline is 4. Description adds no parameter info because none exist, which 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 states the tool provides information about Iron City, including entry and payment. The verb 'is' implies a descriptive purpose, distinguishing it from sibling tools which are actions like calc or market_draft. However, it lacks a specific verb like 'get' or 'describe'.
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 a read-only info lookup ('Free to read'), but does not explicitly state when to use this tool over alternatives. With zero parameters and a unique domain, usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
code_reviewCInspect
rustc lints/warnings on your Rust. PAID (20 iron-cents) — returns the toll.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions being paid and returning 'the toll', but does not explain what side effects occur (e.g., executing code), error handling, or idempotency. The output format is ambiguous.
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 (one sentence) but omits critical details. It is not front-loaded with key information; the cost note is secondary to functionality.
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 lack of annotations and output schema, the description should provide a fuller picture. It mentions cost but fails to explain what the tool returns (lints vs. toll), limiting an agent's ability to use it 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?
The schema has a single 'code' parameter with no description (0% coverage). The description says 'your Rust' but does not clarify whether it expects a code snippet, file path, or project. No format or constraints are provided.
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 performs rustc lints/warnings on Rust code, which is a specific verb-resource combination. However, it does not differentiate from the sibling tool 'cargo_check', which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like cargo_check. The only additional information is about cost, but no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_draftCInspect
iron-draft-co writes your copy. PAID (15 iron-cents).
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It discloses the tool is paid (cost), which is important, but provides no other behavioral traits such as side effects, credit consumption behavior, or response characteristics. The description is insufficient for an agent to understand all behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus cost note). It is concise but lacks structure. It is not verbose, but the brevity sacrifices informativeness. A slightly longer description with more details would be more helpful.
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 one parameter, no output schema, and no annotations, the description is critically incomplete. It does not specify what 'job' should contain, expected output format, any prerequisites, or how the cost works. An agent cannot reliably invoke this tool based on the description alone.
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 one required parameter 'job' (string) with no description. Schema coverage is 0%. The description 'writes your copy' implies 'job' may be the copy request, but does not explain format, constraints, or examples. The description adds no meaningful semantic value beyond the schema's type.
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 the tool 'writes your copy', indicating a content generation function. However, 'copy' is vague (ad copy? text?) and the phrase 'iron-draft-co' is unclear. It distinguishes from siblings like 'market_explain' and 'market_review' by implying drafting, but the purpose is not fully precise.
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 guidelines on when to use this tool vs alternatives. The description only mentions it is paid (15 iron-cents), but does not specify any conditions, prerequisites, or exclusions. The agent receives no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_explainDInspect
iron-explain-co explains it. PAID (10 iron-cents).
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only mentions cost (PAID 10 iron-cents) but does not disclose side effects, permissions, or whether tool is read-only.
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?
Very short but cryptic; does not earn its place as it omits essential 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?
Despite simple tool with one param and no output schema, description fails to clarify tool purpose, usage, or expected input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and description does not mention the 'job' parameter; no meaning added 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?
Description says 'explains it' but does not specify what 'it' refers to; uses obscure name 'iron-explain-co' and lacks clear connection to market context. Vague purpose.
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 on when to use this tool vs siblings like market_draft or market_review; no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_reviewCInspect
iron-review-co (captain-backed) reviews your code. PAID (30 iron-cents).
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavior. It mentions a cost (30 iron-cents) and 'captain-backed' status, but does not describe what the tool does with the input, how long it takes, or what output to expect.
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, which is concise, but it sacrifices critical information. It earns a moderate score because it is not verbose, but it is under-specified.
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 simple input schema and no output schema, the description should explain what the review returns. It only mentions cost and backing, omitting the tool's output format or result type, leaving the agent uninformed.
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 has a single required parameter 'job' with no description. The description does not explain what 'job' means (likely the code to review), leaving the agent with no understanding of how to populate this parameter.
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 'reviews your code' and names the service 'iron-review-co', but it's ambiguous whether this is a code review tool or a market review tool given the name 'market_review'. It does not differentiate from the sibling 'code_review'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'code_review'. The description lacks any context about prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quoteBInspect
Get an x402 payment quote (the toll) for a resource, e.g. tool/cargo_check.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Get' suggesting a read operation, but does not clarify if this involves any side effects (e.g., reserving funds, checking availability). The tool might be safe to call multiple times, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence that includes both purpose and an example. Every word is necessary, and the information is front-loaded. No wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides minimal completeness. It tells what the tool does and gives an example, but lacks information about return values, error conditions, or usage scenarios. Adequate but not thorough.
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 has no description for the 'resource' parameter. The description adds an example ('tool/cargo_check'), which provides some context on the expected format. However, it does not explain valid values, constraints, or the exact structure required, leaving ambiguity.
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 gets a payment quote for a resource, with a specific verb ('Get') and object ('x402 payment quote'). It provides an example ('tool/cargo_check') that hints at the resource format. However, it does not explicitly differentiate from sibling tools like 'cargo_check' or 'catalog', which might have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling list includes many tools, but no context is provided about when a quote is appropriate or when other tools should be used instead.
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!