Skip to main content
Glama

history_search

Read-only

Find quotes in a Word document's undo log, edit requests, and nearby paragraph text, returning exact or folded hits with offsets and match levels.

Instructions

Find a quote in the undo log: in the requests, and in the text of every paragraph before and after each write. Exact unless match_level folds it; then every hit, with its offsets and the level it matched at.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
docNoPath to the .docx.
limitNo
queryYesText to find.
storeNoA store folder (see history.orphans) to read instead of the document's own.
ignore_caseNo
match_levelNoFold the search as `find` does: `default` ignores case, accents and punctuation (symbols such as `$` still count), `loose` drops symbols too; `exact` keeps the flags. When passed, Word's Find codes in `query` are read as their characters, every hit in a text is returned (not only the first, `exact` included), each with `start` and `end` (its offsets in that text: the request's JSON or the paragraph before or after the write, as `in` names it; not offsets into the cut `text`), `match_level` (the strictest level it meets) and `text` cut around it, and the reply gains `matches_by_level`, adding up to `total`. Without it, the first hit per text, with no `start`, `end` or level. Not with `ignore_case` or `ignore_accents` false at a folded level.
ignore_accentsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries most of the behavioral load and does surface real traits: exact-by-default matching, how match_level folds results, and the returned offsets/level structure. It omits things like ordering or performance caveats but adds genuinely useful behavior beyond the annotation.

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?

Dense but front-loaded, with the purpose stated first and the matching/return behavior appended. It is appropriately short for a search tool, though the heavy backtick and clause structure may cost readability.

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

Completeness3/5

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

With 7 params, no output schema, and 57% coverage, the description should do more. It sketches the return shape (offsets, level, matches_by_level) but leaves the interaction of ignore_case/ignore_accents with folded levels only partially explained, so an agent still has blind spots.

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 a middling 57%. The description reinforces what match_level does to the result set, but that same detail already lives in the schema's rich match_level description, and it adds nothing for ignore_case, ignore_accents, limit, store, or doc. Marginal added value over 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?

States a specific verb+resource, 'Find a quote in the undo log,' and narrows the scope to the requests plus the paragraph text before/after each write. This clearly tells an agent it searches history rather than the live document, though it never names the sibling (e.g. find) it should be chosen over.

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

Usage Guidelines2/5

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

The description explains matching behavior but gives no when-to-use or when-not guidance and does not mention alternatives such as find, locate, or history_list. An agent must infer from the name alone that this is the history-search tool rather than the document-search tool.

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