Skip to main content
Glama
Sign In

Switchbooks

by ai.switchbooks
OverviewDiscussionsAdmin

Review Client Requests

manage_requests
Read-onlyIdempotent

Read recent requests to the active company's owner: questions, transactions to clarify and missing files, with answers and uploaded file names. It does not create requests or send email on this connection. Set action to one of: list, link.

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": "manage_requests"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNo
asksNo
noteNo
refsNo
filesNo
actionNo
offsetNo
companyNoCompany for this call only: its ID, exact name, or a unique part of the name. Leave out to use the active company.
confirmNo
newNameNo
questionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare the tool as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful scope boundaries around not creating requests or sending email, but it leaves the 'link' action and the role of confirm/newName unexplained.

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?

The description is short and front-loads the read/review purpose. Its sentences are mostly useful, though the action sentence is incomplete and could better explain how 'list' and 'link' differ.

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

Completeness2/5

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

For an 11-parameter tool with no output schema and very low schema description coverage, the description is not complete enough. It gives a good high-level purpose but omits too much about parameter behavior and the 'link' action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 11 parameters and only 9% schema description coverage, the description should explain most parameters, but it only clarifies the action enum values. Parameters such as to, asks, note, refs, files, offset, confirm, newName, and questions remain undocumented in both the schema and the description.

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 description gives a specific verb and resource: reading recent client requests, including questions, transactions to clarify, missing files, answers, and uploaded file names. It also excludes creating requests and sending email, which sharpens scope, though it does not explicitly differentiate itself from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a negative usage boundary by saying it does not create requests or send email, which helps avoid misuse. However, it does not explain when to use 'list' versus 'link', nor does it name alternatives among sibling tools.

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

All Switchbooks toolsInspect
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