Skip to main content
Glama
MarcinWolnyEU

European Search Engine - Staan MCP

Staan web search

web_search
Read-onlyIdempotent

Search the internet and return ranked results with titles, URLs, snippets, and optional full page content, with domain and market filters.

Instructions

Search the internet. Returns ranked results as a JSON array of {"title", "url", "snippet", "full_content"?}.

Input Schema

NameRequiredDescriptionDefault
queryYesSearch query in natural language.
marketNoLanguage-country market(s) to search: fr-fr, de-de, en-us, en-gb, en-fr, en-ca, en-au, en-in, en-ie, en-nz, en-za, en-sg. Pass one, a list, or wildcards ('en-*' for all English markets, '*' for all). Several markets are merged by rank and de-duplicated by URL; each is a separate billable request, so prefer one unless you need broader coverage.en-gb
offsetNoOffset of the first result, for paging: pages hold up to 10 results, at most 40 per query.
full_contentNoPage text returned with each result. Default 'none' omits it; 'markdown' adds it and makes the response very large; 'html' is much larger still.none
exclude_domainsNoDrop results from these sites, e.g. ['pinterest.com']; subdomains too. At most 10. Not with include_domains.
include_domainsNoOnly return results from these sites, e.g. ['wikipedia.org']; subdomains match. At most 10. Not with exclude_domains.
simple_responseNofalse returns the raw Staan response, one entry per market, instead of the flat list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, openWorld, idempotent and non-destructive, so the safety profile is covered. The description's only added value is the return shape ('ranked results as a JSON array of {title, url, snippet, full_content?}'), which matters because there is no output schema. It says nothing about result freshness, billing implications of multiple markets, or how results are ranked.

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?

Two short sentences with zero filler, and the core purpose is front-loaded before the return detail. Nothing repeats the name or the schema.

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 correctly spends its budget describing the return value, and the rich input schema covers all parameter behavior. The main remaining gap is sibling differentiation, which is a usage-guidance issue rather than missing mechanics.

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 all seven parameters are already fully documented, including market wildcards, paging offsets, size warnings for full_content, and the include/exclude mutual exclusion. The description adds no parameter meaning beyond the return fragment 'full_content?', 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?

States a specific verb and resource ('Search the internet') and adds the return shape, which is more than the title 'Staan web search' conveys. It does not distinguish itself from the sibling 'answer' tool, so an agent cannot tell from the description which one to pick.

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 only implied by 'Search the internet'; there is no statement of when to prefer this over the sibling 'answer', nor any exclusions. The agent must infer the routing decision on its own.

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

Deploy Server

Other Tools