Skip to main content
Glama

search_content

Search full file content for patterns, filtering out inactive #ifdef branches. Ideal for finding extern declarations, macros, includes, and global variables that are only present in compiled code.

Instructions

Find patterns in FULL file content — not limited to function bodies.

Searches ifdef-filtered file text — only code that actually compiles for the current build configuration. Inactive #ifdef branches are replaced with blank lines (preserving original line numbers).

Covers file-scope constructs that search_bodies cannot see: extern "C", type declarations in headers, #include, #define, global variables, namespace blocks. Also covers function bodies, but search_bodies is preferred for body-level patterns (per-function context, snippet highlights per match).

When to use search_content vs search_bodies vs search_code:

  • search_content — patterns anywhere in FILES (file scope + bodies): extern "C", InterruptIn, #define, type declarations.

  • search_bodies — patterns in function BODIES only: .attach(, callback(&, ISR registration patterns.

  • search_code — find symbols by NAME: interrupt handler, modem init.

project_only=True filters to files with is_project = 1 (project code, excluding vendor/SDK). Default False includes vendor SDK files.

Results are file-level (one entry per matching file) — use search_bodies for per-function granularity.

When files_fts is missing (legacy index), falls back to LIKE search on files.content — results include _fallback: "like" and no snippet highlighting. Run fw-context index to upgrade.

Read-only. No side effects. Requires the FTS5 index with file content.

Args: query: FTS5 search terms. 1-3 words. Bare multi-word queries are OR-joined (prefix-wildcarded). Prefer single-word queries. E.g. 'InterruptIn', 'extern C', '#define'. project_root: Project root. Auto-detected if omitted. limit: Maximum results (default 20, max 100). project_only: When True, filter to project code only (files with is_project = 1).

Returns: list of dicts, each with: file, language, mtime, _match_snippet (highlighted excerpt around the match).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results (default 20, max 100).
queryYesFTS5 search terms for full file content. 1-3 words. E.g. 'InterruptIn', 'extern C'. Bare multi-word = OR-joined.
project_onlyNoExclude vendor SDK code. When True, only application code. Default False.
project_rootNoProject root. Auto-detected if omitted.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations exist, so the description carries full burden. It discloses read-only nature, no side effects, ifdef-filtering preservation of line numbers, fallback to LIKE search when FTS5 index is unavailable, and result structure. This is comprehensive for a search tool with no annotations.

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

Conciseness4/5

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

The description is lengthy but well-structured with clear sections and bullet points. It front-loads the main purpose and organizes additional details logically. Minor redundancy (e.g., project_only explained twice) prevents a perfect score.

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 presence of 3 sibling tools, 4 parameters, and an output schema, the description covers all necessary aspects: input semantics, output format, use cases, fallback behavior, and index requirements. It is fully self-contained for an agent to select and invoke correctly.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. The description adds substantial value: explains query syntax (1-3 words, OR-joined, prefix-wildcarded), project_only filter semantics, limit range, and auto-detection of project_root. This goes well beyond the schema.

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 starts with a clear verb and resource: 'Find patterns in FULL file content'. It distinguishes itself from siblings by listing specific constructs it can find (extern "C", type declarations, #include, #define, global variables) that search_bodies cannot see. The purpose is unambiguous and directly addresses what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit 'When to use' section with comparative guidance for search_content, search_bodies, and search_code, including concrete pattern examples. Also explains the project_only flag and fallback behavior. This fully addresses when and when not to use the tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/turbyho/fw-context-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server