Skip to main content
Glama

Web search

web_search
Read-onlyIdempotent

Search the live web and get ranked results with the relevant passages already extracted from each page. Use search_depth 'advanced' for research questions, 'basic' for a quick lookup. Set include_answer to get a grounded summary whose quotes are checked against their sources.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoRestrict to the last N days.
queryYesThe search query.
topicNogeneral
max_resultsNo
search_depthNoHow much work to do. advanced expands the query and reads more pages.standard
include_answerNo
exclude_domainsNo
include_domainsNoOnly return results from these domains.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already mark the tool as read-only and idempotent. The description adds behavioral detail beyond the schema: results come with pre-extracted passages and the grounded summary has quotes checked against sources. No contradiction with annotations.

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 sentences with no filler: the first states the core purpose and output shape, the second gives targeted parameter guidance. Every sentence earns its place and the key information is front-loaded.

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?

The description adequately explains how to invoke the tool for common cases, including depth and summarization behavior. It does not detail the response format or compare with extract_url, but the annotations and schema fill enough gaps for a search tool.

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 50%, and the description adds meaningful semantics to search_depth and include_answer. However, it does not explain topic, max_results, or domain filtering parameters, leaving the agent to rely on schema defaults for those.

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

Purpose5/5

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

The description states a specific verb and resource: 'Search the live web and get ranked results with the relevant passages already extracted from each page.' This clearly distinguishes the tool from the sibling extract_url, which focuses on URL extraction rather than live search.

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

Usage Guidelines4/5

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

Provides explicit parameter guidance: 'Use search_depth advanced for research questions, basic for a quick lookup' and 'Set include_answer to get a grounded summary.' This gives actionable context, though it does not mention when to prefer web_search over extract_url.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

The two tools have clearly distinct input modes and purposes: web_search is used to discover URLs via query, while extract_url is used to fetch and read content from known URLs. Even though both can return relevant passages, the starting point is unambiguous—search when you need to find pages, extract when you already have the URL.

Naming Consistency4/5

Both names are lowercase and underscore-separated, but extract_url follows a clear verb-object pattern while web_search is more of a noun phrase or object-verb construction. The inconsistency is minor and does not hinder understanding, but a more consistent pattern like search_web would improve clarity.

Tool Count3/5

Two tools is on the low end for a search-focused server. The pair covers the core search-and-extract workflow, but feels slightly thin compared to typical search APIs that offer multiple query types, filtering, or pagination. Still, the scope is focused enough that the count is not unreasonable.

Completeness4/5

The two tools form a complete loop: discover information via web_search, then read full pages via extract_url. Missing advanced search options and pagination details are notable gaps but not blocking for the primary use case, so the surface is mostly complete for a simple search assistant.