google-web-search

Web Search

get_v1

Get web search results, knowledge panel and related keywords Billing per call: 1 Credits.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`gl`	No		US
`hl`	No		en
`limit`	No
`query`	Yes	The search query. Supports plain keywords or full Google search syntax (Google Dorking). Common operators: `"exact phrase"`, `OR`, `-exclude`, `site:`, `inurl:`, `intitle:`, `intext:`, `filetype:`, `before:` / `after:` (`YYYY-MM-DD`), `related:`, numeric ranges (`10..50`). Example: ``` site:github.com intitle:awesome python -site:gist.github.com ```
`cursor`	No
`related_keywords`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedSep 2, 2026

addedInput schema / properties / query / description

Added value: +"The search query. Supports plain keywords or full Google search syntax (Google Dorking).\n\nCommon operators: `\"exact phrase\"`, `OR`, `-exclude`, `site:`, `inurl:`, `intitle:`, `intext:`, `filetype:`, `before:` / `after:` (`YYYY-MM-DD`), `related:`, numeric ranges (`10..50`).\n\n**Example:**\n\n```\nsite:github.com intitle:awesome python -site:gist.github.com\n```"

removedInput schema / properties / query / title
```
Removed value: -"Search Query"
```

Changed2 schema fields changedSep 2, 2026

addedInput schema / properties / gl

Added value: +{
+  "default": "US",
+  "title": "Country code",
+  "type": "string"
+}

addedInput schema / properties / hl

Added value: +{
+  "default": "en",
+  "title": "Language code",
+  "type": "string"
+}

First observedAug 19, 2026

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description must disclose behavior itself. It mentions per-call billing, which is useful, but it omits any details about pagination/cursor behavior, result format, rate limits, or side effects. It does not contradict any annotations, but it leaves most non-obvious behavior unexplained.

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?

The description is compact and front-loaded, with the core purpose in the first sentence and the cost note kept separate. It is minimal but not padded; the only flaw is missing punctuation and a lack of any structural breaks for readability.

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?

For a tool with six parameters, no output schema, and no annotations, this description is too sparse. An agent can call it with just a query, but it has no way to understand cursor pagination, limit semantics, or the shape of the returned results/knowledge panel.

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

Parameters1/5

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

Schema description coverage is only 17%, and the description does not compensate: it never mentions query, gl, hl, limit, cursor, or related_keywords beyond a generic reference to 'related keywords' in the output. The parameter meaning must be inferred entirely from schema titles/examples.

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?

The description identifies a specific action ('Get') and resource ('web search results'), plus additional outputs (knowledge panel, related keywords). It is immediately clear what the tool returns, though the name 'get_v1' is generic and no sibling differentiation is needed since there are no siblings.

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

Usage Guidelines2/5

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

The description provides no context about when to use this tool, what problem it solves, or situations where an alternative might be better. The only operational hint is the billing line. An agent would have to infer the intended use from the title alone.

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

All google-web-search tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.7/5.0

Disambiguation5/5

Only one tool exists, so there is no possibility of ambiguity or overlap with other tools.

Naming Consistency3/5

The single tool name 'get_v1' uses a verb_prefix style but includes a version suffix, which is slightly unconventional though not inconsistent since there are no other tools to compare.

Tool Count2/5

With only one tool, the server feels severely under-scoped for a service that presumably handles web search, knowledge panels, and related keywords, which typically require at least a few distinct endpoints.

Completeness2/5

The server claims to provide search results, knowledge panels, and related keywords, but exposes only a single endpoint with no obvious way to paginate, filter, or access additional details, leaving significant gaps.

Resources

Need Help?