keyso-mcp

keyso_post_tools_history_serp

Retrieve historical Google search results for a keyword to analyze ranking changes and SERP volatility.

Instructions

История выдачи SERP по запросу Method: POST Path: /tools/history-serp Пример запроса https://api.keys.so/tools/history-serp?base=gru

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": "keyso_post_tools_history_serp"
  }
}

Input Schema

Name	Required	Description
`base`	No	in: query
`body`	No	JSON body
`token`	No	API token override (fallback: KEYSO_TOKEN env)
`base_url`	No	Override API base URL

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 20, 2026

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are present, so the description carries the full behavioral disclosure burden. It implies a read operation via the word 'history', but it does not state what the response contains, whether it is synchronous, whether results are paginated, or what authentication or rate limits apply.

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: a one-line purpose plus the endpoint and an example. It is front-loaded and contains no filler, though the missing content is captured in other dimensions.

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 POST endpoint with four parameters, no annotations, and no output schema, this description is under-specified. An agent cannot determine whether base is required, what the JSON body should hold, or what the return structure looks like, making correct invocation largely guesswork.

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 100%, giving a baseline even with no added parameter descriptions. However, the schema property descriptions are mostly transport metadata ('in: query', 'JSON body'), and the tool description only adds an example request with base=gru without explaining what base means or what the body should contain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool returns SERP history for a query ('История выдачи SERP по запросу') and gives the endpoint path /tools/history-serp. It is identifiable as a read-oriented endpoint, but it doesn't explicitly define what 'base' represents or distinguish it from the many SERP-related siblings such as keyso_get_serp, keyso_post_serp, and keyso_get_serp_id.

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?

There is no guidance on when to use this tool versus the numerous alternatives. The only usage hint is a bare example URL with base=gru; no prerequisites, required parameters, or exclusion criteria are provided.

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

Deploy Server