Skip to main content
Glama
Sign In

SuperBooks

by io.superbooks
OverviewDiscussionsAdmin

Search Tools

search_tools
Read-onlyIdempotent

Find the SuperBooks bookkeeping operations this connection can use (transactions, invoices, customers, reports, documents, inbox, tags, time tracking), as typed external_ TypeScript declarations for execute_typescript. Call it first for any question about the user's business finances. Optionally filter with { query }: a word or substring of the tool id and description ('invoice'), several tool ids separated by spaces, or a plain question in the user's words ('who owes me money'), which returns the few tools that answer it. When the matches are too many to declare at once it returns an index of ids and summaries; query the ids you need to get their declarations.

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

Input Schema

NameRequiredDescriptionDefault
queryNoA word or substring of the tool id and description, several tool ids separated by spaces, or a plain question in the user's words. Omit to list every tool this credential can reach.

Output Schema

NameRequiredDescriptionDefault
indexNoSet when the matching declarations were too long to send at once: says the tools carry summaries only and how to get their declarations.
toolsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Case-insensitive substring filter over the tool id and description, or several tool ids separated by spaces. Omit to list every tool this credential can reach."New value: +"A word or substring of the tool id and description, several tool ids separated by spaces, or a plain question in the user's words. Omit to list every tool this credential can reach."
  2. Changed5 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"Case-insensitive substring filter over the tool id and description. Omit to list every tool this credential can reach."New value: +"Case-insensitive substring filter over the tool id and description, or several tool ids separated by spaces. Omit to list every tool this credential can reach."
    • addedOutput schema / properties / index
      Added value: +{
+  "description": "Set when the matching declarations were too long to send at once: says the tools carry summaries only and how to get their declarations.",
+  "type": "string"
+}
    • changedOutput schema / properties / tools / items / properties / declaration / description
      Previous value: -"The typed TypeScript declaration for external_<name>, JSDoc (title, scope tag, description) included."New value: +"The typed TypeScript declaration for external_<name>, JSDoc (title, scope tag, description) included. Left out when the answer is an index."
    • addedOutput schema / properties / tools / items / properties / summary
      Added value: +{
+  "description": "The tool's title and scope tag, sent instead of the declaration when the answer is an index.",
+  "type": "string"
+}
    • changedOutput schema / properties / tools / items / required
      Previous value: -[
-  "id",
-  "external_name",
-  "declaration"
-]New value: +[
+  "id",
+  "external_name"
+]
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still discloses the two-tier return behavior: full declarations when matches are few, an index of ids and summaries when they are many. That is real behavioral context an agent needs to plan a follow-up call. It stops short of saying anything about how results are ranked or how large the index gets.

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?

Four sentences, front-loaded with purpose before usage and parameter detail, so an agent gets the essential routing information first. The only waste is the middle sentence, which duplicates the `query` description already present in the schema.

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?

Covers purpose, when to call, parameter forms, and the fallback retrieval path, while annotations carry safety and an output schema carries the return shape. Nothing an agent needs in order to call this correctly and follow up on an index result is missing.

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

Parameters3/5

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

Schema coverage is 100% and the single optional parameter is fully described in the schema, so the baseline is 3. The description's examples ('invoice', space-separated ids, 'who owes me money') largely restate the schema text for `query` rather than adding new meaning, though the omission-to-list-everything case is made a bit more concrete.

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 a specific verb and resource ('Find the SuperBooks bookkeeping operations this connection can use'), enumerates the domains covered, and pins the return type ('typed external_<id> TypeScript declarations for execute_typescript'). That return-type clause cleanly separates it from the execute_typescript sibling: this one discovers, that one runs.

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?

Gives an explicit first-call rule ('Call it first for any question about the user's business finances') rather than leaving usage to inference. It also handles the follow-on case: when too many matches come back, query the specific ids to get declarations.

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

All SuperBooks 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