Percent-encode or decode a string or query map.
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": "url_codec"
}
}| 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?
No annotations are provided, so the description carries the full burden, but it discloses almost no behavior beyond the basic operation. It does not say which percent-encoding variant is used (e.g., space as %20 vs +), how invalid input is handled on decode, or whether full URLs or only components are accepted, leaving significant operational gaps.
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 front-loaded sentence with no filler, and the encode/decode distinction is stated immediately. Every word earns its place.
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 codec tool with no annotations, no output schema, and a vacuous input schema, the description should specify input field names, encoding variants, error behavior, and return format. None of these are covered, so an agent cannot reliably call the tool without trial and error.
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 schema defines zero named parameters and is essentially an open POST body, so the baseline is 4, but the description only hints that input may be 'a string or query map' without naming body fields or structure. This adds some meaning beyond the empty schema but still leaves the agent unsure how to construct a valid request.
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 states a specific verb pair (percent-encode or decode) and the resource (a string or query map), so an agent knows exactly what operation is performed. It does not explicitly differentiate itself from sibling utilities like base64 or html_sanitize, which also transform text, so it stops 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?
There is no guidance on when to choose this tool over alternatives such as base64 for encoding or html_sanitize for escaping text. The intended use is only implied by the word 'percent-encode', and there are no exclusions or prerequisites stated.
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.