Skip to main content
Glama

search_content

Find which files mention a topic anywhere in their full content, including inactive #ifdef branches and file-scope comments. Returns file-level results with match lines and highlighted snippets.

Instructions

Find patterns in FULL file content — the whole file, not only the text that belongs to a definition.

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). A pattern that lives only in a dead branch therefore gives no result, and that empty answer is the correct one: the code does not compile.

Covers the text that belongs to no definition, which is what search_bodies cannot see: #include, #define, #ifdef, extern "C", and a comment or declaration at file scope. It covers the text of definitions too. To find a symbol by NAME (modem init, interrupt handler), use search_code.

Not a fallback of search_bodies — its complement. The two answer different questions and reach different text:

  • search_bodies answers WHICH DEFINITION holds the pattern, and takes the query literally (no wildcard, space = AND).

  • search_content answers WHICH FILES the topic touches, and widens the query: every term gets a trailing * and the terms are OR-joined. The wider query reaches text the literal one misses — measured on one project, SELF_TEST found 6 files here and the same word found 5 through search_bodies, the extra file holding the comment Self tester.

For the footprint of one feature, run both.

Results are file-level — one entry per matching file, with match_lines for the lines that hold a query term. project_only=True filters to is_project = 1 files; the default False includes the vendor SDK files.

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: yes. Requires the FTS5 index with file content. May auto-reindex stale files (non-blocking) — see search_code.

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. project: Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both. limit: Maximum results of one page (default 20, max 100). offset: Skip this many results. Reads the next page of a topic that many files touch; the page notice names the offset to use. project_only: When True, filter to project code only (files with is_project = 1). variant: Build variant (multi-build project). Omit to use default_variant. One query answers for ONE build. image: Sysbuild image within the variant. Required when the variant holds several: each image is a separate program.

Returns: list of dicts. The page notice leads the answer — total, offset, shown, more — and each that follows holds: file, language, mtime, _match_snippet (highlighted excerpt around the match).

Also, when it carries an answer:

* ``match_lines`` (list[int]) — line numbers of the lines that hold
  a query term, up to 20.  They are the line numbers of the file
  itself: an inactive ``#ifdef`` branch is a blank line, thus the
  count never shifts.  Cite ``file:line`` from here.

  The field is absent when FTS5 matched a variant of the token that
  the term is not a substring of — ``SELF_TEST`` matches the file
  that writes ``Self tester``, and no line holds ``self_test``.
  Read ``_match_snippet`` in that case.

No match gives ``[]``.  A dict with ``error`` means the query
failed.  A stale index prepends a dict with ``warning`` + ``hint``,
and so does a query that FTS5 refuses to parse — the answer then
comes from the LIKE path and carries ``_fallback: "like"``.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
imageNoSysbuild image within the variant. Required when the variant holds several: each image is a separate program.
limitNoMaximum results of one page (default 20, max 100).
queryYesFTS5 search terms for full file content. 1-3 words. E.g. 'InterruptIn', 'extern C'. Bare multi-word = OR-joined.
offsetNoSkip this many results. Reads the next page of a topic that many files touch.
projectNoProject name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.
variantNoBuild variant (multi-build project). Omit to use default_variant. One query answers for ONE build.
project_onlyNoExclude vendor SDK code. When True, only application code. Default False.
project_rootNoProject root. Auto-detected if omitted. This field also accepts a project name or a project_id, but project is the clear field for those.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.32.0
    • changedInput schema / properties / image / description
      Previous value: -"Sysbuild image name within the variant (multi-project). Omit for all images of the variant."New value: +"Sysbuild image within the variant. Required when the variant holds several: each image is a separate program."
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum results (default 20, max 100)."New value: +"Maximum results of one page (default 20, max 100)."
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Skip this many results. Reads the next page of a topic that many files touch.",
      +  "minimum": 0,
      +  "title": "Offset",
      +  "type": "integer"
      +}
    • addedInput schema / properties / query / minLength
      Added value: +1
    • changedInput schema / properties / variant / description
      Previous value: -"Build variant name (multi-project). Omit to use default_variant or fail-closed. Use '*' for all variants."New value: +"Build variant (multi-build project). Omit to use default_variant. One query answers for ONE build."
  2. Changed3 schema fields changedv0.30.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / project
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.",
      +  "title": "Project"
      +}
    • changedInput schema / properties / project_root / description
      Previous value: -"Project root. Auto-detected if omitted."New value: +"Project root. Auto-detected if omitted. This field also accepts a project name or a project_id, but project is the clear field for those."
  3. Changed2 schema fields changedv0.25.3
    • addedInput schema / properties / image
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Sysbuild image name within the variant (multi-project). Omit for all images of the variant.",
      +  "title": "Image"
      +}
    • addedInput schema / properties / variant
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Build variant name (multi-project). Omit to use default_variant or fail-closed. Use '*' for all variants.",
      +  "title": "Variant"
      +}
  4. Changed1 schema field changedv0.18.2
    • changedInput schema / properties / project_only / description
      Previous value: -"Exclude vendor SDK code (mbed-os/, .pio/, zephyr/, build/). When True, only your application code (src/, lib/). Default False."New value: +"Exclude vendor SDK code. When True, only application code. Default False."
  5. Addedv0.13.1

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and excels. It discloses ifdef-filtering behavior, line-number preservation via blank lines, file-level results, LIKE-fallback with '_fallback: like', stale-index auto-reindex, read-only nature, and the subtle case where match_lines are absent because FTS matched a token variant. This is far beyond what structured data could convey.

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 long but structured with distinct sections (purpose, sibling contrast, Args, Returns) and front-loaded with the core scoping statement. Some redundancy exists—'Covers the text that belongs to no definition' is repeated in the contrast paragraph—but given the 8-parameter complexity and zero annotation coverage, the length is mostly earned.

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 description is complete for a complex search tool with 8 parameters and no annotations. It covers error shapes (dict with 'error'), warnings/hints for stale or unparseable queries, page-notice fields (total, offset, shown, more), match_lines semantics, and the no-match case ([]). Nothing an agent needs to call this correctly is missing.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds meaning beyond the schema: it explains the OR-joining and prefix-wildcarding of bare multi-word queries ('every term gets a trailing *'), the project vs project_root mutual exclusion, pagination semantics with offset/page-notice, and variant/image build scoping. These details materially change how an agent should construct calls.

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 states a specific verb, resource, and scope: 'Find patterns in FULL file content — the whole file, not only the text that belongs to a definition.' It explicitly differentiates from siblings by contrasting with search_code (finds by NAME) and search_bodies (definitions only), so an agent can pick the right tool immediately.

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 explicit when-to-use guidance and names alternatives with clear conditions: 'To find a symbol by NAME... use search_code' and 'search_bodies answers WHICH DEFINITION... search_content answers WHICH FILES.' It even advises running both for a feature footprint and explains the fallback path when files_fts is missing.

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