list_visas
Visas the user holds — type, number, validity, entries used.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Visas the user holds — type, number, validity, entries used.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and idempotentHint annotations already cover behavioral safety. The description adds no extra information about side effects, data sources, or potential errors. It only confirms the scope (user holds), which is minimal added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that lists the key attributes. It is efficiently written and avoids redundancy, though the dash-separated list feels slightly telegraphic. 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?
The description names the fields but does not specify the output structure (e.g., array of objects, ordering, or any filtering). Since there is no output schema, the description should ideally clarify the expected response format. It is partially complete but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so there is nothing to describe. The absence of parameters is clear and requires no additional explanation. Perfect score.
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 that the tool lists visas the user holds and enumerates key fields (type, number, validity, entries used). This is specific enough to distinguish from create/update/delete operations, though it could be more explicit in saying 'list' or '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 explicit guidance is provided on when to use this tool. There is no mention of alternatives like get_visa_status or get_visa (if such exists), nor any context about querying a single visa vs. all visas. The description relies solely on the tool name for intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.