Skip to main content
Glama

search_content

Search entire file contents for code patterns, from preprocessor directives to type declarations, excluding inactive #ifdef branches to return only 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
imageNoSysbuild image name within the variant (multi-project). Omit for all images of the variant.
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.
variantNoBuild variant name (multi-project). Omit to use default_variant or fail-closed. Use '*' for all variants.
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?

With no annotations, the description carries the full transparency burden and delivers: it explains ifdef-filtered search (inactive branches replaced with blank lines), fallback behavior when FTS5 index is missing, file-level results, and explicitly states 'Read-only. No side effects.' This is exceptionally transparent.

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?

Although lengthy, the description is tightly structured with headings and bullet-like explanations. Every section (ifdef behavior, sibling comparisons, fallback, return format) adds necessary context for a nuanced search tool; the opening line is immediately informative.

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?

The tool's complexity (ifdef filtering, fallback, file-level vs body-level granularity) is fully addressed, and the output schema is described. The only minor gap is no mention of image/variant parameters, but the schema documents them clearly.

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?

The input schema already provides 100% coverage, but the description adds semantic nuance for query: 'Bare multi-word queries are OR-joined (prefix-wildcarded). Prefer single-word queries.' It also clarifies project_only semantics with the is_project=1 detail. Parameters like image and variant are left to the schema, but their descriptions are sufficient.

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 first line states 'Find patterns in FULL file content — not limited to function bodies,' immediately establishing the tool's scope and distinguishing it from sibling tools like search_bodies. The description also lists specific file-scope constructs it covers (e.g., extern "C", #include, #define), making the purpose concrete.

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?

The description includes an explicit 'When to use' section contrasting search_content, search_bodies, and search_code with example patterns for each. It also notes that search_bodies is preferred for body-level patterns, providing clear conditional guidance.

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