Convert a public HTTPS page into structured Markdown via an isolated remote fetch after explicit consent, saving output as zip or Markdown in a chosen directory.
Convert one public HTTPS page after explicit consent to Markovo's isolated remote fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| out_dir | Yes | ||
| max_credits | Yes | ||
| poll_attempts | No | ||
| download_format | No | zip | |
| accept_remote_fetch | Yes | ||
| poll_interval_seconds | No |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two meaningful traits: the fetch is remote/isolated and requires explicit consent. It omits that max_credits is spent and that the call polls for completion (poll_attempts/poll_interval_seconds), which are significant cost and latency behaviors for a 7-param tool.
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?
A single dense sentence with the precondition (consent) and scope front-loaded, and no filler. Nothing in it is redundant.
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 7-parameter tool with zero schema descriptions, no annotations, and no output schema, a one-line description is far too thin. The mandatory credit budget, output directory, and polling parameters are essential to correct invocation and go unaddressed.
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% across 7 parameters, so the description must compensate and largely fails to. It only hints at url being public HTTPS and consent via accept_remote_fetch; out_dir, max_credits, poll_attempts, poll_interval_seconds, and download_format are entirely unexplained anywhere.
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?
States a specific verb (Convert) and resource (one public HTTPS page) plus the mechanism (Markovo's isolated remote fetch). This implicitly separates it from the local sibling markovo_convert, though the sibling is never named.
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?
'after explicit consent' signals a required precondition, and 'one public HTTPS page' bounds the use case. However, it never states when to prefer this remote variant over markovo_convert, nor any exclusion conditions beyond the URL type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.