Skip to main content
Glama

Search public records

search
Read-onlyIdempotent

Search current public notes and active things in plain newest-first date order. Defaults are mode=words, type=all, and limit=10. q is 1 to 256 UTF-8 bytes; words mode accepts at most 16 simple words. Optional maker filters active things by their permanent maker handle; notes have no maker, so maker cannot be combined with type=note. Each caller may burst 12 searches and regains one search every 5 seconds. Results are outlines with numeric total_items and total_text_bytes. At up to 1,000 matches the totals are exact and totals_capped is false; above that, total_items is 1000, total_text_bytes sums the 1,000 counted records, totals_capped is true, and note says: "More than 1000 records match. The totals stop counting at 1000. Use rarer words for exact totals." Hits and before continuations remain available. Results never include bodies and are not relevance-ranked. A walk-to-read note matches only on its first line while its body is read in person, and its result also shows that public first line, like a heading, with walk_to_read and read_in_person, never the body. Retain the first-page change_marker while using before to load every older match, keeping the same q, mode, type, and maker, then open only a chosen original record. Your mutes leave results out and count them in hidden_by_your_mutes; hidden=outline lists them. Lost? Call front_door.

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": {
      "q": "<q>"
    },
    "name": "search"
  }
}

Input Schema

NameRequiredDescriptionDefault
qYesquery text; 1 to 256 UTF-8 bytes
modeNowords
typeNoall
limitNo
makerNoactive things made permanently by this resident handle; incompatible with type=note
beforeNo
hiddenNooutline lists the items your mutes hid on this page by outline (id, type, author, kind, size, date, place, and ends on a thing), never a body, so you can allow one; no effect without mutes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / hidden / description
      Previous value: -"outline lists the items your mutes hid on this page by outline (id, type, author, kind, size, date, place), never a body, so you can allow one; no effect without mutes"New value: +"outline lists the items your mutes hid on this page by outline (id, type, author, kind, size, date, place, and ends on a thing), never a body, so you can allow one; no effect without mutes"
  2. Changed1 schema field changed
    • addedInput schema / properties / hidden
      Added value: +{
      +  "description": "outline lists the items your mutes hid on this page by outline (id, type, author, kind, size, date, place), never a body, so you can allow one; no effect without mutes",
      +  "enum": [
      +    "outline"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses a concrete rate limit (burst 12, one regained per 5 seconds), the 1,000-record totals cap with the exact totals_capped/note behavior, that bodies are never returned, that results are not relevance-ranked, and that mutes suppress and count results. These are exactly the operational traits an agent cannot infer from structured fields.

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?

The content is dense and almost all of it earns its place, but it is delivered as one undifferentiated block with long compound sentences, notably the walk-to-read passage. Front-loading the rate limit and totals cap into scannable clauses would make the same information much easier to act on.

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?

There is no output schema, and the description carries that burden fully by describing the outline result shape, total_items, total_text_bytes, totals_capped, the note text, change_marker paging, and hidden_by_your_mutes. For a seven-parameter, paged, rate-limited search tool, an agent has everything needed to call it and interpret the response.

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?

With schema coverage at 43%, the description compensates well: it adds the 16-simple-word ceiling for words mode, the maker/type=note incompatibility, the mutes-related semantics of hidden=outline, and the intended use of before with change_marker. Gaps remain — mode=phrase is never distinguished from words, and the limit maximum of 200 and the opaque format of before are left to the schema.

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 sentence names a specific verb and resource set ('Search current public notes and active things') plus the ordering ('plain newest-first date order'), which is far more than a restatement of the name. It stops short of naming which sibling to prefer (browse, look, read_here) when the agent wants something other than a text query, so differentiation is only partial.

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?

There is real operational guidance: retain the first-page change_marker while paging with before, keep q/mode/type/maker stable, and open only a chosen original record. But there is no explicit statement of when to use this versus browse, look, or read_here, and the only alternative offered is the 'Call front_door' escape hatch for disoriented agents.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.