FiatDock
Server Details
Non-custodial USDC <-> bank for AI agents via x402 + Transak. Own funds only; PT + EU/EEA; 18+.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: searching and getting service details, invoking services, creating on/off-ramp sessions, checking order status, and getting quotes. No overlapping functionality.
All tools use a consistent verb_noun pattern with snake_case (e.g., create_onramp_session, get_service). No naming conventions mixed.
7 tools is well-scoped for a marketplace with fiat gateway functionality. Each tool covers a necessary operation without unnecessary duplication.
The tool surface covers browsing, invoking, on/off ramping, status, and quoting. Missing a cancel/update order tool, but core workflows are covered.
Available Tools
7 toolscall_serviceCall a marketplace serviceAInspect
Invoke a listed FiatDock service. PAID listings go THROUGH the 1% gateway (POST /s/:id) so the non-custodial split is enforced — this remote /mcp cannot sign payments, so it returns the gateway's TWO-payment 402 challenge as an error (use the fiatdock-mcp npm package with AGENT_PRIVATE_KEY to pay both legs automatically). FREE / first-party listings are forwarded to their real MCP endpoint directly (no payment). Pass the service's expected request body as args.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id (svc_…) to invoke, from search_services | |
| args | No | JSON payload to send to the service (e.g. an MCP JSON-RPC request body) — shape is defined by that service |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | true when the underlying service returned a 2xx |
| result | No | The service's response body — parsed JSON when it returned JSON, otherwise the raw text |
| status | Yes | HTTP status returned by the service (or the gateway) |
| service | Yes | Listing id that was invoked |
| routedThroughGateway | Yes | true if PAID (settled 99% seller / 1% FiatDock via /s/:id); false if FREE/first-party direct |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral traits beyond annotations: for paid listings, it returns a 402 challenge and cannot sign payments; for free listings, it forwards directly. This explains side effects and limitations, enhancing transparency. No contradiction with annotations (readOnlyHint=false, etc.).
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 but informative, covering key behaviors in a few sentences. It could be slightly more streamlined, but it's well-structured and front-loaded with the main action.
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 (two listing types, payment gateway, error handling), the description covers essential aspects. An output schema exists but is not shown; the description does not explain return values, but the schema would handle that. Overall, it is sufficiently complete for the agent.
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 the schema already documents parameters. The description adds meaning by explaining that `args` is the service's expected request body (e.g., MCP JSON-RPC), which clarifies the purpose and structure beyond the schema's 'JSON payload' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it invokes a listed FiatDock service, distinguishes between paid and free listings, and explains the gateway behavior. The verb 'Invoke' and resource 'FiatDock service' are specific, and the description differentiates from sibling tools like search_services or get_service.
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 when to use this tool: to actually call a service after listing it. It explains behavior for paid vs free, but does not explicitly state when not to use it or name alternatives. However, the sibling tools are for different purposes (e.g., getting orders, quotes), so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_offramp_sessionCreate off-ramp session (USDC → bank)AInspect
Convert the agent's USDC to fiat in the owner's OWN bank account. Returns a one-time checkoutUrl (forward it to the human owner; valid 5 minutes, single use) and a partnerOrderId to track. Paid endpoint ($0.05 USDC via x402) — without payment this returns the 402 challenge; use the fiatdock-mcp npm package with AGENT_PRIVATE_KEY for automatic payment. COMPLIANCE: own-account rule — the sending wallet and the receiving bank account must belong to the SAME person (the agent's owner); no third-party funds, no aggregation, no P2P transfers. 18+; service area: Portugal + Transak-supported EU/EEA countries (NOT the UK). Crypto is volatile; not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional referral code (1-64 chars: letters, digits, _ or -) | |
| No | Owner's Transak account email | ||
| network | No | USDC network, default base | |
| customerId | No | Stable agent/customer id | |
| cryptoAmount | Yes | USDC amount to sell | |
| fiatCurrency | No | e.g. EUR, default EUR |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | Next-step instructions |
| checkoutUrl | Yes | One-time branded checkout URL (valid ~5 minutes, single use) — forward to the human owner |
| customerKey | No | Returned ONCE on the first session with a new customerId — store securely |
| partnerOrderId | Yes | Order id — track it with get_order_status |
| customerKeyNote | No | How to use customerKey |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint=false is consistent. Description adds critical behavioral context: paid endpoint via x402, returns a one-time checkoutUrl valid 5 minutes, partnerOrderId for tracking, and compliance rules (own-account, 18+, service area). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then returns info, payment handling, and compliance. Every sentence adds value, though slightly verbose. Well-structured 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's complexity (6 params, payment, compliance), the description covers purpose, usage, behavioral traits, return values (checkoutUrl, partnerOrderId), and constraints. The output schema existence is noted but description already mentions key return fields, making it complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good individual parameter descriptions. The tool description does not significantly enhance parameter semantics beyond the schema, providing only overarching context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts USDC to fiat into the owner's bank account, distinguishing it from the sibling create_onramp_session (which likely does the opposite). The verb 'convert' is specific, and the resource and direction are 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 details when to use (for owner's own bank account) and when not to (no third-party, no aggregation, not in UK). Also explains payment requirement and how to handle the 402 challenge, guiding the agent on prerequisites and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_onramp_sessionCreate on-ramp session (fiat → USDC)AInspect
Buy USDC with the owner's OWN fiat and deliver it to the agent's wallet (address locked). Returns checkoutUrl + partnerOrderId. Paid endpoint ($0.05 USDC via x402) — without payment this returns the 402 challenge; use the fiatdock-mcp npm package with AGENT_PRIVATE_KEY for automatic payment. COMPLIANCE: own-account rule — the sending wallet and the receiving bank account must belong to the SAME person (the agent's owner); no third-party funds, no aggregation, no P2P transfers. 18+; service area: Portugal + Transak-supported EU/EEA countries (NOT the UK). Crypto is volatile; not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional referral code (1-64 chars: letters, digits, _ or -) | |
| No | Owner's Transak account email | ||
| network | No | USDC network, default base | |
| customerId | No | Stable agent/customer id | |
| fiatAmount | Yes | Fiat amount to spend | |
| fiatCurrency | No | e.g. EUR, default EUR | |
| walletAddress | Yes | Agent wallet that receives USDC |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | Next-step instructions |
| checkoutUrl | Yes | One-time branded checkout URL (valid ~5 minutes, single use) — forward to the human owner |
| customerKey | No | Returned ONCE on the first session with a new customerId — store securely |
| partnerOrderId | Yes | Order id — track it with get_order_status |
| customerKeyNote | No | How to use customerKey |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant details beyond annotations: paid endpoint, return values, compliance, region, volatility disclaimer. 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?
Dense but well-structured: purpose, returns, payment, compliance, region, disclaimer. Efficiently packed with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects for a pay-on-ramp tool: purpose, payment flow, compliance, service area, risk disclaimer. Output schema provides additional detail.
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 all parameters with descriptions (100% coverage). Description adds context but doesn't enhance parameter understanding 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?
Clearly states the tool buys USDC with owner's fiat and delivers to agent wallet, distinguishing it from offramp and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies use case (buy USDC with owner's fiat), payment requirement (x402), and compliance rules. Lacks explicit when-not-to-use or alternatives, but offers good context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_order_statusGet order statusARead-onlyIdempotentInspect
Check the status of an on/off-ramp order by partnerOrderId.
| Name | Required | Description | Default |
|---|---|---|---|
| partnerOrderId | Yes | Order id returned when the session was created |
Output Schema
| Name | Required | Description |
|---|---|---|
| ref | No | Referral code if one was set |
| status | Yes | SESSION_CREATED -> PROCESSING -> COMPLETED | FAILED | CANCELLED | EXPIRED |
| createdAt | No | ISO 8601 session creation time |
| updatedAt | No | ISO 8601 time of the last webhook update |
| customerId | No | Customer id the session was created with |
| isBuyOrSell | No | Order direction |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description 'check the status' is consistent but adds no extra behavioral context beyond what annotations convey. For a simple read operation, this is adequate.
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, well-structured sentence with no unnecessary information. It is concise and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full output schema and comprehensive annotations, the description is sufficient for a simple status-check tool. It could mention potential error conditions, but overall it provides a complete context.
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 parameter description in the schema is clear. The tool description does not add additional parameter semantics, 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?
The description clearly states the verb ('Check') and the resource ('status of an on/off-ramp order') and identifies the key parameter (partnerOrderId). It implicitly distinguishes from siblings which create sessions or get quotes.
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 the tool is for checking order status when you have a partnerOrderId, but it does not explicitly state when to use or not use it, or contrast with siblings. No 'use this when' or 'instead of' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quoteGet a free quoteARead-onlyIdempotentInspect
Free quote before paying: exchange rate, total fees (all itemised, incl. the 1% service commission), and amount received. Quotes are indicative, not guaranteed. side=SELL (USDC->fiat) or BUY (fiat->USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | SELL = USDC to fiat, BUY = fiat to USDC | SELL |
| network | No | USDC network, default base | |
| fiatAmount | No | Fiat amount (for BUY) | |
| cryptoAmount | No | USDC amount (required for SELL) | |
| fiatCurrency | No | e.g. EUR, default EUR |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | Human-readable caveat (quotes are indicative) |
| rate | Yes | Exchange rate used (fiat per USDC) |
| side | Yes | Quote direction |
| network | No | USDC network the quote assumes |
| youSend | Yes | Amount the sender pays, e.g. '50 USDC' |
| totalFee | Yes | Total fees in fiat, all itemised (incl. the 1% service commission) |
| youReceive | Yes | Amount received after all fees, e.g. '44.6 EUR' |
| feeBreakdown | Yes | Provider's itemised fee list |
| paymentMethod | No | Settlement method, e.g. sepa_bank_transfer |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, openWorld. The description adds critical behavioral context that quotes are indicative and not guaranteed, which is not covered by annotations. This supplements the safe-read 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 two short sentences plus an explanatory note on side parameter. It is front-loaded with the tool's purpose and includes all essential information without 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 quote tool with 5 parameters, an output schema, and full schema coverage, the description fully covers the tool's purpose, key behaviors, and parameter usage. No significant 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 has 100% description coverage. The tool description adds value by explaining the side enum semantics (SELL=USDC->fiat, BUY=fiat->USDC) and clarifying which amount parameter applies per side (fiatAmount for BUY, cryptoAmount for SELL), 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 the tool provides a free quote with exchange rate, total fees itemized, and amount received. It distinguishes from sibling tools (create_offramp_session, create_onramp_session, get_order_status) by focusing on quote generation before payment.
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 indicates this tool is used before paying and explains the side parameter (SELL/BUY) with direction. It provides clear context on when to use each side, but does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_serviceGet a marketplace service's detailARead-onlyIdempotentInspect
Full detail for one FiatDock marketplace listing, including how to call it: PAID listings route through the gateway via call_service (the 99/1 split is enforced); FREE/first-party listings expose their real MCP endpoint to call directly. Read-only, free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id (svc_…) from search_services |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Listing id (svc_…) — pass to get_service / call_service |
| name | Yes | Service name |
| tags | No | Free-text tags |
| rating | No | Verified-purchase rating aggregate: { count, average (1-5) } |
| status | No | Listing status: pending | verified | suspended |
| reviews | No | Recent verified-purchase reviews, newest first |
| summary | No | One-line summary |
| callHint | No | Plain-language instruction for how an agent invokes this listing |
| category | No | Category slug (data, search, finance, dev, productivity, ai, web, other) |
| networks | No | Chain slugs the service settles on |
| priceUsd | Yes | Price per call in US dollars (0 = free) |
| sellerId | No | Opaque seller id that owns the listing |
| verified | Yes | Verified seller (KYC + active badge) or first-party (platform-vouched) |
| createdAt | No | ISO 8601 listing creation time |
| firstParty | No | Platform's own featured listing (official) |
| gatewayUrl | Yes | How to reach it: a relative /s/:id (PAID — invoke via call_service, 99/1 split) OR an absolute MCP endpoint URL (FREE/first-party — call directly) |
| sellerName | No | Seller display name, if set |
| description | No | Full description |
| mcpEndpoint | No | Real MCP endpoint — present only for FREE/first-party (direct) listings |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds critical behavioral details: paid vs. free handling, the 99/1 split, and that it is read-only and free. 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 a single, efficient sentence that front-loads the purpose ('Full detail for one FiatDock marketplace listing') and contains no extraneous 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 need not cover return values. It adequately explains the listing types and usage context, making it complete for a detail retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage and already describes the parameter as 'Listing id (svc_…) from search_services'. The description does not add new semantic meaning, so it scores the baseline 3.
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 provides full detail for a FiatDock marketplace listing. It distinguishes between paid and free listings, which differentiates it from siblings like call_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context on when to use get_service versus call_service: for paid listings, route through call_service; for free ones, call directly. It lacks an explicit 'do not use if' but provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_servicesSearch the FiatDock marketplaceARead-onlyIdempotentInspect
Find paid + free MCP services other agents have published on the FiatDock marketplace. Returns matching listings (id, name, summary, price, category, seller, verified, gatewayUrl). Use get_service for full detail and call_service to invoke one. Read-only, free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text search over name, summary, description and tags | |
| sort | No | Sort order (default newest; first-party listings are always featured first) | |
| category | No | Filter by category slug: data, search, finance, dev, productivity, ai, web, other | |
| verifiedOnly | No | Only verified listings (KYC'd seller or first-party) |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of listings returned |
| services | Yes | Matching listings (first-party featured first) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds 'Read-only, free' and return fields, but does not introduce major new behavioral traits beyond what annotations provide.
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?
Three concise sentences: purpose, return fields, usage with alternatives. Front-loaded and 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 annotations and schema, the description covers purpose, return values, usage context, and safety. Minor gap: no mention of pagination or result limits, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add additional meaning beyond what the schema already provides, 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?
The description clearly states the tool finds paid+free MCP services on the FiatDock marketplace, lists return fields, and distinguishes from siblings by mentioning get_service for detail and call_service for invocation.
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 when to use the tool (searching services) and provides alternatives (get_service for detail, call_service to invoke). Missing explicit 'when not to use' but context is clear.
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!