Skip to main content
Glama

Search the list and the archive

find

Search open and archived tasks and documents by keywords, dates, tags, lists, sources, or agent status to locate past decisions; search inside one document for matching lines with context.

Instructions

Search the tasks — open and archived alike — and the documents: by words with query, by what a task is with the sifting fields (alone or narrowing a query), or by source alone to see whether something was filed from it already. A task found by what its page, description, steps or notes say comes with in and the line that says it, so a past decision often reads without read. With doc it searches inside that one document instead and hands back the matching lines with their numbers and the section each sits in.

Input Schema

NameRequiredDescriptionDefault
toNoIts date or deadline on this day or before
docNoLook inside this one document rather than across the tasks. Hands back the lines where every word of the query turns up, accents or not, with their numbers, the lines around them unless every one of those is blank, and the section each sits in. A line in `around` is cut at 200 characters; `read_doc` with `from` and `to` brings it whole
tagNoCarrying this tag, with or without the #. Any sifting field leaves the documents out of the answer
fromNoIts date or deadline on this day or after (2026-08-31)
listNoIn this list, named as `lists` names it
afterNoSkip this many tasks, to page on while `total` is higher than what came back. Documents are not paged: `docsTotal` says how many match, and a higher `limit` brings more
limitNoAt most 100, 20 by default
queryNoWords to look for, not a phrase: each word has to turn up in the same task or document (on the same line, with `doc`), in any order, accents or not; put a phrase in quotes when the order is the point. Not needed when sifting by the fields below
scopeNoDefaults to either: the open tasks and the archive together, which is where how something was solved before is found
aroundNoWith `doc`: how many lines to bring on each side of a hit, 1 by default, 0 for none, at most 10
folderNoOnly the documents in this folder and the folders below it, by its name, its whole path or its id. Documents whose title says the words come first either way, before those that only mention them
sourceNoAsk whether this exact source was proposed already
part_ofNoOnly the parts of this task, by its id
by_agentNoTrue for what an agent filed, false for what the person wrote
said_doneNoTrue for what an agent spoke for — said done, or said should not be done — and the person has not decided yet; false for what nobody spoke for
from_sourceNoOnly tasks whose `source` starts with this, however it is written: «sereno», «sereno#» and «sereno: » all bring everything read out of that one place
open_to_agentsNoTrue for the person's own tasks they opened to agents — yours to fill in and to say done — false for what they kept to themselves

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

No annotations exist, so the description carries the full load, and it discloses a lot beyond the schema: hits carry `in` plus the matching `line`, `around` lines are truncated at 200 characters (with `read_doc` to get them whole), documents are not paged while tasks are, and sifting fields silently exclude documents from results. It omits any error or permission behavior, but for a read-only search that is a modest gap.

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?

Purpose and modes are front-loaded in the first clause, and with 17 optional parameters the length is defensible — nearly every sentence carries selection or result-shape information. It is a single dense paragraph of heavily nested clauses, though, which makes it slower to scan than it needs to be.

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 17-parameter, all-optional search tool with no annotations and no output schema, the description covers mode selection, result shape (`in`, `line`, line numbers, section), truncation, and paging semantics (`after`/`total`, `docsTotal`). An agent could call it correctly from this text; only error and permission behavior are unaddressed.

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 prose adds cross-parameter meaning rather than restating fields: it explains that the sifting fields can narrow or replace a query, that `source` alone answers a yes/no provenance question, and that `doc` switches the whole result shape. That interaction guidance is not obvious from the schema alone.

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 specific verb and both resources — 'Search the tasks — open and archived alike — and the documents' — then distinguishes the three query modes and the `doc` scoped mode. It even names the sibling it can replace ('a past decision often reads without `read`'), so an agent can separate it from `read`, `docs`, and `read_doc` without opening a 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?

Gives explicit mode selection: words via `query`, sifting fields 'alone or narrowing a query', `source` alone for a provenance check, and `doc` to search inside one document. It also states `query` is 'Not needed when sifting by the fields below', which removes a real ambiguity. It stops short of stating when NOT to use this tool (e.g. full-document retrieval belongs to `read_doc`), leaving one inference.

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