Skip to main content
Glama
Sign In
SerpApi MCP Server

SerpApi MCP Server

by serpapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

SerpApi search (dashboard)

search_dashboard
Read-only

Displays query results as an interactive dashboard with summary metrics, a source breakdown chart, and a click-to-expand results table; automatically uses engine-specific views when available.

Instructions

Interactive dashboard variant of search: returns summary metrics, a source breakdown chart, and a results table with a click-to-expand detail panel, all rendered in the conversation. Same params as search. Use for a richer visual overview of a query's results. Automatically selects an engine-specific dashboard when available (e.g. google_flights gets price intelligence charting).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_dashboard"
  }
}

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.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, open-world, non-idempotent), so the description's added value is the rendering behavior: it discloses that output is composed of three distinct rendered artifacts and that engine-specific dashboards are auto-selected (e.g. price intelligence for google_flights). It does not mention latency, token/size cost of the richer output, or fallback behavior when a dashboard 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?

Four tight sentences, front-loaded with the tool's identity and return shape, then the alternate-tool relation, then the engine-selection nuance. No filler or restatement of the title.

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?

With no output schema, the description usefully explains what the caller receives, and the input side is handled by cross-reference to `search`. Minor gaps remain around cost/size of the richer payload and behavior when no engine-specific dashboard exists, but nothing essential to invoking it correctly is missing.

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

Parameters4/5

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

The schema has a single free-form `params` object with 0% description coverage, so the description must carry the load — and 'Same params as `search`' is a meaningful delegation that tells the agent where to find the real contract. It still does not enumerate any parameter names or note whether dashboard-specific keys exist, so an agent must consult `search` before calling.

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 ('Interactive dashboard variant of `search`') and immediately enumerates the return composition: summary metrics, source breakdown chart, and results table with a detail panel. This is clearly distinguishable from the siblings `search` (plain results) and `search_table` (table only).

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 cue — 'Use for a richer visual overview of a query's results' — and anchors itself to `search` by inheriting its parameters. It does not explicitly state when NOT to use it (e.g. cost/latency tradeoffs vs. plain `search`), leaving the agent to infer the exclusion.

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