ConnectMeGuru eSim
Server Details
Buy traveler eSim plans for more than 190+ countries.
- 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 3.5/5 across 14 of 14 tools scored. Lowest: 2.9/5.
Each tool targets a distinct action: order management, catalog browsing, wallet operations, authentication, and support. No two tools have overlapping purposes, making selection unambiguous.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_esim_catalog, purchase_esim_with_wallet, verify_agent_otp). There is no mixing of conventions.
With 14 tools, the surface is well-scoped for an eSIM service: catalog browsing, purchasing, wallet management, authentication, order history, and support. No tool feels redundant or missing.
The set covers the core eSIM lifecycle (browse, buy, cancel, top-up, monitor usage, wallet, auth, support). A minor gap is the lack of a dedicated tool to retrieve a single order detail beyond the paginated list, but agents can work around.
Available Tools
14 toolscancel_orderAInspect
Cancels an eligible eSIM order before activation/provisioning. Requires a valid session token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | The secure session token returned by verify_agent_otp. | |
| orderId | Yes | The ID of the order to cancel. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the cancellation action and a prerequisite, but does not describe side effects (e.g., irreversibility), authorization details beyond token, 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?
Two concise sentences, no waste. The essential information is front-loaded and easy to parse.
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 no annotations, the description is minimal. It covers the basic purpose and a prerequisite but lacks details on success/failure behavior, eligibility criteria, or post-cancellation effects.
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 baseline is 3. The description reinforces the token requirement and contextualizes orderId as belonging to an eSIM order, but does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action ('cancels'), the resource ('eSIM order'), and a condition ('before activation/provisioning'). It clearly identifies what the tool does, and there is no sibling tool with similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a prerequisite ('Requires a valid session token'), but does not provide guidance on when to use the tool versus alternatives, nor conditions where cancellation is ineligible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_checkout_urlBInspect
Generates a secure checkout and purchase link for a specific eSIM package.
| Name | Required | Description | Default |
|---|---|---|---|
| packageCode | Yes | The package code of the eSIM (e.g. PIK0SW14Q). | |
| discountCode | No | Optional coupon code to pre-apply (e.g. WELCOME10). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states it generates a link but does not disclose behavior on invalid inputs, authentication needs, rate limits, or 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?
Single sentence with no redundant words, front-loaded with the core action. Achieves maximum conciseness for the content provided.
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 is simple with two parameters, but the description does not specify the return format (a URL) or behavior for edge cases. Adequate but not thorough; output schema absence increases burden.
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 parameters are already well-documented. The description adds no additional semantic information beyond the schema, meeting baseline expectations but not exceeding them.
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 verb+resource 'generates...link for a specific eSIM package', which clearly states the tool's purpose. It distinguishes from sibling tools that perform actual purchases or validations, though explicit differentiation is absent.
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 like purchase_esim_with_wallet or validate_coupon. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_esim_catalogAInspect
Queries active travel eSIM data plans. Refines by destination name, country code, or query keywords (e.g. JP, Japan, Japan 100MB, Europe 10GB, USA 30 Days).
| Name | Required | Description | Default |
|---|---|---|---|
| countryCode | No | Destination name, country code, or search keywords (e.g. Japan, JP, Japan 100MB, Europe 10GB). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states 'Queries' implying a read-only operation, but lacks details on idempotency, side effects, or error conditions beyond the simple query scope.
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 redundancy, front-loaded with the core action. Every sentence adds unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool, the description covers the basic purpose and parameter. However, without output schema or annotations, it omits return structure, pagination, and error handling, which could be necessary for effective 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 describes the single parameter 'countryCode' with a clear description. The description adds value with concrete examples (JP, Japan, Japan 100MB, Europe 10GB, USA 30 Days), enriching the schema's information.
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 'Queries' and resource 'active travel eSIM data plans', and differentiates from sibling tools like get_topup_packages by focusing on eSIM catalog queries.
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 querying eSIM plans based on filters, but does not provide explicit guidance on when to use this tool versus alternatives like purchase_esim_with_wallet or get_topup_packages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_knowledge_baseAInspect
Retrieves the official ConnectMeGuru grounding knowledge base, including installation guides, device compatibility, refund policies, and support escalation workflows.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits like read-only. While the name and content suggest a safe read, the description does not explicitly state it is non-destructive or idempotent, leaving ambiguity.
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 with no wasted words. Immediately states the core function and lists key contents. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a clear list of knowledge base topics, the description is adequate. However, it lacks an explicit mention of being a read-only operation, which would complete the behavioral contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100% trivially. According to rubric, 0 params yields baseline 4. No parameter documentation needed.
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 'Retrieves' and identifies the resource 'official ConnectMeGuru grounding knowledge base' followed by concrete content examples (installation guides, refund policies). It clearly distinguishes from sibling tools that handle orders, purchases, and verification.
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 when the agent needs knowledge base information, and sibling tools cover transactional actions. No explicit when-not or alternatives, but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topup_packagesBInspect
Retrieves compatible top-up data packages for an active eSIM. Requires a valid session token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | The secure session token returned by verify_agent_otp. | |
| orderId | Yes | The ID of the active eSIM order. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It only indicates a read operation ('retrieves') and a session token requirement, but does not explain behaviors like error handling, idempotency, or conditions for successful retrieval beyond what the schema already shows.
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 front-loads the core purpose and includes a necessary precondition. Every word earns its place, with no redundancy or fluff.
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 absence of an output schema and annotations, the description should provide more context about the return format (e.g., list of packages with pricing) and how this tool fits into the workflow with siblings like purchase_topup. Currently, it is too minimal to be complete.
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 each parameter has a descriptive comment (token links to verify_agent_otp, orderId identifies active eSIM). The description adds no additional meaning beyond the schema, so a 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 clearly states the verb 'retrieves' and the resource 'compatible top-up data packages' with the context 'for an active eSIM', making the purpose specific and distinct from siblings like purchase_topup or get_esim_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (requires a valid session token) but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_ordersBInspect
Retrieves a paginated list of the authenticated user's eSIM orders and history. Requires a valid session token.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Optional page number (defaults to 1). | |
| limit | No | Optional number of orders per page (defaults to 20). | |
| token | No | The secure session token returned by verify_agent_otp. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only indicates a read operation and token requirement. It does not disclose any additional behavioral traits such as pagination behavior, data freshness, or error scenarios beyond what the schema already implies.
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 with no superfluous words. It effectively communicates the core action. However, it could benefit from a brief note on response format.
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, so the description should at least hint at the return structure (e.g., array of order objects). It does not. Given the lack of annotations and simple parameter set, the description is incomplete for an agent to fully understand the tool's output.
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 baseline is 3. The description adds 'paginated' but this is already implied by the page/limit parameters. No additional semantic meaning is provided 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 retrieves a paginated list of the authenticated user's eSIM orders and history, which is a specific verb and resource. It distinguishes from sibling tools like cancel_order and purchase_esim_with_wallet that have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions requiring a valid session token, which is a prerequisite. However, it does not provide guidance on when to use this tool versus alternatives like get_wallet_transactions or cancel_order, nor does it specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wallet_balanceBInspect
Retrieves the user's current pre-funded wallet balance. Requires a valid session token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | The secure session token returned by verify_agent_otp or a Personal Access Token. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that this is a read-only operation or disclose any side effects, rate limits, or error behaviors.
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 efficiently conveys the purpose and a key requirement, though it could be slightly expanded without losing 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?
The description is adequate for a simple tool with one parameter, but it lacks details about the return value format, which is important given no output schema is provided.
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 already detailed; the tool description adds no additional meaning beyond what the schema provides.
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 the clear verb 'Retrieves' and specific resource 'wallet balance', distinguishing it from sibling tools that handle orders, topups, or catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite of a valid session token but provides no guidance on when to use this tool versus alternatives like get_wallet_transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wallet_transactionsCInspect
Retrieves a paginated list of wallet transaction history. Requires a valid session token.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Optional page number (defaults to 1). | |
| limit | No | Optional number of items per page (defaults to 20). | |
| token | No | The secure session token returned by verify_agent_otp. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read operation but does not disclose behavioral traits such as error handling, rate limits, or what happens with invalid tokens.
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-formed sentence of 11 words. It is front-loaded with the main action. No wasted words, but could benefit from a bit more structure (e.g., listing pagination parameters).
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?
Without an output schema, the description should explain what is returned. It only says 'paginated list' without specifying fields or structure. Given three parameters and no output schema, the description is incomplete for effective usage.
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 documents all three parameters. The description adds no extra meaning beyond stating the token requirement, which is already in the schema. 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 retrieves a paginated list of wallet transaction history. The verb 'retrieves' and resource 'wallet transaction history' are specific. However, it does not explicitly distinguish this tool from siblings like get_wallet_balance, though the different resource makes it obvious.
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 requiring a valid session token, implying it should be used after authentication, but provides no guidance on when to use this tool versus alternatives like get_wallet_balance, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_esim_with_walletAInspect
Purchases an eSIM package directly in chat using the user's wallet balance. If balance is insufficient, returns a magic link to top-up.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | The secure session token returned by verify_agent_otp or a Personal Access Token. | |
| packageCode | Yes | The package code of the eSIM (e.g. PIK0SW14Q). | |
| discountCode | No | Optional coupon code (e.g. WELCOME10). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the purchase and insufficient balance handling but omits success effects (e.g., activation, delivery method) and does not mention side effects like wallet deduction.
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 the primary action, no extraneous information. Efficient and clear.
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, the description should explain the post-purchase outcome (e.g., what the user receives, any next steps). It also lacks information on potential issues like refunds or activation delays.
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 documents each parameter. The description does not add additional semantic value beyond what is 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 purchases an eSIM package using wallet balance, and specifies the fallback for insufficient balance. This distinguishes it from siblings like purchase_topup and get_checkout_url.
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 context (direct purchase via wallet) but does not explicitly state when to use this tool versus alternatives like purchase_topup or get_checkout_url. No prerequisites or when-not guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_topupAInspect
Purchases a compatible top-up package using the wallet balance. Requires a valid session token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | The secure session token returned by verify_agent_otp. | |
| orderId | Yes | The ID of the active eSIM order. | |
| packageCode | Yes | The top-up package code to purchase. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates that the purchase uses wallet balance (implied deduction) and requires a token, but omits details on success/failure handling, reversibility, or idempotency.
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 wasted words, and front-loaded with the core 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?
The description covers the main action and requirement, but could be more complete by mentioning that the package must be from get_topup_packages or that the order must be active.
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 description reinforces the token's origin (verify_agent_otp) but does not add significant meaning beyond what the schema already provides.
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 ('Purchases') and resource ('compatible top-up package') and clearly distinguishes from siblings like purchase_esim_with_wallet and get_topup_packages.
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?
It mentions the session token requirement from verify_agent_otp, but does not explicitly state when not to use this tool or compare with alternatives like other purchase methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refresh_esim_usageBInspect
Requests a real-time data usage update for an active eSIM from the carrier. Requires a valid session token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | The secure session token returned by verify_agent_otp. | |
| orderId | Yes | The ID of the eSIM order. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Does not disclose whether the tool is idempotent, destructive, or has side effects. No mention of authentication beyond token, rate limits, or error conditions. Since annotations are absent, the description should provide more behavioral context.
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 focused sentences with no wasted words. Action and requirement are 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?
Omits important details such as return value, success/failure behavior, and prerequisites beyond token. Given no output schema and no annotations, the description inadequately prepares an agent for correct invocation.
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?
While schema descriptions cover both parameters, the description adds that token is required, contradicting the schema where token is optional (only orderId is required). This inconsistency undermines clarity.
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 requests a real-time data usage update for an active eSIM from the carrier, using specific verbs and resource. This distinguishes it from siblings like cancel_order or get_esim_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only mentions a prerequisite (valid session token) but provides no guidance on when to use this tool versus alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_agent_otpAInspect
Sends a 6-digit OTP code to the customer's email address for in-chat authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address of the customer. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action of sending an OTP. It does not disclose potential delays, rate limits, error handling (e.g., invalid email), side effects, 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 of 15 words, directly front-loading the action and purpose with zero wasted content. It is optimally concise.
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 one-parameter tool with no output schema, the description covers the core action adequately but lacks details on expected return value, confirmation, or error cases. It is sufficient but minimal.
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 additional detail beyond the schema; it simply repeats 'email address'. No format, validation, or constraint information is provided that isn't 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 the verb 'sends', specifies the resource '6-digit OTP code', the recipient's email address, and the context 'for in-chat authentication'. It effectively distinguishes from sibling 'verify_agent_otp' which handles verification.
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 in an in-chat authentication flow but does not explicitly state when to use this tool versus alternatives, such as before verify_agent_otp. No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_couponAInspect
Validates a discount coupon code for checkout. Note: User login is mandatory to validate a coupon. If this returns a 401 Unauthorized error, you must inform the user that they need to log in (by sending an OTP using send_agent_otp) before they can apply a coupon.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The coupon code to validate (e.g. WELCOME10). | |
| packageCode | Yes | The eSIM package code to check applicability for. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the login requirement and potential 401 error, but does not explicitly mention that the tool is read-only or non-destructive. However, it adds meaningful context beyond the schema.
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 with no wasted words. Primary purpose is stated first, then the important note about login requirement, making it easy to scan.
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 validation tool with two well-documented parameters and no output schema, the description covers purpose, prerequisites, and error handling. It doesn't describe the response format, but that is often inferred for validation endpoints.
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 baseline is 3. The description does not add extra meaning or constraints beyond what the schema already provides for the two parameters.
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 'validates' and resource 'discount coupon code for checkout', clearly distinguishing it from sibling tools like purchase_esim_with_wallet or send_agent_otp. No other tool handles coupon validation.
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 that user login is mandatory and provides actionable guidance on handling a 401 error by informing the user to log in via send_agent_otp. This helps the agent decide when to use this tool and how to recover from auth failures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_agent_otpBInspect
Verifies the email OTP code and returns a session token for wallet purchases.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The 6-digit OTP code entered by the user. | |
| Yes | The email address of the customer. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal behavioral disclosure beyond stating it verifies OTP and returns a session token; no details on OTP expiration, session token validity, or side effects like one-time use of OTP.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded and contains 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 the simple structure and no output schema, the description covers basic functionality but lacks context about session token details, error behavior, or usage flow.
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 parameter descriptions are adequate; the description adds only the context of 'email OTP code' but no new semantics 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 verifies an email OTP code and returns a session token for wallet purchases, distinguishing it from siblings like send_agent_otp (sends OTP) and purchase_esim_with_wallet (uses session token).
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 explicit guidance on when to use this tool or when not to use it; no mention of prerequisites like needing to have sent the OTP first via send_agent_otp.
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!