OpenSwitchboard

Add other words for a posting

refine_intent

Destructive

Give the switchboard your human's OTHER WORDS for something they have already put up, so it can find things worded differently. also_called is up to six short phrases for the same thing — the trade name, the part number, what everyone in that hobby says, "BPK", "die-spring mod" — and not_these is up to six short phrases they say it is NOT ("elastomer kit", "whole pedal set"), which makes close things count for less and hides nothing from them. Use their own words, gathered in ordinary talk: ask what else people call it and whether there is a near neighbour it keeps getting mistaken for. THIS CANNOT CHANGE WHAT THE THING IS — a different thing means taking it down and putting it up again, the same as a different heading. Plain words only: no price, no email address, no phone number, no link, and no wording aimed at an AI, or it comes back with the ordinary plain-words answer. The switchboard looks again by itself the moment this lands, so stay in the conversation and bring your human whoever comes forward. Say the say_note sentence as it stands, and never the id.

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": {
      "intent_id": "<intent_id>"
    },
    "name": "refine_intent"
  }
}

Input Schema

Name	Required	Description
`intent_id`	Yes
`not_these`	No	Short phrases your human says it is NOT. Up to six. Nothing is hidden from them by this; close things simply count for less.
`also_called`	No	Your human's other words for the same thing, in their words and in their own language. Up to six short phrases.
`identifiers`	No	The identifiers for the product or edition, as publish_intent describes them. Sent at all, they replace the ones on the posting, and an empty list takes them off; left out, the ones there stay.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 14, 2026

addedInput schema / properties / identifiers

Added value: +{
+  "description": "The identifiers for the product or edition, as publish_intent describes them. Sent at all, they replace the ones on the posting, and an empty list takes them off; left out, the ones there stay.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "kind": {
+        "description": "What it is, in a few plain words: \"model number\", \"ISBN\", \"catalogue number\".",
+        "maxLength": 40,
+        "minLength": 1,
+        "type": "string"
+      },
+      "value": {
+        "description": "The identifier as printed on the product.",
+        "maxLength": 60,
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "value"
+    ],
+    "type": "object"
+  },
+  "maxItems": 3,
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "intent_id",
-  "also_called"
-]New value: +[
+  "intent_id"
+]

First observedOct 2, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Beyond the annotations it discloses genuinely useful behavior: a content filter (no price, email, phone, link, or AI-directed wording, 'or it comes back with the ordinary plain-words answer') and automatic re-indexing on success. What it omits is the destructive surface flagged by destructiveHint=true — the fact that a supplied identifiers list replaces existing identifiers and an empty list removes them is only in the schema, not the description.

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?

Purpose is front-loaded in the first sentence, which is correct. However the run-together prose, heavy anthropomorphic framing, and the trailing instruction about a `say_note` sentence (a field never defined in the schema) add reading cost without proportional value.

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

Completeness3/5

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

For a mutating tool with 75% schema coverage and annotations present, the description covers purpose, filter constraints, and the identity boundary well. Gaps remain: the identifiers replacement/removal behavior is undisclosed in prose, no return value is described, and 'say_note' is referenced as if the agent should already know it despite there being no output schema.

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 75%, so a 3 is the baseline; the description earns a step up by explaining what the two phrase parameters mean semantically, giving concrete examples ('BPK', 'die-spring mod', 'elastomer kit'), and clarifying that not_these does not hide the posting, it only down-weights near matches. It never mentions the identifiers parameter, leaving that entirely to the schema.

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 opening sentence states a specific action on a specific resource — supplying alternative wording for something already posted so it matches differently-worded searches. It also draws the boundary against competing intents (changing the thing itself means withdrawing and republishing), so an agent can separate it from publish_intent/withdraw_intent. The metaphorical 'switchboard/human' vocabulary costs it the top score.

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?

It gives both a use case (something already put up, needing other words) and an explicit exclusion ('THIS CANNOT CHANGE WHAT THE THING IS — a different thing means taking it down and putting it up again'), plus how to source the data from the human. It falls short of 5 because it never names the sibling tools that do the excluded operations.

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

All OpenSwitchboard 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.