Push Drop Stick: force-free dog training

Read the Handbook

read_handbook

Read-onlyIdempotent

Read the Handbook. id = an entry id from search_handbook (e.g. "threshold", "geartoavoid", "faqtreats") → the whole entry as markdown, with its canonical url and the entries it links to. id = a section slug (e.g. "fear-emotion", "gear", "faq") → the section's introduction and its entries. No id → the table of contents: every section and entry with urls.

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_handbook"
  }
}

Input Schema

Name	Required	Description	Default
`id`	No	An entry id or title, or a section slug. Omit for the table of contents.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety bar is low; the description goes further by disclosing the exact return shape for all three modes (markdown body, canonical url, outbound links, section intro, TOC with urls). It leaves error behavior for an invalid id unstated, which is the only meaningful behavioral gap.

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?

A single dense paragraph in three parallel 'X → Y' clauses, front-loaded with the entry case. No filler sentences and each clause carries distinct information.

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 one-parameter read tool with no output schema, the description covers input semantics and return shape for every mode, which is what an agent needs to call it correctly. Only the failure mode for a bad or ambiguous id is absent.

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 the baseline is 3, but the description adds real meaning beyond the schema by giving concrete example values ('threshold', 'geartoavoid', 'fear-emotion', 'gear') that show the two distinct id namespaces and by explaining what omitting the parameter yields.

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?

States the specific verb and resource ('Read the Handbook') and then immediately decomposes the tool into its three concrete modes keyed on `id`: entry lookup returning markdown plus canonical url and linked entries, section lookup returning the intro plus its entries, and no-`id` returning the full table of contents. An agent can distinguish this from search_handbook without opening either schema.

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?

The description routes each invocation mode clearly by tying entry ids back to search_handbook ('an entry id from search_handbook'), which implies the search-then-read workflow. It does not explicitly state exclusions or what to do when an id is unknown, so it stops short of full when/when-not guidance.

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

All Push Drop Stick: force-free dog training 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?