Skip to main content
Glama
Sign In
SerpApi MCP Server

SerpApi MCP Server

by serpapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

SerpApi search (table)

search_table
Read-only

Returns organic search results as a sortable, searchable table in the conversation, enabling visual browsing instead of reading raw JSON.

Instructions

Interactive UI variant of search: returns organic results as a sortable, searchable table rendered in the conversation. Same params as search. Use when the host supports MCP Apps and the user wants to browse results visually rather than read JSON.

Input Schema

NameRequiredDescriptionDefault
paramsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.1.0
    • removedInput schema / properties / params / additionalProperties
      Removed value: -true
    • addedInput schema / properties / params / anyOf
      Added value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / params / type
      Removed value: -"object"
  2. First observedv1.0.3

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, open-world, non-destructive and non-idempotent, so the description only needs to add output/rendering behavior — which it does by disclosing that results are rendered as an interactive table rather than returned as raw JSON. That is meaningful context, especially since no output schema exists, though it says nothing about failure modes or fallback when rendering is unavailable.

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 tightly written sentences: identity and output format first, then the selection condition. Nothing is redundant and no sentence is filler.

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 thin UI-variant wrapper with zero-typed params, the description supplies what an agent most needs: what comes back, when to pick it, and where the parameter documentation lives. Minor gaps are the lack of any fallback guidance if the host cannot render the table.

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 coverage is 0% and the single `params` property is an untyped anyOf object with additionalProperties true, so the schema conveys nothing. The description partially compensates by pointing to `search` for parameter semantics ('Same params as `search`'), but an agent must load the sibling tool's definition to learn anything concrete.

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 specific verb and resource ('returns organic results') plus the distinctive output form ('sortable, searchable table rendered in the conversation'), and explicitly frames itself as a variant of `search`, so an agent can distinguish it from the JSON sibling without opening either schema.

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?

Gives a clear selection rule: use when the host supports MCP Apps and the user wants to browse visually rather than read JSON, which implicitly names `search` as the alternative. It stops short of explicit exclusionary guidance (e.g. what to do when MCP Apps is unsupported) and never mentions `search_dashboard` as a competing option.

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