Skip to main content
Glama

search

Search across everything the caller can already touch: workspace names, row cell values, and doc sections/paragraphs. Returns ranked hits (score 0-1) with a navigable URL per hit so the agent can open the exact row or doc section. Access-gated; never returns hits from workspaces the caller can't open. Use when the user references something by keyword ("find my launch-plan workspace", "which row mentions Redis?"). Faster than listing workspaces and iterating.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesSearch query. Case-insensitive substring match.
kindNoNarrow to one surface. 'all' (default) searches workspace names + row cells + doc sections. 'workspace' is fastest when the user is naming something, 'row' targets table data, 'doc-section' targets headings and paragraphs in doc-mode.
limitNoMax hits to return (default 20, max 100).
offsetNoHits to skip for pagination (default 0).

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals that the tool is access-gated ('never returns hits from workspaces the caller can't open') and describes the return format (ranked hits with score 0-1 and navigable URLs). This is substantial, though it omits details like rate limits or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, each earning its place. It front-loads the core function, then covers return values, access restrictions, and usage context without redundancy or filler. This is efficient and well-structured.

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?

Given the tool's moderate complexity and the absence of an output schema, the description is remarkably complete. It explains what gets searched, the ranking and URL details, the access-gating behavior, and when to use it. An agent can successfully select and invoke this tool based solely on this description and the schema.

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?

The input schema already covers all four parameters with 100% description coverage, including defaults and enums. The tool description does not add meaningful parameter-level semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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?

The description clearly states what the tool does: it searches across workspace names, row cell values, and doc sections/paragraphs. It uses a specific verb ('Search') and enumerates the exact resources covered, distinguishing it from list-style sibling tools. The scope ('everything the caller can already touch') adds precision.

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?

The description provides clear usage context: 'Use when the user references something by keyword' with concrete examples. It also contrasts with an alternative approach ('Faster than listing workspaces and iterating'), though it does not name a specific sibling tool. This is better than no guidance but stops short of explicit exclusions.

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.