OpenSwitchboard

Post a list

publish_list

Destructive

FOR MANY THINGS AT ONCE: a collection, a stock list, a want list. CONVERT WHAT YOUR HUMAN HAS YOURSELF (an export file, a spreadsheet, a typed list, a photo of their shelves), keep only what each item needs, and post it here as one list. shared is what every item has in common: the side, the shelf, the place written in full with its reach, and the deal (sale, trade or free). Each item carries only a name in plain words, up to three identifiers, a few details such as condition, a quantity, and on a sale an asking price or open_to_offers (on a want, a private price_limit). No descriptions and no photos. Good items go up even where others do not: each one that did not comes back with its place in your list, the reason and the one thing to fix. Prices are read back once for the whole call, as a summary: say it to your human, and post again with the reference only if those are their figures. Up to 200 items a call; send more to the same list_id. To send an updated list, give its list_id with replace, in part of parts if it is long: unchanged items keep their introductions, and items no longer on it come down after the last part. Read the results to your human plainly, and never say an id aloud. read_manual("lists").

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": {
      "items": "<items>"
    },
    "name": "publish_list"
  }
}

Input Schema

Name	Required	Description
`part`	No
`items`	Yes
`parts`	No
`shared`	No	What every item shares. Needed for a new list; on a list already up, leave it out.
`list_id`	No	Leave out for a new list. Give it to add to a list already up, or with replace to send it again.
`replace`	No	With list_id: these items, with the other parts, are now the whole list.
`reference`	No	The `reference` the last answer about this same list handed you. Machinery: never say it.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations flag destructiveHint=true and openWorldHint=true; the description goes well beyond by disclosing partial success ('Good items go up even where others do not'), the per-item failure report shape, the 200-item cap, the price readback/confirm loop with `reference`, and that removed items come down after the last part. It also adds the 'never say an id aloud' output handling constraint that annotations cannot express.

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?

It is front-loaded with the core framing and every major sentence carries operational meaning (batching, partial failure, replace semantics, price confirmation). The stylized phrasing ('CONVERT WHAT YOUR HUMAN HAS YOURSELF') and some repetition about reading results back cost it a bit of crispness.

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?

With no output schema and a 7-param nested payload, the description supplies the missing return-behavior context: partial success, per-item reasons, and the price summary readback. Gaps remain around `category` format and `ttl_days`, which the schema names but does not elaborate.

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?

At 57% schema coverage the description must add value, and it does: it explains what `shared` means per field (side, place with reach, deal), what each item may carry, and the interplay of list_id/replace/part/parts/reference. It leaves `category` and `ttl_days` unmentioned, so it is not fully compensating for the coverage gap.

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 'FOR MANY THINGS AT ONCE: a collection, a stock list, a want list' states a specific verb (post) and resource (a multi-item list), and implicitly contrasts with the single-item publish_intent sibling. It does not name publish_intent directly, so an agent must infer the boundary from 'many things at once' rather than an explicit routing sentence.

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 clearly says when to use it: converting an export, spreadsheet, typed list or shelf photo into one list, and it covers the three operating modes (new list, append via list_id, replace in parts). It does not explicitly say when NOT to use it or name the sibling that handles single items.

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.