Extract clean, token-dense markdown from a public URL or raw HTML string. Includes 3 free calls per caller per rolling 24 hours, then costs USD 0.05 per successful extraction via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url_or_html | Yes | The public URL or raw HTML string to convert into markdown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that only public URLs are accepted, that there is a rolling 24-hour free quota, and that successful extractions cost money after that. This is strong transparency for a simple extraction tool, though it does not mention failure behaviors.
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?
Two concise sentences front-load the core purpose and immediately cover usage constraints and pricing. Every sentence contributes useful information with no filler.
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 no output schema, the description is nearly complete: it names the input, the output format (markdown), and the cost model. It does not describe error cases or expected response structure, but the simple scope makes this a minor gap.
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 coverage is 100% and the schema description already explains that the parameter accepts a public URL or raw HTML string. The tool description repeats this without adding meaning beyond the schema, so the baseline score of 3 is appropriate.
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 action ('Extract clean, token-dense markdown') and a clear resource ('public URL or raw HTML string'). It fully distinguishes the tool's purpose even without sibling 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 clearly indicates when to use the tool: whenever clean markdown is needed from a public URL or raw HTML. It also provides relevant operational context about free quota and paid usage, though it does not explicitly discuss alternatives or exclusions.
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.
With only one tool, there is no possibility of confusion or overlapping purposes. The tool's purpose is clearly defined and distinct.
The single tool name 'clean_extract' uses a clear verb_noun pattern and is descriptive. Consistency cannot be fully assessed with one tool, but the naming style is reasonable.
A single tool feels too thin for a server, even for a narrow purpose. Users may expect additional utilities like batch processing or output formatting, making the count borderline inadequate.
The tool covers the core extraction functionality (URL or raw HTML to markdown), but there are minor gaps such as handling multiple URLs, custom extraction options, or output validation. The domain is narrow, so the single tool is partially complete.