base64_decodeDecodes Base64 or Base64URL encoded data back to text, validating input to prevent mojibake.
Decode Base64 (standard or URL-safe) back to text. Reports whether the input was valid rather than returning mojibake. Web version: https://buildutilities.com/base64-codec
| Name | Required | Description | Default |
|---|---|---|---|
| encoded | Yes | Base64 or base64url input |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral value by stating that it reports whether the input was valid rather than returning mojibake, and it mentions URL-safe support. This goes beyond annotations and helps the agent understand 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?
The description is two concise sentences, front-loaded with the core action and validity behavior. It includes a web link which is extra but not harmful. No unnecessary verbiage; every sentence 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 single-parameter tool with annotations covering safety, the description covers the input format, output (text), and validity reporting. It does not detail the exact return structure (e.g., whether it returns an error object), but the statement about reporting validity implies that. Minor gap, but overall adequate for an agent to call it correctly.
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 already documents the single 'encoded' parameter with description 'Base64 or base64url input', achieving 100% coverage. The description restates this by mentioning 'standard or URL-safe' but adds no new meaning beyond the schema. Per the baseline, a 3 is appropriate when the schema does the heavy lifting.
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 'Decode', the resource 'Base64', and the output 'text'. It also distinguishes from siblings by mentioning both standard and URL-safe variants, and the validity-reporting behavior. The purpose is unambiguous and differentiates from encode/decode 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?
The description provides clear context (decoding Base64 back to text) but does not explicitly name alternative tools or state when not to use it. It implies usage for any Base64-encoded string, which is sufficient for this simple tool. No exclusions or comparisons are given, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.