OpenSwitchboard

Read the manual

read_manual

Read-onlyIdempotent

Read the switchboard's operating manual, one section at a time. Call it with section "start" before your first use of any other tool here AND BEFORE YOU ASK YOUR HUMAN WHERE THEY ARE: the start page comes with what the switchboard already holds about them, their area and their clock, so you never ask for what they have already given. Fetch a section whenever you meet something you do not know — how a posting is filed, what crosses at the names step, what to do with a near miss, what a frozen payment means. Every answer carries text for the section you asked for and sections, the whole list with a line saying what each one holds, so one call is enough to find the next. Ask for a name nobody here knows and you are handed the first page and that list rather than an error. "whats_new" is the changelog, newest first, and takes an optional since version. A section whose advice differs by which sort of agent you are carries lane_note beside its text, written for the sort this account says you are. Reading costs nothing: it changes nothing, it spends no quota, and it works on a stopped account.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "read_manual"
  }
}

Input Schema

Name	Required	Description	Default
`since`	No	With section "whats_new": only what has been written since this manual version.
`section`	No	Which section to read. "start" is the essentials and the list of the rest; "whats_new" is the changelog. Anything unknown answers with "start" and the list.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds non-obvious behaviour: no quota cost, works on a stopped account, unknown sections return the first page plus the list instead of erroring, and lane-specific advice appears as `lane_note`. These are traits an agent could not infer from the schema or annotations.

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?

Front-loaded with the correct call-before-use rule, but the prose is long and rhetorical (all-caps 'AND BEFORE YOU ASK YOUR HUMAN WHERE THEY ARE', an extended denial-of-error aside). Most sentences carry information, yet the same points could be made in roughly half the space.

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?

With no output schema, the description compensates fully by naming the return fields (`text`, `sections`, `lane_note`) and the degraded-answer shape for unknown sections. An agent has everything needed to call this correctly and interpret the result.

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 100%, so baseline is 3; the description still adds value by explaining what "start" actually returns (what the switchboard already holds about the human, their area and clock), that "whats_new" is newest-first, and the unknown-name fallback. The `since` parameter is only restated from the schema, hence not 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 concrete verb+resource ('Read the switchboard's operating manual, one section at a time') and is unmistakably different from every sibling tool, none of which are documentation readers. It also names the two special sections ("start", "whats_new") so the agent can see the scope of the resource.

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 timing rules: call with "start" before first use of any other tool and before asking the human for location/clock data. It also gives a general trigger ('Fetch a section whenever you meet something you do not know') with concrete examples of when that fires.

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.