Skip to main content
Glama
Sign In
LLMScribe

LLMScribe

by AMRITO-KUNDU
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search

Locate case-insensitive text matches across local project file names and file contents, returning ordered results while skipping binary and oversized files.

Instructions

Substring search over file names and file contents.

Results are ordered by path then line number and limited to 1,000 matches. Binary and oversized files are skipped. This is plain text matching, not semantic search.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoLocal project directory. Defaults to the server's working directory.
queryYesText to find (case-insensitive substring) in file paths and file contents.
formatNoOutput format: 'markdown' (default) or 'json' (structured envelope).markdown

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: result ordering (path then line number), a hard 1,000-match cap, skipping of binary and oversized files, and plain-text (non-semantic) matching. It leaves open important questions such as whether truncation at 1,000 is signaled to the caller, whether ignore rules (e.g. .gitignore) are honored, and whether recursion is unbounded.

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 short sentences, front-loaded with what the tool does, then result ordering and limits, then the plain-text caveat. No filler or redundancy; each sentence contributes a distinct fact.

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?

For a read-only search tool with a full schema and an output schema (so return shape need not be explained), the definition covers the essentials: matching semantics, ordering, result cap, and file-type skips. The main residual gap is behavior at the match cap and ignore-rule handling, which matter for an agent interpreting results.

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 all three parameters (path, query, format) are already documented in the schema, including the case-insensitive substring semantics and format enum values. The description adds no parameter-level meaning beyond that, so the baseline 3 is appropriate.

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 ('Substring search over file names and file contents') with explicit scope, and adds a negative definition ('plain text matching, not semantic search') that rules out a whole class of alternatives. It stops short of naming the sibling tools (read/read_many) that an agent would actually weigh it against, so it is clear but not sibling-differentiated.

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?

The 'not semantic search' clause implicitly tells the agent when this tool fits (exact text lookup) and when it doesn't (conceptual queries), which is useful implied guidance. However there is no explicit statement of when to prefer this over read/read_many or project_map, and no prerequisites or exclusions beyond the semantic-search note.

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

Deploy Server

Other Tools