Skip to main content
Glama

Scrape Google News

scrape_google_news
Read-only

Run a Google News search from a chosen country and return news results. Supports desktop, mobile, iOS, and Android emulation and multi-page results. Costs 5 credits (3 base + 2 sync surcharge); each page after the first adds 2.

Input Schema

NameRequiredDescriptionDefault
glNoISO 3166-1 alpha-2 code for the result geography, sent to Google as gl (e.g. "us"). Use list_countries to see supported codes per model.
hlNoOptional Google interface-language code, sent as hl (e.g. "de", "pt-br"). Defaults to the language derived from gl — set it when the geography's dominant language is not the one you want.
pagesNoNumber of result pages to fetch (1-10). Defaults to 1.
queryYesThe search query.
deviceNoDevice to emulate: desktop, mobile, ios (Safari on iPhone), or android (Chrome on Android). mobile is an alias for android. Defaults to desktop.desktop
countryNoISO 3166-1 alpha-2 country code to geo-target the request from (e.g. "US"). Use list_countries to see supported codes per model. Deprecated — use gl instead; country is kept for compatibility and must not disagree with gl.
includeNoOptional flag, off by default: html (the result page HTML). Leave unset for the leanest response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / include / description
      Previous value: -"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."New value: +"Optional flag, off by default: html (the result page HTML). Leave unset for the leanest response."
  2. Changed1 schema field changed
    • changedInput schema / properties / include / description
      Previous value: -"Optional flags to include heavier payload fields in the response. Leave unset for the leanest response."New value: +"Optional flags for heavier payload fields, each off by default: markdown (the answer rendered as markdown), html (the answer page HTML), rawResponse (the engine's unprocessed response payload). Leave unset for the leanest response."
  3. Changed4 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. \"US\"). Use list_countries to see supported codes per model."New value: +"ISO 3166-1 alpha-2 country code to geo-target the request from (e.g. \"US\"). Use list_countries to see supported codes per model. Deprecated — use gl instead; country is kept for compatibility and must not disagree with gl."
    • addedInput schema / properties / gl
      Added value: +{
      +  "description": "ISO 3166-1 alpha-2 code for the result geography, sent to Google as gl (e.g. \"us\"). Use list_countries to see supported codes per model.",
      +  "type": "string"
      +}
    • addedInput schema / properties / hl
      Added value: +{
      +  "description": "Optional Google interface-language code, sent as hl (e.g. \"de\", \"pt-br\"). Defaults to the language derived from gl — set it when the geography's dominant language is not the one you want.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "query",
      -  "country"
      -]New value: +[
      +  "query"
      +]
  4. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: a concrete credit cost model (5 credits = 3 base + 2 sync surcharge, +2 per extra page) and the fact that device emulation and multi-page fetching are supported. It does not describe the shape of the returned results, which matters given there is no output schema.

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?

Three compact sentences, front-loaded with what the tool does and followed by capability and cost. Every sentence carries information; the cost sentence is dense but earns its place since pricing affects whether the agent fetches extra pages.

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 7-parameter tool with a nested object and no output schema, the description covers the essentials an agent needs: scope, geo targeting, device emulation, paging and cost. The remaining gap is the shape of the returned news results, which the description does not characterize.

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%, including enum values, defaults, deprecated-parameter warnings and a pointer to list_countries, so the schema carries the parameter burden. The description only echoes the device options and page paging at a high level, adding little beyond it. Baseline 3 is appropriate.

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 — 'Run a Google News search from a chosen country and return news results' — which cleanly separates it from scrape_google and the AI-mode siblings. It stops short of naming any sibling explicitly, so an agent must infer the News-vs-general-search split from the phrase 'Google News'.

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 implied by the resource (news results, geo-targeted by country) and the cost note gives a reason to economize on pages. But there is no explicit when-to-use/when-not guidance and no mention of the sibling tools (scrape_google, scrape_google_ai_mode) that an agent would need to choose between.

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.