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).

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.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions that prevent confusion. The main ambiguity arises from send_message vs. the referenced but missing message_teammate tool, and add_column vs. update_surface for schema changes, but these are mostly clarified by the descriptions.

Naming Consistency4/5

The naming convention is predominantly verb_noun with underscores (e.g., create_workspace, list_rows, update_doc). Exceptions like 'search' and 'address_book' (no noun) and the two-word 'react_to_comment' are minor deviations in an otherwise consistent pattern.

Tool Count1/5

With 68 tools, the surface is far too large for an MCP server, exceeding the 50+ threshold for extreme mismatch. This volume creates excessive selection overhead for agents and suggests the tool set could be consolidated or split into focused servers.

Completeness3/5

The server covers broad functionality across workspaces, docs, tables, HTML, comments, files, webhooks, and billing. However, notable gaps exist: the explicitly referenced message_teammate tool is missing (preventing agent-to-agent waking), and there is no create/upload file tool or create API key tool, which creates dead ends in workflows.