Official ConnectMeGuru MCP server: search 190+ travel eSIM data plans and buy in-chat.
Scored across 5 tools
Each tool targets a distinct resource and action: catalog lookup, coupon listing, coupon validation, checkout link generation, and knowledge base retrieval. The two coupon-related tools are clearly differentiated by their descriptions (listing vs. validation).
All tool names follow a consistent verb_noun snake_case pattern (get_available_coupons, get_checkout_url, get_esim_catalog, get_knowledge_base, validate_coupon). The single non-get verb (validate) is semantically appropriate and still fits the same convention.
Five tools is well-scoped for an eSIM sales and support server. Each tool has a clear, non-overlapping role in the purchase and information workflow.
The surface covers the core pre-purchase journey (catalog, coupons, checkout) and provides grounding via the knowledge base. Minor gaps exist for post-purchase actions like order status or eSIM management, but these may be intentionally out of scope or handled via support workflows.
Retrieves currently active official ConnectMeGuru promotional coupon codes with their descriptions and applicability.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| content | No | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the dataset is restricted to currently active, official coupons and includes their descriptions and applicability, which tells the agent what will and will not come back.
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 tightly written sentence with the resource and its scope qualifiers front-loaded. No filler, no restatement of the title, nothing that could be cut without losing meaning.
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 zero-parameter read-only tool with full annotation coverage and an output schema, the description carries enough: what it returns, and that results are limited to active official coupons. The only gap is the missing routing hint toward validate_coupon, which keeps it short of a 5.
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?
There are zero parameters, so there is nothing for the description to disambiguate and the 4 baseline applies. The description correctly avoids inventing filter parameters that the empty schema does not support.
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 names a specific verb ('Retrieves') and resource ('currently active official ConnectMeGuru promotional coupon codes'), and the scope qualifiers make it clearly a listing operation rather than a single-item lookup. It does not explicitly distinguish itself from the sibling validate_coupon, so an agent has to infer the split between listing active coupons and validating a specific one.
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?
Usage is only implied by the 'currently active' scope — the description never states when to call this instead of validate_coupon, nor any prerequisite or exclusion. An agent can reasonably infer 'browse available coupons' vs 'check one coupon', but the routing is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a secure web checkout and purchase link on connectmeguru.com 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). |
| Name | Required | Description |
|---|---|---|
| content | No | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context beyond that: the link is hosted on connectmeguru.com and is a purchase/checkout URL rather than an in-app action. It does not disclose link expiry, single-use behavior, or whether repeated calls return the same URL, which matters for a link-generation tool.
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 sentence that front-loads the action and the resulting artifact, with the domain qualifier placed before the scope. Nothing is wasted and nothing is buried.
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 an output schema present and annotations covering the safety profile, the description need not explain return values or permissions, and it covers the core purpose adequately for a two-parameter tool. The remaining gap is behavioral rather than structural: nothing about link lifetime, reuse, or coupon validation ordering.
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 only two parameters, so the schema already explains packageCode and discountCode including examples. The description's only parameter-adjacent statement, 'for a specific eSIM package,' restates the required parameter rather than adding format, constraint, or coupon-application semantics. Baseline 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 gives a specific verb (generates), a specific artifact (secure web checkout and purchase link), a domain (connectmeguru.com), and scope (a specific eSIM package). This clearly separates it from siblings like get_esim_catalog, get_available_coupons, and validate_coupon without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use, when-not-to-use, or alternative routing. Critically, the discountCode parameter implies a coupon flow, yet the description never says whether the coupon should be validated first via the sibling validate_coupon or discovered via get_available_coupons. The purchase intent is inferable but no guidance is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queries active travel eSIM data plans. Refines by destination name, country code, or query keywords (e.g. JP, Japan, Europe 10GB, USA 30 Days).
| Name | Required | Description | Default |
|---|---|---|---|
| countryCode | No | Destination name, country code, or search keywords (e.g. Japan, JP, Europe 10GB). |
| Name | Required | Description |
|---|---|---|
| content | No | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds that only 'active' plans are returned, which is useful scope context, but says nothing about authentication, result limits, or pagination.
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, zero waste, with the core purpose front-loaded before the refinement detail. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the single parameter is fully covered. The only shortfall is the absence of usage routing against the sibling tools, which for a simple read-only catalog search is 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?
Schema description coverage is 100%, so the single parameter is fully documented in the schema, which is the baseline for a 3. The description's extra examples ('USA 30 Days', 'Europe 10GB') add only marginal value over the schema's own examples ('Japan, JP, Europe 10GB').
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?
States a specific verb ('Queries') and resource ('active travel eSIM data plans'), so the agent immediately knows the domain. Siblings (coupons, checkout URL, knowledge base) cover entirely different resources, so differentiation is implicit rather than stated.
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 phrase 'Refines by destination name, country code, or query keywords' implies the intended search usage, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the official ConnectMeGuru grounding knowledge base, including installation guides, device compatibility, refund policies, and support escalation workflows.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| content | No | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds almost nothing beyond naming the content: it does not say whether the whole base is returned, whether results are static or live, or how it is meant to be consumed. For a zero-parameter tool this leaves the agent with little operational 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?
One tight sentence that front-loads the verb and resource and then lists the included material. Nothing is wasted, though it is a single sentence and stops short of giving the agent any routing or usage instruction.
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?
An output schema exists, so return structure need not be explained, and annotations carry the safety profile. However, for a grounding tool whose value depends on when and how the agent should consult it versus answering directly, the description omits that operational context entirely.
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 takes no parameters, which is the baseline 4. The description correctly implies a parameterless full retrieval and does not invent filter semantics that do not exist.
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?
States a specific verb (Retrieves) and resource (ConnectMeGuru grounding knowledge base), then names what it contains. It is clearly distinct from every sibling, which are all transactional or account-scoped 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?
Usage is implied: the tool exists so the agent can ground answers about installation, compatibility, refunds, and escalation. But there is no explicit when-to-use/when-not-to-use guidance and no named alternative for policy or workflow questions. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates an official promotional discount coupon code for eSIM checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The coupon code to validate (e.g. WELCOME10). | |
| packageCode | No | Optional eSIM package code to check applicability for. |
| Name | Required | Description |
|---|---|---|
| content | No | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful constraint that only 'official promotional' codes are honored, but says nothing about invalid-code behavior, rate limits, or applicability checks.
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 front-loaded sentence with no filler or redundancy. Every word contributes to identifying the 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?
For a simple two-parameter read-only validator with a full-coverage schema and an output schema covering return values, the description is nearly sufficient. It could mention what an invalid result implies, but that is reasonably delegated to the output 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 description coverage is 100%, so both parameters are already documented in the schema; the description adds only the qualifier that codes are 'official promotional' ones. Baseline 3 is appropriate when the schema carries parameter semantics.
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?
States a specific verb (validates) and resource (coupon code) with domain scope (eSIM checkout), which cleanly separates it from get_available_coupons. It does not explicitly name a sibling, so it falls short of a 5.
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 phrase 'for eSIM checkout' implies the usage context, but there is no explicit when-to-use versus get_available_coupons (which lists codes) or any prerequisite/ordering guidance. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cancel_orderget_esim_catalog1 field changedInput schema / properties / countryCode / descriptionPrevious value: -"Destination name, country code, or search keywords (e.g. Japan, JP, Japan 100MB, Europe 10GB)."New value: +"Destination name, country code, or search keywords (e.g. Japan, JP, Europe 10GB)."get_topup_packagesget_user_ordersget_wallet_balanceget_wallet_transactionspurchase_esim_with_walletpurchase_topuprefresh_esim_usagesend_agent_otpvalidate_coupon2 fields changedInput schema / properties / packageCode / descriptionPrevious value: -"The eSIM package code to check applicability for."New value: +"Optional eSIM package code to check applicability for."Input schema / requiredPrevious value: -[
- "code",
- "packageCode"
-]New value: +[
+ "code"
+]verify_agent_otpcancel_orderget_available_couponsget_checkout_urlget_esim_catalogget_knowledge_baseget_topup_packagesget_user_ordersget_wallet_balanceget_wallet_transactionspurchase_esim_with_walletpurchase_topuprefresh_esim_usagesend_agent_otpvalidate_couponverify_agent_otpOfficial MCP server for MAQAMI, a hotel and flight booking platform with 3M+ hotels.
Official IPinfo MCP Server - IP intelligence tools for AI assistants
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Glide's official MCP server — build, manage, and operate GlideOS apps, data, and workflows.
Add one secure layer between your agents and this server.
