Skip to main content
Glama

Find files by name

search_files
Read-onlyIdempotent

Locate files by name substring recursively in everkeep to find notes, decisions, and project documents. Use grep_files for content searches.

Instructions

Find files by NAME substring, recursively. For content use grep_files.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
patternYes
excludePatternsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered structurally. The description adds two genuine behavioral traits not in the annotations: the search is recursive and matching is a case/substring match on the name. It says nothing about result limits, ordering, or what happens on no match.

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?

Two short sentences, zero filler, with the scope constraint front-loaded and the disambiguation trailing. Nothing could be removed without losing information.

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

Completeness2/5

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

For a 3-parameter tool with 0% schema description coverage and no output schema, the description is too terse: excludePatterns and path semantics are absent, as is any note on return shape or result limits. The annotations carry the safety profile, but the parameter documentation gap remains a real risk of misuse.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description only partially compensates, clarifying that 'pattern' is a name substring. It never explains 'path' (root of the recursion?) or 'excludePatterns' (what forms are accepted, whether globs), leaving two of three parameters with no documented meaning anywhere.

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?

States a specific verb and resource ('Find files') plus the matching scope ('by NAME substring, recursively'), and explicitly names the sibling it is not (grep_files for content). An agent can distinguish it from grep_files without opening either schema.

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?

'For content use grep_files' gives an explicit alternative and the condition that selects it, which is exactly the routing decision an agent faces here. It stops short of exclusions (e.g., versus list_directory or get_file_info), so it is clear but not exhaustive.

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