Skip to main content
Glama

superbuy_fetch

Fetches raw responses from Superbuy.com pages for API exploration, with custom method, body, and content type to inspect endpoints.

Instructions

Ruwe fetch binnen de Superbuy-tab (alleen *.superbuy.com), voor API-verkenning.

Input Schema

NameRequiredDescriptionDefault
urlYes
bodyNo
methodNoGET
max_charsNo
content_typeNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist, so the description carries the full burden, yet it only discloses the domain restriction. It never says that method/body allow non-GET requests, whether auth/cookies are supplied automatically, whether responses are truncated (max_chars), or how errors surface — all critical for a tool that can mutate state.

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

Conciseness4/5

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

A single short sentence with the domain restriction front-loaded and no filler. It is efficiently sized, though the brevity is partly under-specification rather than economy.

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

Completeness2/5

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

An output schema exists so return values needn't be explained, but for a five-parameter HTTP tool with zero annotation coverage the description omits too much: write capability, authentication, truncation and error behavior are all unstated. The domain restriction alone is insufficient context to call it safely.

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

Parameters2/5

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

Schema description coverage is 0% across five parameters, and the description only constrains the url host. Nothing explains method defaulting to GET, what body/content_type expect, or that max_chars truncates the returned payload, so the description fails to compensate for the schema gap.

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?

States a specific action (raw fetch) and the resource scope (Superbuy tab, restricted to *.superbuy.com), which separates it from siblings like superbuy_captures, search or details that presumably return structured data. It is clear enough to identify the tool, though 'raw fetch' is never spelled out as an HTTP request.

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?

'voor API-verkenning' (for API exploration) hints at the intended context, so an agent can infer this is the exploratory/low-level option versus the structured siblings. However it names no alternative and gives no when-not conditions, leaving the choice of this tool vs superbuy_captures to inference.

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