list_esimseSIMs on the account with status, data left and validity. Search by ICCID, package name or code; filter by status.
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "list_esims"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | Default 20 | |
| search | No | ||
| status | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so safety is covered. The description adds that each result carries status, remaining data and validity, which is useful, but it says nothing about pagination behavior or result ordering for a paginated endpoint.
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?
Roughly two clauses, front-loaded with the resource and what the rows contain, then the search/filter capabilities. Efficient with no wasted words, though the second clause is slightly terse for the amount of behavior it is conveying.
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?
There is no output schema, so the description does well to name status, data left and validity as returned fields. However, for a paginated, 4-parameter listing endpoint it omits pagination semantics, ordering, and how the search/status filters combine, leaving real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (just limit's default of 20), so the description must compensate. It usefully explains that the search term accepts ICCID, package name or code and that status is a filter, but leaves the page parameter entirely undocumented and gives no format hints for status values beyond the enum.
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 the resource (eSIMs on the account) and previews the returned fields (status, data left, validity), which is more than a restatement of the name. It does not, however, distinguish this list tool from siblings like get_esim_usage or get_esim_live_status, so an agent must infer which eSIM view to pick.
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?
"Search by ICCID, package name or code; filter by status" implies how to use the tool but never states when to choose it over the sibling eSIM/usage tools. Usage is implied rather than contrasted with alternatives, so it clears the minimum-viable bar but no more.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.