Open-End Response Analyser – coding of open-ended survey answers

Start a paid analysis run

open_end_start_run

Starts an AI analysis job that finds the themes in the responses. type='hierarchy' builds the L1-L3 category hierarchy and CHARGES CREDITS (1 per valid response, once per project); type='categorization' assigns every response to the hierarchy (no extra charge). Call only after the user agreed to the price and model from open_end_estimate_analysis; pass that model as expected_model and the agreed price as max_credits. Returns a run id immediately; poll it with open_end_get_run. Do not start a second run while one is active. Requires OAuth or an API key with analysis:run.

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": {
      "project_id": "<project_id>",
      "type": "<type>",
      "expected_model": "<expected_model>"
    },
    "name": "open_end_start_run"
  }
}

Input Schema

Name	Required	Description
`type`	Yes
`project_id`	Yes
`max_credits`	No	Upper price limit the user agreed to.
`hierarchy_id`	No	For categorization; defaults to the newest hierarchy.
`expected_model`	Yes	The model from open_end_estimate_analysis.
`idempotency_key`	No	Optional retry key (e.g. a UUID). Repeating the call with the same key and arguments returns the original result instead of writing again. Without it, identical calls within about 10 minutes are deduplicated.
`confidence_threshold`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false; the description goes well beyond that by disclosing the credit-charging model (1 credit per valid response, once per project), which mode is free, that the call is asynchronous and returns a run id immediately, and the required auth scope (analysis:run). The concurrency restriction adds operational context not present in any structured field.

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?

Five sentences, each carrying distinct load: purpose, mode/cost split, precondition, return-and-poll behavior, concurrency rule, auth. The cost information — the highest-stakes fact — is front-loaded in the first two sentences with capitalization for emphasis.

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 7-parameter mutating, credit-charging async tool with no output schema, the description covers cost, auth, sequencing, concurrency, and return shape (a run id). The only meaningful gap is confidence_threshold, which is unexplained in both the description and schema, and no guidance on when to supply idempotency_key beyond the schema note.

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?

Schema coverage is 57%, and the description compensates by explaining the semantics of the most consequential parameters: the two type values, expected_model as "the model from open_end_estimate_analysis", and max_credits as the agreed price ceiling. It adds no meaning for confidence_threshold or hierarchy_id, which remain documented only in the schema, keeping this short of a 5.

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?

Opens with a specific verb and resource ("Starts an AI analysis job that finds the themes in the responses") and then distinguishes the two modes by name, including what each produces (L1-L3 hierarchy vs. assigning responses to the hierarchy). An agent can tell this apart from open_end_estimate_analysis and open_end_get_run without opening any schema.

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

Usage Guidelines5/5

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

Explicit preconditions ("Call only after the user agreed to the price and model from open_end_estimate_analysis"), explicit routing of the follow-up step ("poll it with open_end_get_run"), and an explicit prohibition ("Do not start a second run while one is active"). This is the when/when-not/alternatives pattern at full strength.

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

All Open-End Response Analyser – coding of open-ended survey answers tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?