Skip to main content
Glama
ralf9090

Agent Kiosk

web_extract

Read-onlyIdempotent

Extract clean, LLM-ready Markdown from a web URL, while scanning the page for hidden prompt injection traps targeting AI agents.

Instructions

Extract clean, LLM-ready Markdown from any web URL while automatically scanning the page for hidden Prompt Injection traps targeting AI agents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesFull URL to extract (must start with http:// or https://)
max_lengthNoMaximum markdown character length to return (500-25000, default: 8000)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.5.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real value by disclosing the output format (Markdown) and a non-obvious secondary behavior: automatic scanning for hidden prompt-injection traps. It stops short of saying what happens when a trap is found or whether scanning affects the returned content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that states the extraction target first and the security side-benefit second. No filler, no repetition of the tool name, and nothing that could be dropped without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must convey the return shape, and it does (Markdown, length-bounded by max_length). The one gap is the injection-scanning feature: it is announced but the description never explains how findings surface to the agent, leaving a promised behavior underspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both url and max_length are already documented with format and range by the schema. The description adds nothing about parameter behavior (e.g., truncation semantics for max_length), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb (Extract) and resource (clean, LLM-ready Markdown from any web URL), which is far more informative than a tautology. It does not explicitly distinguish itself from siblings like domain_intel or security_audit, but no sibling competes for generic page fetching, so the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'any web URL' but there is no explicit when-to-use, when-not-to-use, or alternative routing. An agent can infer this is the general-purpose fetch tool, but nothing tells it when domain_intel or security_audit should be preferred instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.