Fetch a web page and return it as clean markdown (or plain text), with internal and private addresses refused for safety. A reliable read tool an agent can call before acting on a link. Paid tool: $0.003 per fetch via x402 (USDC on Base, Arbitrum, Polygon or Solana).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| format | No | markdown |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses that internal/private addresses are refused for safety, that it converts to markdown/plain text, and importantly, that it's a PAID tool with specific pricing ($0.003 per fetch) and payment rails (x402 with USDC on specific chains). This payment disclosure is critical behavioral transparency that would otherwise be invisible to the agent.
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?
Three sentences, each serving a distinct purpose: function, safety posture, and pricing. Well-front-loaded with the core functionality first. The third sentence about pricing could arguably be trimmed, but the cost disclosure is essential behavioral information that the agent needs before invoking, so it 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?
Given the tool has only 2 simple parameters, no output schema, and no annotations, the description covers the essential ground: what it does, safety constraints, and cost. The description adds necessary pricing context (critical for agents) and the safety posture. It could mention response size limits, timeout behavior, or error handling, but for a simple fetch tool the coverage is reasonably complete.
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 for explaining parameters. The description explains the `format` parameter implicitly ('markdown or plain text') and gives context for `url` (fetches web pages, refuses internal/private addresses). However, it doesn't explicitly enumerate the format parameter's possible values or explain the default behavior in detail, leaving ambiguity about exact accepted values beyond markdown/plain text.
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 tool fetches a web page and returns clean markdown or plain text, with internal/private addresses refused. This distinguishes it from sibling tools, which are all focused on EU compliance, IBAN/VAT validation, and transaction status — none of which read URLs. The purpose is clear with a specific verb+resource, though it could more explicitly contrast with siblings.
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 positions it as 'a reliable read tool an agent can call before acting on a link,' which gives implied usage context. However, it doesn't explicitly state when NOT to use it or mention alternatives among the siblings (though none obviously compete). The 'before acting on a link' framing provides context but lacks explicit exclusion criteria.
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.
Many tools are clearly separate (validate_vat, validate_iban, token_status, tx_status), but several overlap by combining the same core checks: check_counterparty_eu, must_verify_before_pay, tx_preflight, and invoice_to_pay_dossier_eu all screen sanctions and/or do VIES/IBAN checks. The descriptions help, but the boundaries between a KYB check, a payment gate, and a transaction preflight are subtle enough that agents can easily pick the wrong one.
Names are uniformly lowercase snake_case, and patterns like validate_*, prepare_*, and *_eu give some predictability. However, the verb style is inconsistent: some tools are verb-led (read_url, screen_sanctions_eu, lookup_company_eu), others are noun-led (market_data, token_status, agentllm_micro), and paid/prepare pairs do not share a consistent naming scheme.
24 tools is at the upper edge of what is reasonable, and the server mixes several unrelated concerns: EU VAT/invoice compliance, sanctions/KYB, US import readiness, AI disclosure/LLM inference, market data, URL reading, and transaction status. The core comply-to-pay workflow is well represented, but the extra domains make the tool list feel heavier and less like a single coherent service.
The EU invoice/payment compliance flow is fairly complete: e-invoice validation, VAT rules, VIES, IBAN, sanctions, transaction preflight, payment decisions, bookkeeping statements, and receipt verification are all covered. Obvious gaps remain for such a broadly named server: no export/other product compliance, no broader EU regulatory coverage, and the key invoice guard explicitly does not cover duplicate-ledger detection, internal approval, or delivery checks.
