Fetch a URL, extract title/description/OG/Twitter/canonical/JSON-LD. Not for body text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL. | |
| headers | No | Headers to forward (Authorization, Cookie…). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / url / descriptionAdded value: +"Page URL."Input schema / properties / headersAdded value: +{
+ "type": "object"
+}Input schema / properties / url / descriptionRemoved value: -"URL to fetch (http:// or https://)."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true annotation, the safety profile is already disclosed. The description adds the scope of extraction (specific metadata types) and the 'not for body text' constraint, which is behavioral context. However, it omits details like handling of auth headers, redirects, or error cases, but given the annotation coverage, the description adds reasonable value without overexplaining.
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 a single sentence that immediately states the action and output fields, followed by a terse exclusion. Every word earns its place, and there is no fluff or repetition of structured data.
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?
The tool is simple with two parameters and no output schema, but the description lists all expected extracted fields, covering return expectations. The 'Not for body text' exclusion helps prevent misuse. While it doesn't discuss quirks like dynamic sites or JSON-LD variants, the description is complete enough for a straightforward metadata fetcher among a well-named sibling set.
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 100%, with both 'url' and 'headers' having clear descriptions. The tool description doesn't add parameter-specific details beyond what the schema provides, so it meets the baseline without needing to compensate for gaps.
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 verb ('Fetch') and resource ('URL') and lists exactly what is extracted: title, description, OG, Twitter, canonical, JSON-LD. This clearly distinguishes it from siblings like fetch_html, fetch_extract, and html_to_markdown, making its purpose unambiguous.
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 a clear exclusion ('Not for body text'), signaling that this tool is for metadata extraction only. It doesn't explicitly name alternative tools like fetch_html for body text, but the when-not-to-use guidance is strong and sufficient for typical selection scenarios.
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.
Several tools overlap in fetching and processing web content (fetch_extract, fetch_html, fetch_metadata, html_to_markdown), which could confuse an agent. However, descriptions clarify output types, so most tools are distinguishable.
Names follow mixed conventions: verb_noun (fetch_html, remove_background), noun_verb (csv_query, rss_parse), and noun_noun (tool_catalog, screenshot_url). Each name is descriptive, but the lack of a consistent pattern makes it harder to guess tool names.
With 17 tools, the count is slightly above the ideal 3-15 range but still manageable. The inclusion of 5 meta-tools (pricing, tool_catalog, task_recipes, memory_snippet, use_tool) inflates the count but serves a discovery purpose.
The toolkit covers a broad range of web and data tasks (fetch, parse, query, convert, image, SEO). Minor gaps exist (e.g., no OCR, no image editing), but use_tool can dynamically access additional tools, mitigating incompleteness.