Chargebee
Server Details
Chargebee MCP Pack — wraps the Chargebee API v2
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-chargebee
- GitHub Stars
- 0
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 3.8/5 across 10 of 10 tools scored. Lowest: 2.9/5.
Most tools have distinct purposes: Chargebee-specific CRUD operations, memory functions, and Pipeworx discovery. However, ask_pipeworx could be confused with discover_tools as both involve finding or using tools, though ask_pipeworx is more about executing queries directly.
Naming is mixed: chargebee_* prefix for Chargebee tools, simple verbs for memory tools (remember, recall, forget), and compound names for Pipeworx tools (ask_pipeworx, discover_tools). No single pattern, but within each group it's consistent.
10 tools is reasonable for a server that integrates Chargebee operations with memory and a natural language interface. It covers core needs without being too sparse or bloated.
For Chargebee, there are basic CRUD for customers, subscriptions, and invoices, but missing operations like create/update/delete for those entities, as well as payments or plans. Memory tools are minimal but functional. Pipeworx discovery is present but ask_pipeworx seems redundant.
Available Tools
10 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It clearly states the tool selects the right source and fills arguments automatically, indicating autonomy. It does not detail limitations or error handling, but the examples cover varied use cases.
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 concise, two sentences plus examples. Every sentence adds value: the first defines purpose, the second explains behavior, examples clarify scope.
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 is complete. It explains input, behavior, and expected output, with no gaps for the agent to misinterpret.
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 a single parameter 'question'. Description explains the parameter's purpose beyond the schema by saying 'in plain English' and giving examples, but adds no additional syntax or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: answering questions in plain English by selecting the best data source. It distinguishes itself from siblings by acting as a universal query interface, unlike the specific Chargebee tools or memory 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?
Description tells the agent to use this tool when the user asks a general question, without needing to browse other tools. It provides examples but does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chargebee_get_customerAInspect
Get complete customer profile by ID. Returns name, email, address, payment methods, subscription count, and account status.
| Name | Required | Description | Default |
|---|---|---|---|
| _site | Yes | Chargebee site name | |
| _apiKey | Yes | Chargebee API key | |
| customer_id | Yes | Customer ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries full burden. States 'returns full customer details' but does not disclose rate limits, authentication details, or potential errors (e.g., if customer not found). Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Purpose and behavior clearly stated upfront.
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 no output schema and simple parameters, the description is minimally adequate. Lacks detail on response structure or error handling, but sufficient for basic 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 description coverage is 100%, so parameters are well-documented in schema. Description adds no extra meaning beyond schema, achieving 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?
Clearly states the action (get), resource (Chargebee customer), and uniqueness (single customer by ID). Distinguishes from sibling tools like chargebee_list_customers by specifying 'single' vs listing.
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?
Indicates the tool is for retrieving a single customer, implying it should be used when a specific ID is known. However, no explicit guidance on when not to use it or alternatives for other scenarios (e.g., listing all customers).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chargebee_get_subscriptionBInspect
Get full subscription details by ID. Returns plan, status, billing dates, customer info, and all charges.
| Name | Required | Description | Default |
|---|---|---|---|
| _site | Yes | Chargebee site name | |
| _apiKey | Yes | Chargebee API key | |
| subscription_id | Yes | Subscription ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states 'Returns full subscription details' but doesn't explain side effects (none expected), required authentication context (apiKey, site are parameters), or potential errors (e.g., invalid ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no filler. Could be slightly improved by combining into one sentence, but current form is clear and front-loaded.
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 (single object retrieval, no output schema), the description is mostly complete but lacks mention of what happens on failure or authentication context already covered by required parameters.
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 describes all parameters. The description adds no extra meaning beyond 'by its ID', which aligns with subscription_id. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('single Chargebee subscription'), clearly identifies the input parameter (ID), and distinguishes it from sibling tools like chargebee_list_subscriptions.
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 use when a specific subscription ID is known, but provides no guidance on when not to use it (e.g., when wanting multiple subscriptions) or alternatives like chargebee_list_subscriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chargebee_list_customersCInspect
List all customers with pagination. Returns customer IDs, names, emails, billing addresses, and creation dates.
| Name | Required | Description | Default |
|---|---|---|---|
| _site | Yes | Chargebee site name | |
| limit | No | Number of results to return (default 10, max 100) | |
| offset | No | Pagination offset from a previous response | |
| _apiKey | Yes | Chargebee API key |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must carry the behavioral burden. It only mentions pagination but does not disclose other behaviors like rate limits, authentication needs beyond the required parameters, or whether it is read-only (assumed but 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?
Two sentences are concise and front-loaded. The first sentence states the purpose, the second adds pagination detail. 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?
Given no output schema and empty annotations, the description is incomplete. It doesn't mention the return format, error conditions, or that this is a paginated list. For a tool with 4 parameters and no output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema descriptions for parameters, such as default value or max for limit, but those are already in 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 'List customers from Chargebee' with a specific verb and resource. It also mentions pagination support (limit and offset), which distinguishes it from sibling tools like chargebee_get_customer that fetch a single customer.
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 given on when to use this tool versus alternatives. For example, it doesn't mention that this is for listing multiple customers while chargebee_get_customer is for a single one. No when-not-to-use or context for pagination usage is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chargebee_list_invoicesAInspect
List invoices filtered by status (e.g., 'paid', 'pending') and/or customer ID. Returns invoice numbers, amounts, dates, and payment status. Paginate with limit and offset.
| Name | Required | Description | Default |
|---|---|---|---|
| _site | Yes | Chargebee site name | |
| limit | No | Number of results to return (default 10, max 100) | |
| offset | No | Pagination offset from a previous response | |
| status | No | Filter by invoice status: paid, posted, payment_due, not_paid, voided, pending | |
| _apiKey | Yes | Chargebee API key | |
| customer_id | No | Filter invoices by customer ID |
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 discloses that the tool lists invoices and supports filters, but does not mention side effects, authentication details, or rate limits. The description is accurate but lacks depth.
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 conveys the essential information without redundancy. It is 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?
For a list tool with good schema coverage and no output schema, the description adequately covers the input parameters but does not mention return value structure or pagination details beyond what is in the schema.
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 all parameters are documented in the schema. The description adds a brief summary of the filters but does not provide additional meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list invoices'), the source ('from Chargebee'), and the supported filters. It distinguishes itself from siblings like chargebee_list_customers and chargebee_list_subscriptions by specifying 'invoices'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filters and pagination parameters, implying when to use them. However, it does not explicitly state when not to use this tool or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chargebee_list_subscriptionsBInspect
List all subscriptions with optional filtering by status (e.g., 'active', 'cancelled'). Returns subscription IDs, plans, amounts, and renewal dates. Paginate with limit and offset.
| Name | Required | Description | Default |
|---|---|---|---|
| _site | Yes | Chargebee site name (e.g., "mycompany" for mycompany.chargebee.com) | |
| limit | No | Number of results to return (default 10, max 100) | |
| offset | No | Pagination offset from a previous response | |
| status | No | Filter by subscription status: active, cancelled, non_renewing, future, in_trial, paused | |
| _apiKey | Yes | Chargebee API key |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. Describes the basic behavior (list with filters) but doesn't disclose side effects (none expected for read), rate limits, or return format. Adequate for a read operation but lacks details about pagination behavior or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose. Efficient, though could be slightly more structured (e.g., separate usage guidance). 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 simple read operation, good annotations coverage, and no output schema, the description is mostly complete. Could mention that it returns a list of subscription objects or refer to API docs for fields. But basic needs are met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description mentions status filter, limit, and offset but doesn't add much beyond what the schema already says. The schema descriptions are already clear, so the description provides little extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists subscriptions from Chargebee and mentions optional filters (status, limit, offset). Distinguishes itself from siblings like chargebee_get_subscription (single) and chargebee_list_customers (different resource).
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?
Provides basic usage context (list subscriptions with filters) but no guidance on when to use alternatives or prerequisites beyond required parameters. Implies pagination via offset but doesn't explicitly say when to use this vs. chargebee_get_subscription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it searches and returns relevant tools with names and descriptions, which is transparent about behavior. However, it doesn't mention any side effects, auth requirements, or rate limits, which would be needed for a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with clear purpose: what it does, what it returns, when to call it. 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 tool's simplicity (search, no output schema needed as return is described), the description is complete. It tells what it returns (names and descriptions) and the key usage context (call first when many tools).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that query is a natural language description and gives examples, and mentions default/max for limit. This exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and resource 'Pipeworx tool catalog', and distinguishes itself from siblings by explicitly saying 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.'
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?
Provides explicit guidance on when to use: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' No alternative tools are named, but the context of being first and searching distinguishes it from other tools that presumably do specific actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetBInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. While 'Delete' implies destructiveness, it does not clarify if the operation is reversible, whether it requires confirmation, or what happens if the key does not exist. Lacks detail on 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?
Extremely concise single sentence with no wasted words. Front-loaded with the action and object, ideal for quick scanning.
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 simplicity (1 param, no output schema, no annotations), the description is minimal but fails to mention return behavior (e.g., success confirmation, error handling for missing key) or any constraints. It is not fully complete for safe 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 a single 'key' parameter described as 'Memory key to delete'. The description adds no additional meaning beyond the schema; it restates the parameter's purpose. Baseline 3 is appropriate given full 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 uses a clear verb ('Delete') and specific resource ('stored memory') with the parameter 'key', making the tool's purpose unambiguous. It effectively distinguishes from siblings like 'remember' (store) and 'recall' (retrieve).
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 is provided. There is no mention of prerequisites (e.g., memory must exist), or that this is destructive and irreversible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. It discloses the basic behavior (retrieve by key or list all) but does not mention any side effects, authorization requirements, or limitations (e.g., maximum memory size, persistence across sessions). The description is adequate but could be more transparent.
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, no wasted words. Front-loaded with the primary action. Every sentence contributes meaningful guidance.
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 low complexity (1 optional parameter, no output schema, no nested objects), the description is sufficiently complete. It explains the two modes of operation and provides context for its use. Could mention what is returned (e.g., memory content) but not strictly necessary.
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% with the single 'key' parameter having a clear description. The description adds value by explaining the effect of omitting the key (list all), which is not in the schema. The parameter semantics are well-covered.
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 uses specific verb 'Retrieve' and resource 'memory by key' or 'list all stored memories'. Clearly distinguishes between single-key retrieval and listing, and differentiates from sibling tools like 'remember' (store) and 'forget' (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to omit the key to list all memories. Provides context about retrieving 'context you saved earlier in the session or in previous sessions', which helps agent understand when this tool is appropriate, though no explicit alternatives or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses persistence behavior (persistent for authenticated, 24-hour for anonymous) but does not mention any side effects, overwrite behavior for existing keys, or memory limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with clear front-loading of purpose and immediate use cases. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required string params, no output schema, no nested objects), the description is largely complete. It explains what it stores, when to use it, and memory duration. However, it could mention behavior on key overwrite or maximum value length.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes parameters. The description adds examples for 'key' and states value can be any text, which is consistent with the schema, but adds no new semantic information beyond what's in 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 stores a key-value pair in session memory, with specific use cases (saving findings, preferences, context). It distinguishes itself from siblings like 'recall' (retrieval) and 'forget' (deletion) by its focus on storage.
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 for when to use (save intermediate findings, preferences, context) and mentions persistence differences for authenticated vs anonymous users, but does not explicitly state when not to use it or suggest alternatives.
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!