Close Knit

Rate answer

rate_answer

Idempotent

Rate a Close Knit answer by its callId (none: the last answer): rating 1-5, what was good, what was bad or missing, the fix you would want. Use it for the last answer in a conversation; earlier ones go in the next call's rate_previous. It describes the answer, never the user. Stored for 90 days with the call's intent summary, tool, client name and the conversation's one-way tag, contact details and full postcodes removed, no IP address or user agent.

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": {
      "rating": "<rating>"
    },
    "name": "rate_answer"
  }
}

Input Schema

Name	Required	Description
`bad`	No	[input value] What was wrong, missing or confusing.
`fix`	No	[input value] The change to the tool or its answer you would want.
`good`	No	[input value] What was useful in the answer.
`rating`	Yes	[input value] 1 = useless or wrong, 3 = usable with gaps, 5 = exactly what was needed.
`call_id`	No	[id] The callId of the answer you are rating; leave it out when answers carry none.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 5, 2026

changedInput schema / properties / bad / description

Previous value: -"What was wrong, missing or confusing."New value: +"[input value] What was wrong, missing or confusing."

changedInput schema / properties / call_id / description

Previous value: -"The callId of the answer you are rating; leave it out when answers carry none."New value: +"[id] The callId of the answer you are rating; leave it out when answers carry none."

changedInput schema / properties / fix / description

Previous value: -"The change you would want."New value: +"[input value] The change to the tool or its answer you would want."

changedInput schema / properties / good / description

Previous value: -"What was useful."New value: +"[input value] What was useful in the answer."

changedInput schema / properties / rating / description

Previous value: -"1 = useless or wrong, 3 = usable with gaps, 5 = exactly what was needed."New value: +"[input value] 1 = useless or wrong, 3 = usable with gaps, 5 = exactly what was needed."

Changed5 schema fields changedOct 30, 2026

addedInput schema / properties / call_id / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / call_id / default
```
Added value: +null
```

changedInput schema / properties / call_id / description

Previous value: -"The callId of the answer you are rating."New value: +"The callId of the answer you are rating; leave it out when answers carry none."

removedInput schema / properties / call_id / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "call_id",
-  "rating"
-]New value: +[
+  "rating"
+]

AddedOct 27, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing exactly what is persisted (intent summary, tool, client name, one-way tag), the 90-day retention window, and the redactions applied (contact details, full postcodes, no IP or user agent). It also adds a content constraint absent from any structured field: "It describes the answer, never the user," which directly shapes how an agent should write the free-text fields.

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?

Front-loaded with verb, identifier and the fields being supplied, then usage rule, then content constraint, then storage disclosure — a sensible ordering. The final privacy sentence is dense and packs several facts into one clause chain, so it is information-dense rather than padded, but it could be split for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers what the tool does, when to use it, what to write in each field, and the full data-handling story, while an output schema already exists so return values need not be described. Nothing an agent needs in order to call this 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?

With schema coverage at 100% the baseline is 3, and the description earns an increment by clarifying that call_id may be omitted and that omitting it targets the last answer ('none: the last answer'), a defaulting behavior the schema only hints at. Repeating the 1-5 scale and the good/bad/fix field meanings adds little beyond the schema descriptions, but the call_id default is genuine added meaning.

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?

States a specific verb and resource ("Rate a Close Knit answer") and then enumerates exactly what a rating consists of: a 1-5 score, what was good, what was bad or missing, and the fix wanted. It does not, however, differentiate itself from the sibling send_feedback, which an agent could reasonably confuse with this tool.

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 concrete usage rule: "Use it for the last answer in a conversation; earlier ones go in the next call's rate_previous," which cleanly splits the last-answer case from the retrospective case. The gap is that it never routes the agent away from send_feedback or explains how the two feedback mechanisms relate.

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

All Close Knit 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.