Skip to main content
Glama

search_work

Read-onlyIdempotent

Search Hub threads, projects, and wiki progress snippets to find open or blocked work without an external index; read-only results never change threads.

Instructions

Search local Hub work without an external index.

Returns mixed hits (thread, project, wiki) with quiet snippets. Read-only; does not create or change threads.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum hits to return (1–50); defaults to 25.
queryYesKeywords to find across Hub threads, projects, and local wiki progress snippets.
include_doneNoWhen true, also match done/dismissed threads; default false matches open and blocked only.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.22.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'read-only; does not create or change threads' largely restates what the agent already knows. The genuinely additive detail is that hits span threads, projects and wiki with 'quiet snippets', but with an output schema present that value is modest. No annotation contradiction.

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?

Two short sentences, front-loaded with purpose and scope, no filler. Minor redundancy in restating read-only behavior that annotations already cover.

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?

For a three-parameter read-only search with full schema coverage, rich annotations and an output schema explaining return values, nothing an agent needs in order to invoke it correctly 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 description coverage is 100%, with each of query, limit and include_done documented including defaults, ranges and the open/blocked-vs-done filtering semantics. The description adds no further parameter meaning, so the baseline 3 applies.

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 and resource ('Search local Hub work') and clarifies the scope ('without an external index') plus the result composition (mixed thread/project/wiki hits with snippets). It does not name or differentiate itself from siblings such as list_open_threads or list_projects, which is the only thing keeping it from a 5.

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?

Implies usage through the local-only, no-external-index framing, but never says when to choose this over listing tools or how to narrow a search. No explicit when-not conditions beyond the read-only note.

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