ManaBuy MCP Server is a stdio-based Model Context Protocol server for integrating ManaBuy product and order APIs with MCP clients. It exposes tools for product search, product detail retrieval, SKU and order-field inspection, order quotation, authenticated order creation, order status lookup, and order detail retrieval, with explicit confirmation required before any order-creation workflow.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.7/5 across 9 of 9 tools scored. Lowest: 2.9/5.
Each tool targets a distinct action or resource: auth (login/logout/status), product discovery (search/detail), ordering (quote/create/status/detail). There is no functional overlap that would cause an agent to select the wrong tool.
All tool names follow a consistent verb_noun pattern in snake_case, such as search_products, create_order, get_login_status. Even login_manabuy and logout_manabuy fit the pattern with the domain as the object.
With 9 tools, the server is well-scoped for the ManaBuy ordering domain. Each tool covers a necessary step in the workflow without redundancy or bloat.
The set covers product discovery, quoting, order creation, order status/detail tracking, and session management. A notable gap is the lack of a cancel order or list orders capability, but the core purchasing flow is complete.
create_orderAInspectCreate a ManaBuy order and return payment information. This is a high-risk action: call it only after explicit user confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| skuCode | Yes | Selected SKU code. | |
| urlName | No | Product URL name. | |
| couponId | No | Optional coupon ID as string. | |
| skuCount | No | Quantity. | |
| couponCode | No | Optional coupon code. | |
| ipCurrency | No | Optional detected local currency. | |
| extraParams | No | Payment/channel specific extra params. | |
| productCode | Yes | ManaBuy product code. | |
| orderInfoMap | Yes | Game/account fields required by the product, for example { userId: '123456', server: 'Asia' }. | |
| payMethodCode | Yes | Payment method code, for example AirWallex_Card. | |
| promotionCode | No | Optional promotion code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, but the description flags the action as high-risk and requires explicit user confirmation—critical behavioral context. It also notes the return of payment information. Could additionally disclose irreversibility or charging side effects, but the warning is substantial.
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, front-loaded with purpose and risk warning. No fluff or repeated schema info.
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 an 11-param tool with nested objects and no output schema, the description captures the core purpose and high-risk context. It could elaborate on the payment information return format, but schema covers parameters adequately.
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% parameter description coverage, so the description adds no param-specific value. 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?
Clear verb+resource: 'Create a ManaBuy order' and adds 'return payment information'. Distinguishes from siblings by being the only order-creation tool among read/quote 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?
Explicitly states 'high-risk action: call it only after explicit user confirmation', providing a strong when-not-to-call condition. Doesn't name alternatives like quote_order, but the confirmation requirement is clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_login_statusAInspectCheck whether ManaBuy is currently logged in for this MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It adds useful scope clarification ('for this MCP server') and the verb 'Check' implies a non-mutating read, but it does not disclose return type, side effects, or error behavior. No contradiction exists.
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 clear, front-loaded sentence with no redundant information. Every word contributes to understanding the tool's 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?
For a simple zero-parameter status query, the description provides sufficient context. It clearly states what is checked and the scope, though it does not explicitly describe the return value; the phrase 'whether' strongly implies a boolean result, making this a minor gap.
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?
This tool takes no parameters, so the schema fully covers parameter semantics. The description has no need to add parameter details, and the baseline for zero-parameter tools 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 uses a specific verb 'Check' and clearly identifies the resource: ManaBuy login status for this MCP server. It distinguishes itself from sibling actions login_manabuy and logout_manabuy by focusing on state inspection rather than mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying whether the server is logged in, but it gives no explicit when-to-use context, prerequisites, or references to alternative tools. It is minimally adequate but lacks clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_order_detailAInspectGet ManaBuy order detail by order number.
| Name | Required | Description | Default |
|---|---|---|---|
| orderNo | Yes | ManaBuy order number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing prerequisites such as authentication (siblings include login_manabuy), potential side effects, or error conditions. The verb 'Get' implies read-only, but no explicit behavioral context is provided.
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 with no filler, front-loading the verb and resource. It is appropriately compact for a simple one-parameter operation.
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 parameter schema and lack of output schema, the description offers the bare minimum: it names the operation and parameter. However, it doesn't cover authentication requirements or return value expectations, leaving the agent under-informed for a production 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?
The schema already provides a description for orderNo ('ManaBuy order number'), achieving 100% coverage. The description's 'by order number' simply restates this, adding no additional semantic value beyond what the schema contains.
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' with resource 'ManaBuy order detail' and identifies the key identifier 'by order number'. This distinguishes it from sibling tools like get_order_status which focuses on status only.
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 does not explicitly state when to use this tool versus alternatives like get_order_status or get_product_detail. The usage is implied from the name but not reinforced with guidance about which order-related operation to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_order_statusCInspectGet ManaBuy order status by order number.
| Name | Required | Description | Default |
|---|---|---|---|
| orderNo | Yes | ManaBuy order number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the core purpose. It does not mention read-only nature, authentication requirements, response format, or whether the status is raw or processed. The term 'get' implies a read operation, but this is not explicitly 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 a single, concise sentence that is front-loaded with the action and resource. It contains no unnecessary words or fluff, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has only one parameter and low complexity, there is no output schema. The description does not explain what the response contains, what statuses exist, or how errors are handled. Without these details, an agent cannot fully anticipate the tool's behavior.
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 already describes orderNo as 'ManaBuy order number' with 100% coverage. The description's 'by order number' adds no additional meaning beyond the schema, aligning with the baseline of 3 for high schema coverage.
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 ManaBuy order status by order number, identifying the specific resource (order status) and input (order number). It does not explicitly distinguish itself from get_order_detail, but the focus on 'status' implies a narrower scope than full order details.
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 get_order_detail. The description lacks any explicit or implicit context about preferred usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailAInspectGet ManaBuy product detail, SKU list, required order fields, and top-up instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| current | No | ||
| urlName | No | Product URL name, for example pubg-mobile-top-up. | |
| productCode | No | ManaBuy product code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does explain what data is returned (detail, SKUs, order fields, instructions), but it does not disclose whether authentication is required (sibling login_manabuy suggests it might be), nor does it mention any side effects or limitations. The lack of explicit safety/read-only hints is a gap for a tool that may require auth.
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 that front-loads the core action and then lists the key output types. Every word adds value, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a good sense of the tool's outputs, but it lacks operational context such as whether login is required (sibling login_manabuy implies this), how pagination parameters work, or how to choose between urlName and productCode. With no output schema and no annotations, this is a noticeable gap, but the tool's purpose is still clear enough for minimal 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 schema provides descriptions for urlName and productCode (50% coverage), but the tool description adds no additional parameter meaning. It does not explain how the parameters map to the product being fetched, nor does it clarify the role of size and current (likely pagination). With 50% schema coverage, the description should compensate but does not.
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 function with a specific verb ('Get') and resource ('ManaBuy product detail'), and enumerates the key outputs (SKU list, required order fields, top-up instructions). This distinguishes it from siblings like search_products (which presumably searches) and create_order (which creates orders).
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 this tool when you need product detail, SKU list, or top-up instructions. It does not explicitly name alternative tools or state when not to use it, but the context is sufficiently clear given the sibling tool names. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
login_manabuyAInspectStart ManaBuy browser login and return a login URL. Use this when a ManaBuy action requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| openBrowser | No | Whether to open the login URL in the default browser. | |
| timeoutSeconds | No | How long the login URL should remain valid. | |
| waitForCallback | No | Wait for a local callback. Use false for hosted HTTP MCP; true only for local stdio MCP. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It reveals a key output (login URL) and its role as an auth initiation, but omits important behavioral details: whether it invalidates an existing session, how authentication completes, or any side effects. This is minimally adequate but not rich.
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 short sentences front-load the core action and output, with no unnecessary words. The second sentence clarifies the exact use case. Very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should cover the flow more thoroughly. While it mentions the login URL, it does not clarify the asynchronous nature, how to complete the login, or that the follow-up status can be checked via get_login_status. It is minimally sufficient but leaves notable gaps.
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%, and each parameter (openBrowser, timeoutSeconds, waitForCallback) already has descriptive text. The tool description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Start' with a clear resource ('ManaBuy browser login') and states the output ('return a login URL'). It distinguishes itself from siblings like get_login_status and logout_manabuy by focusing on initiating the auth flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this when a ManaBuy action requires authentication', providing clear usage context. It does not mention when not to use it or alternatives, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
logout_manabuyAInspectRemove the locally saved ManaBuy login token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds meaningful context by specifying 'locally saved', indicating the operation is client-side and does not necessarily invalidate a server session. This is valuable beyond just saying 'logout'. However, it does not disclose what happens if no token exists or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise, front-loaded with the action, and contains no unnecessary words. It earns its place entirely.
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 0-parameter tool with no output schema, this description fully covers what the tool does and its scope (local token removal). It is complete given the low complexity, and no additional information is needed 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 tool has zero parameters, and the schema coverage is 100% (empty properties). The description does not need to explain parameters. Per the baseline for 0 params, a score of 4 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's action: removing a locally saved login token. The verb 'Remove' and resource 'locally saved ManaBuy login token' are specific, and it distinguishes itself from siblings like login_manabuy (which creates the token) and get_login_status (which checks it).
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 context of logging out is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives, such as mentioning that it only affects local storage and not server-side sessions. No exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_orderAInspectQuote an order before creation. Use this to show the user final price, discounts, and payable amount.
| Name | Required | Description | Default |
|---|---|---|---|
| orderNo | No | Existing order number when requoting. | |
| skuCode | Yes | Selected SKU code. | |
| urlName | No | Product URL name. | |
| couponId | No | Optional user coupon ID. | |
| skuCount | No | Quantity. | |
| couponCode | No | Optional coupon code. | |
| ipCurrency | No | Optional detected local currency. | |
| productCode | Yes | ManaBuy product code. | |
| promotionCode | No | Optional promotion code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to state whether the quote operation has side effects, requires authentication, or is reversible. The term 'quote' hints at a non-mutating action, but this is not explicitly confirmed, leaving the agent uncertain about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and contains no filler. Every word contributes to understanding the tool's function.
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 no output schema and no annotations, the description should cover expected return values and edge cases. It mentions final price, discounts, and payable amount vaguely, but does not explain requoting via orderNo, handling of optional parameters, or any response structure. The tool has 9 parameters, so more detail is needed for 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 description coverage is 100% (all 9 parameters have descriptions), so baseline is 3. The description adds no extra parameter-specific meaning beyond what the schema already provides; it only mentions the overall pricing purpose, which does not significantly enhance parameter understanding.
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: 'Quote an order before creation' identifies the verb (quote) and resource (order) while distinguishing it from sibling create_order. The phrase 'show the user final price, discounts, and payable amount' further clarifies its scope.
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 context on when to use the tool ('before creation', 'show the user final price') but does not explicitly name alternatives or exclusions. It implies use for pre-purchase quoting rather than order creation, which is clear but lacks an explicit 'use create_order instead' pointer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsBInspectSearch ManaBuy products/games by keyword, product code, category, or hub URL name.
| Name | Required | Description | Default |
|---|---|---|---|
| pageNo | No | ||
| keyword | No | Search keyword, such as PUBG Mobile. | |
| category | No | Product category filter. | |
| pageSize | No | ||
| productCode | No | ManaBuy product code if known. | |
| gameHubUrlName | No | Game hub URL name if known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only lists search criteria and does not state whether the operation is read-only, whether pagination is automatic, or what the return format is. The verb 'Search' implies read-only, but explicit disclosure is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and includes the key search dimensions. 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 tool with 6 optional parameters and no output schema, the description is incomplete. It does not explain pagination behavior, result ordering, whether parameters are AND/OR combined, or what a response looks like. The tool may return a list of products, but this is not stated.
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 description lists the same search criteria that already have descriptions in the schema (keyword, category, productCode, gameHubUrlName), adding no new meaning. It fails to describe the pagination parameters (pageNo, pageSize) or how multiple filters interact. Schema coverage is 67%, which is moderate, so the description adds some value by summarizing but does not compensate for the missing parameter details.
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 function: 'Search ManaBuy products/games by keyword, product code, category, or hub URL name.' It specifies the resource (ManaBuy products/games) and the verb (Search), and lists the search criteria, which distinguishes it from sibling tools like get_product_detail that retrieve a specific product.
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. The description does not mention exclusions, prerequisites, or when to prefer search_products over siblings like get_order_detail or get_product_detail. The usage context is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
