Convert base64-encoded file contents to Markdown.
filename is required and drives format detection (e.g. "report.docx").
Intended for programmatic MCP clients; for anything with a URL, prefer
convert_url.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| content_base64 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose that the output is Markdown and that filename drives format detection, which is useful. However, it does not mention constraints like size limits, invalid base64 handling, or whether any external call is involved. The description is minimally acceptable but leaves 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 concise: three short sentences with no filler. The main purpose is front-loaded, followed by essential parameter context and a routing note. 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 simple conversion tool, the description covers the main purpose, key parameter, and an alternative sibling. However, it omits guidance about which formats are supported, despite the existence of list_supported_formats as a sibling. It also does not mention error cases or output structure beyond 'Markdown'. Adequate but with noticeable 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 0%, so the description must compensate. It does explain filename semantics with an example ('report.docx') and notes that it drives format detection. content_base64 is only implied by the tool name and overall description, and there is no detail on the expected base64 format (e.g., raw vs data URI). This is partial compensation, not complete.
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 action: converting base64-encoded file contents into Markdown. It also differentiates itself from the sibling tool convert_url by explicitly noting that URLs should use the other tool. This gives an agent a precise, non-ambiguous understanding of what this tool does.
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 explicit usage guidance: it is intended for programmatic MCP clients, and it explicitly says to prefer convert_url for anything with a URL. It also highlights that filename is required and drives format detection, which is essential for correct usage. This is strong routing information.
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.
Each tool has a distinct role: the two conversion paths (base64 vs URL) are clearly differentiated by input source and usage guidance, and the two informational tools (format support, usage quota) do not overlap.
convert_base64, convert_url, and list_supported_formats follow a consistent verb_noun pattern. usage_status is a minor resource-style exception but remains readable and does not create real confusion.
Four tools are well-scoped for this service: two conversion entry points plus two supporting tools for format discovery and usage awareness. No redundant or filler tools are present.
The surface covers the full workflow for a stateless conversion service: ingest via base64 or URL, discover supported formats and limits, and check quota before conversion. There are no obvious dead ends or missing core operations.