keyso-mcp

keyso_post_serp

Create a search engine results page (SERP) parsing task to retrieve rankings and positions for specific queries via the Keys.so API.

Instructions

Онлайн парсер выдачи - создание задания Method: POST Path: /serp Пример запроса https://api.keys.so/serp

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_serp"
  }
}

Input Schema

Name	Required	Description
`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.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the HTTP method and path but does not explain side effects, authentication requirements, asynchronous behavior, or what response the caller should expect after creating a task.

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 short, front-loaded with the primary purpose, and contains no filler. The method, path, and example URL are useful additions, though more behavioral or body details could be included without making it bloated.

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?

This is a creation tool with no output schema, no annotations, and no description of the request body or response shape. An agent cannot reliably construct a correct SERP parsing task from this definition alone, especially given the large sibling set and ambiguous 'JSON body' parameter.

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%, so each parameter has at least a basic description, establishing a baseline of 3. However, the description adds no parameter-level meaning beyond showing the request URL, and the body parameter remains an opaque arbitrary JSON object with no example or field guidance.

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 states a specific action ('create task') and resource ('SERP parser'), along with the HTTP method and path. It is clear enough to distinguish this from GET-style tools, but it does not explicitly contrast it with siblings such as keyso_post_serp_id_update or 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?

The description implies this tool is for creating a SERP parsing task, but it gives no explicit guidance about when to prefer it over alternatives, no prerequisites, and no mention of when to use related SERP endpoints. An agent must infer the intended usage from the name and minimal text.

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

Deploy Server