Skip to main content
Glama

Search flows

search_flows
Read-onlyIdempotent

Full-text search the signed-in user's saved Wavelength flows by title, node labels, and transcript. Returns matches with where they matched, a transcript snippet, and a link to open each. Query must be at least 2 characters.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of matches to return, 1 to 100. Defaults to 20.
queryYesThe search query, at least 2 characters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds genuine context beyond them: which fields are searched, what a result contains (match locations, transcript snippet, open link), and the minimum query length. No permissions or pagination behavior is described, which keeps it from a 5.

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?

Three tight sentences: purpose and searched fields first, then return shape, then the key constraint. Every sentence carries distinct information and nothing is restated redundantly.

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?

With no output schema, the description usefully enumerates the return shape (where matches occurred, a transcript snippet, an open link) and the query constraint. It stops short of describing result ordering, pagination, or how limit interacts with large result sets, so it is strong but not exhaustive.

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%, so both params and the 2-character minimum are already documented structurally. The description restates the query-length constraint but adds no syntax, formatting, or matching-behavior detail for query or limit, 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 (full-text search), resource (the user's saved flows), and searchable fields (title, node labels, transcript). It implicitly separates itself from plain listing tools, but never names the closest siblings like list_flows or query_flows, so an agent can't fully disambiguate without opening schemas.

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?

Usage is implied by 'full-text search... by title, node labels, and transcript' and the 'signed-in user's saved flows' scoping, but there is no explicit when-to-use guidance nor any statement of when to prefer list_flows or query_flows instead. Adequate but leaves routing to inference.

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.

Resources