keyso-mcp

keyso_post_clustering_uid_build

Start clustering for a report by supplying its UID. This triggers the build process after report creation, generating cluster results.

Instructions

Кластеризация - запуск процесса Method: POST Path: /clustering//build Запуск процесса. Вместо UID в уре запроса, идентификатор полученный при создании.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "uid": "<uid>",
      "body": "<body>"
    },
    "name": "keyso_post_clustering_uid_build"
  }
}

Input Schema

Name	Required	Description
`uid`	Yes	in: path \| Идентификатор отчёта
`body`	Yes	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

B3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'start process' and repeats the HTTP method/path; it does not state whether the call is asynchronous, what the response looks like, or how to track the started process (e.g., via keyso_get_clustering_state_uid). This is a significant gap for a process-launching mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, but it repeats 'Запуск процесса' twice and contains a typo ('уре' instead of 'URL'). It is compact, yet the redundancy means not every sentence earns its place.

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?

Given no output schema, no annotations, and a required but undocumented body, the description is incomplete. A caller needs to know the expected response, whether the process runs asynchronously, and what to include in the body; only the UID's origin is addressed.

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 the baseline is 3. The description adds useful meaning for 'uid' by clarifying it should be the identifier from creation, but it says nothing about the required 'body' parameter, which is opaque and potentially critical for invoking the tool correctly.

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 concrete action ('запуск процесса' / start process) and resource (clustering), with the path '/clustering/<uid>/build' reinforcing that this is the build/launch step. It does not explicitly contrast itself with sibling tools like keyso_post_clustering or keyso_get_clustering_state_uid, but the verb and path make the operation identifiable.

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

Usage Guidelines3/5

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

The description gives a useful prerequisite: the UID must be the identifier obtained at creation, implying this tool is used after clustering creation. However, it does not name alternatives or say when not to use it, leaving the agent to infer the correct routing among the many clustering siblings.

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

Deploy Server