Skip to main content
Glama
paulet4a-commits

webdatatools-rag-mcp

by paulet4a-commits
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

ai_web_search

Run a Google search or read specific URLs, fetch top organic results, and return clean Markdown/text for LLM, RAG, and agent context.

Instructions

AI Web Search runs a Google search, fetches the top organic results and returns clean Markdown per result — one call turns a question into LLM-ready context for agents, RAG and MCP. Billed to your own Apify account: ~$0.005 per result (Apify free-plan price, lower on paid plans).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlsNoURLs to read directly (skip search) — Enter specific page URLs to fetch and convert to Markdown, e.g. https://docs.apify.com/platform. When set, no Google search is performed at all — this becomes a pure URL-to-Markdown reader.
queryNoSearch query — Enter a single question or search phrase, e.g. what is web scraping. Ignored if "queries" or "urls" is also set. One SERP is fetched and the top organic results are read and returned as Markdown. Example: "what is web scraping".
queriesNoSearch queries (batch) — Enter multiple search queries to run in one call, e.g. best crm for startups. Overrides "query" when non-empty. Leave empty to use "query" instead. Example: ["best crm for startups"].
maxResultsNoMax results per query — Enter how many organic results to read per query, e.g. 3. Each result is one billed dataset row, so 3 results costs about 3x the per-result price.
countryCodeNoCountry code (gl) — Enter the 2-letter country code Google should localise results for, e.g. us, gb, de.us
languageCodeNoLanguage code (hl) — Enter the 2-letter interface language code, e.g. en, es, fr.en
outputFormatNoOutput format — Choose markdown (clean Markdown, best for LLMs), text (plain text) or both. Options: markdown = Markdown; text = Plain text; both = Both.markdown
maxCharsPerResultNoMax characters per result — Enter the maximum characters to keep per result page, e.g. 8000. Long pages are truncated (truncated:true) to keep the response inside your LLM's context window.
includeSnippetOnlyNoSnippet-only (cheap mode, no page fetch) — Turn this on to return only the SERP title/url/snippet for each result without fetching and reading the page — much faster and works even without page-fetch access, but markdown/text come back null.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does useful work: it discloses that billing hits the caller's own Apify account at ~$0.005 per result, and that output is Markdown per result. It omits auth/prerequisite details, rate limits, and failure modes, so it is strong but not complete.

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, no filler. The functional core (search → fetch → Markdown) is front-loaded, and the pricing detail follows as supporting context. Every clause earns its place.

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?

For a nine-parameter tool with no annotations and no output schema, the description conveys the return shape (clean Markdown per result) and the cost model, which are the key things an agent needs. It is nearly complete, missing only operational details like auth setup and rate-limit behavior.

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 nine parameters are already richly documented in the schema (including mode exclusivity and billing implications of maxResults). The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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?

States a concrete verb+resource chain: runs a Google search, fetches top organic results, returns clean Markdown per result. This clearly distinguishes it from siblings like website_to_markdown or article_extractor, which do not perform search. An agent can identify the tool's function without opening the schema.

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?

The description frames the use case (turning a question into LLM-ready context for agents, RAG, MCP) but never states when to prefer it over the overlapping siblings website_to_markdown or article_extractor, nor explicit exclusions. Usage mode selection (search vs direct URL read) is documented in the schema, not the description.

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