Embedcalc MCP vs Fw Context MCP — MCP Server Comparison | AllMCPs
Embedcalc MCP vs Fw Context MCP
A side-by-side look at the Embedcalc MCP and Fw Context MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Embedcalc MCP for embedded system work over a hosted endpoint; choose Fw Context MCP for embedded system as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
E
Choose Embedcalc MCP when
You need dedicated capabilities in the Embedded System domain.
No tool names declared yet. Check the project README from the listing page.
Fw Context MCP tools 39
check_dependenciesRun the full dependency audit. Read-only. Returns structured results.
Returns the raw per-check dicts (``name``, ``status``, ``message``,
``fix_cmd``, ``instructions``, ``critical``) — NOT the formatted
``doctor`` table. Read ``status``/``fix_cmd``/``instructions`` per
issue; ``status="skipped"`` means a prerequisite is missing.
Args:
project_root: Project root directory. Auto-detected from CWD 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.
Returns:
list[dict]: one dict per check, ``DepCheckResult`` fields via ``asdict``.
check_ollamaCheck whether the LLM backend is running and the configured embedding/chat model is installed.
Read-only: yes. No side effects. Call before smart_search,
semantic_search, or explain_symbol (when on-demand fallback is
expected — pre-computed analysis returns instantly without the LLM
backend).
Args:
project_root: Project root. Auto-detected if omitted. Used to
locate the project's LLM configuration.
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.
Returns:
dict: {ollama_enabled (bool), status (str — "ok"|"disabled"|
"not_configured"|"model_missing"|"embedding_unavailable"|"error"),
ollama_running (bool), ollama_url (str), configured_model (str),
num_ctx (int), installed_models (list[str]),
chat_api (dict — ``{configured (bool), model (str)}``: whether an
external chat API replaces Ollama, and the model it names),
configured_embed_model (str), embedding_installed (bool),
message (str, on error/disabled), model_details (list[dict], when
Ollama running), suggest_cloud (bool), vec_available (bool),
vec_error (str, optional), debug_log (str, optional — only when
debug logging is enabled)}
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Embedcalc MCP is categorized under Embedded System and uses a remote HTTP/SSE transport. Fw Context MCP belongs to Embedded System and uses a local stdio subprocess. Pick Embedcalc MCP for embedded system work and Fw Context MCP for embedded system.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Embedcalc MCP is listed as free. Auth: no auth required. Fw Context MCP is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add embedcalc-mcp-2 and turbyho-fw-context-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Embedcalc MCP has a quality signal of 42/100 (Fair) with 0 views, 0 installs and 0 GitHub stars. Fw Context MCP has 61/100 (Good) with 3 views, 0 installs and 10 GitHub stars.
configure_llmConfigure LLM settings for the current project.
Writes to ``<project>/.fw-context/local.toml`` ONLY (gitignored,
per-developer). Does NOT modify the global config or the shared
project ``config.toml``. After writing, tests the configuration
by making a simple API call (skipped when LLM is disabled).
IMPORTANT: When ``chat_api_base`` points to an external host, source
code snippets in chat prompts will be sent to that endpoint. Ensure
this complies with your organization's data security policies.
Consider using local Ollama or an internal API proxy first.
Args:
project_root: Project root directory. 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.
chat_api_base: Chat API URL (see description for format details).
chat_api_key: Bearer token for cloud/proxy APIs.
chat_api_format: Override auto-detection: "auto", "ollama", "openai".
model: Chat model name.
embed_model: Embedding model name (Ollama only).
auto_pull: Whether to auto-pull models on 404.
stream: Stream chat responses via SSE. True avoids reverse-proxy idle timeouts.
Returns:
dict: {status ("ok"|"error"), chat_api (dict — configured, endpoint,
format, model), model (str), auto_pull (bool), stream (bool),
test_latency_s (float, on success), test_response (str, on success),
compliance_warning (str, when chat_api_base is external),
message (str)}
get_active_buildMANDATORY FIRST CALL for C/C++ projects. Return metadata about the
most recently indexed build configuration — check index health before
using any other fw-context tools.
Read-only, and it spawns no subprocess — the startup daemon thread and
the file watcher own the background reindex.
Act on ``status``:
* ``"ready"`` — up to date. Continue.
* ``"reindexing"`` — background reindex running; queries stay accurate.
Continue. ``reindex_progress`` holds its last log line.
* ``"reindex_needed"`` — schema mismatch, an old row format, changed
compile_commands.json, or a source file that compile_commands.json
does not cover. Queries still work on existing data. Read
``reindex_reasons``: a missing source file needs
``fw-context index --build``, the others need only
``fw-context index``.
Read ``bg_reindex_running`` before you name any command here. A run
already under way does the work, thus a second one only waits on the
same lock, and ``index_message`` and the branch reason both say so.
That field covers a run of the daemon AND a run the operator started
— the arguments of neither are readable, thus a reason that needs
``--build`` can outlive a run without it. This status wins over
``"reindexing"`` deliberately: the answers of this moment come from
the rows of the last FINISHED run.
* ``"no_index"`` — initialized, never indexed. Run ``fw-context index``.
* ``"not_initialized"`` — run ``fw-context init``.
A failure sets NO ``status``. DB corruption, or no access to the
index, gives a dict that holds ``error`` alone. Read that key first:
a reader that waits for ``status == "error"`` waits for a value this
tool does not produce.
Four conditions set ``reindex_needed``: an outdated schema, an outdated
ROW FORMAT, a changed compile_commands.json, and a source file that is
on disk but absent from compile_commands.json. The last one needs a
build, because only the build system writes that file — a plain reindex
has no translation unit for the file and skips it without a word.
Modified source files are something else: they are handled per-query,
and never set it.
``row_format_mismatch`` means that the same columns hold text with an
older meaning. Take it seriously: an index written before
``fw-context-rows/1`` keeps every inactive ``#ifdef`` branch, thus a
body or a file from it can show code that the compiler never sees. An
index written before ``fw-context-rows/3`` is wrong the other way: it
ANSWERS LESS than it should. A definition that begins and ends on one
line has no stored body there, thus ``search_bodies`` cannot reach an
inline accessor; no macro is marked function-like; and no instance links
to its template, thus ``get_template_instances`` gives an empty list for
every template. Each of those looks like a legitimate empty answer.
The ``value`` of a macro there also holds its parameter list glued to
its replacement text, thus neither can be read out of it.
``client_restart_required`` is the OPPOSITE case, and no command repairs
it. The index carries a NEWER row format than this server process
reads, thus the index is the correct one and this process is the old
reader. A reindex makes it worse than useless: the indexer writes the
same new format again, and the message comes back over an index that had
nothing wrong with it. ``status`` therefore stays ``"ready"`` and
``reindex_needed`` stays False — every query keeps working.
Do NOT run a reindex for this field. Tell the operator to restart the
LLM client — Claude Code, opencode, or whichever one is in use. The MCP
server is a child process of that client, thus nobody can restart the
server by itself. ``client_restart_reason`` holds the wording, and
``index_message`` opens with it.
``indexed_at`` and ``first_indexed_at`` are UTC; file mtimes are local
time. Never compare the two directly — in UTC+2 a correctly indexed
file looks 2 hours newer than ``indexed_at``. Call with ``fast=False``
to find modified files.
``analysis`` splits the LLM-analysis coverage into project and vendor
symbols:
* ``model`` — the model of the analysis, or None. One model only, even
when several were used.
* ``analyze_vendor`` — the value at index time, not the current config.
* ``project`` / ``vendor`` — ``{analyzed, skipped, total}``.
``skipped`` = tried, but not analyzable (body larger than the model
context, an unparseable answer, or a body that was not readable).
* ``complete`` — no work left: every project symbol is analyzed or
skipped. True exactly when ``reindex_reasons`` holds no "unanalyzed
symbols" entry. Vendor symbols excluded by ``analyze_vendor=False``
never block it, thus ``vendor.total`` large with ``vendor.analyzed=0``
is expected, not a defect.
Args:
project_root: Project root directory. Auto-detected from CWD 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.
fast: When True (default), the header check reuses the cached
manifest hashes. Both modes run the per-file scan, thus
``modified_files_count`` is accurate either way — a tool that
reported "ready" while the search tools warned about the same
file gave the caller two readings and no way to choose.
False recomputes the header hashes and costs several times more.
Returns:
dict: {config_hash, project_id, project_root, build_system,
compile_commands, indexed_at (str — "YYYY-MM-DD HH:MM:SS" in UTC,
the completion time of the last full index), symbol_count, file_count,
reference_count, modified_files_count (int — files whose content no
longer matches the index; counted in both modes),
header_affected_tus (int — number of TUs with stale header
dependencies), manifest_verification (str —
"full" when manifest.json exists, "none" otherwise),
analysis (dict — LLM-analysis coverage split by project/vendor:
{model, analyze_vendor, project: {analyzed, skipped, total},
vendor: {analyzed, skipped, total}, complete}),
description (str), first_indexed_at (str — UTC, same format as
indexed_at),
vendor_paths (list[str] — config index.vendor_paths),
project_paths (list[str] — config index.project_paths),
effective_vendor_patterns (list[str] — the SQL LIKE patterns that
this build really used to mark vendor code, for example
``["mbed-os/%"]``; empty when the manifest cannot be read. The two
lists above hold what the config asks for, this one what the index
did),
bg_reindex_running (bool),
reindex_progress (str or None — last log line when reindex is running),
schema_version (int — DB schema version),
current_schema (int — code expects), status (str — "ready"|"reindexing"|
"reindex_needed"|"no_index"|"not_initialized"; a failure sets no
status and gives ``error`` alone), reindex_needed (bool —
structural mismatch requiring a full reindex),
reindex_reasons (list[str] — why reindex is needed, empty when False.
One of them asks for `fw-context index --build` rather than a plain
reindex: when the tree is on a different branch than the index,
compile_commands.json belongs to the OLD branch and carries its file
list and its compiler flags, so only a build regenerates it. Read
the reason text — it names the command it needs),
stale (bool — True when reindex_needed or header_affected_tus > 0),
_warning (str, optional — when manifest verification is not "full"),
vec_available (bool), vec_error (str, optional),
index_message (str — human-readable summary of index state),
multi (bool — True for a multi-variant project),
variants (list[dict] — {name, description, board}),
images (list[dict] — {name, description, dir, type}),
variant_images (dict — variant name to its image names),
active_variant (str or None — [build] default_variant),
active_image (str or None — [build] default_image),
entry_point (str — the `ENTRY()` of the linker script of the build
that the other fields describe, empty when no script names one),
memory (list[dict] — the `MEMORY` regions of that build:
{name, attributes, origin, length, origin_value, length_value,
file_path, line})}
About ``memory``: ``origin`` and ``length`` hold the expression the
script writes, thus they differ by platform — an mbed script writes
`0xefe00` and a Zephyr script writes `((673792) - 0xe6)`.
``origin_value`` and ``length_value`` hold the number, and both are
None for an expression that names a symbol, such as
`ORIGIN(RAM) + LENGTH(RAM)`. The end of a region is
``origin_value + length_value``.
``memory`` and ``entry_point`` describe ONE build. For a
multi-variant project they follow ``config_hash``, which is the
build named by ``[build] default_variant``, and both are empty when
the config names no default. Use ``list_variants`` for the map of
every build.
``memory`` is empty for a build system that records no linker
script. A PlatformIO project is the measured case: SCons writes no
ninja file and no link command the index can read, and the map file
never names the script. An empty list means "not recorded", never
"no memory".
``defines`` (dict — the `-D` flags of that build) and
``defines_varying`` (int). ``defines`` holds only the names that
EVERY translation unit of the build carries with the same value, so
the tool never shows the defines of one file as the defines of the
build. ``defines_varying`` counts the names left out, thus a name
absent from ``defines`` is either not defined at all or not defined
everywhere — measured on the Mbed project: 27 names in all 881 units, 59
in only some, where the three assembly files get a shorter set.
This is the configuration the BUILD states, not every macro the
preprocessor saw. The second is three orders of magnitude larger —
27800 distinct names on the STM32 project — and almost all of it comes from the
headers and the compiler. A Zephyr build keeps its real
configuration in ``autoconf.h`` (740 `CONFIG_*` names) and passes
few `-D` flags, so ``defines`` says little there and a great deal on
an mbed build, where it holds `APPLICATION_ADDR`,
`APPLICATION_SIZE`, and `CMSIS_VECTAB_VIRTUAL`.
For a project that is not initialized, the result holds only
``status``, ``project_root``, and ``index_message``. When no index
exists, the result adds ``project_id``.
get_environment_statusReturn the complete project environment status in one call.
Read-only. Aggregates five domains into a single call so the LLM can
see everything at session start without extra round-trips:
- ``deps`` — dependency audit (``run_full_check``), each entry with an
optional ``action`` (``message`` + shell ``command``). ``status="skipped"``
means a prerequisite is missing (e.g. ``libclang-so`` skipped because
``libclang-python`` is absent) — not a failure.
- ``build_system`` — detected build system, ``None`` when unknown.
- ``compile_db`` — whether compile_commands.json exists and its entry count.
Reported as ``{"exists": false, ...}`` before init (no config to resolve
the path from, and loading one would create empty config files).
- ``index`` — the FULL ``get_active_build()`` result, unchanged (its action
lives in ``index_message``).
- ``llm`` — LLM backend status with an optional ``action``.
When the project is not initialized (``index.status == "not_initialized"``),
only the config-independent dependency subset runs (checks that do not need
a project config) — Ollama/model/db/build checks are skipped.
Args:
project_root: Project root directory. Auto-detected from CWD 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.
Returns:
dict: {init_status (str — "initialized" or "not_initialized"),
deps (list[dict] — name, status, message, and an optional action),
build_system (str or None),
compile_db (dict — {exists (bool), path (str or None),
entry_count (int or None — None before init, and when fw-context
cannot read the file)}),
index (dict — the full ``get_active_build`` result),
llm (dict — {enabled, ollama_running, chat_model, embed_model}, plus
``ollama_enabled`` when the LLM check ran, plus an optional
``action``)}.
get_project_infoReturn project metadata (name, type, root_path) for a project ID.
Looks up the global project registry at ``~/.fw-context/projects.db``.
Use this to identify a project from its UUID4 — find out what build
system it uses, its name, and where it was last indexed.
Read-only. No side effects.
Args:
project_id: Project ID (UUID4 hex) to look up.
Returns:
dict: {project_id, name, project_type, root_path, created_at, updated_at}
or {"error": "..."} when the project_id is not registered.
On failure the dict holds only ``error`` with the reason.
list_projectsList all indexed firmware projects with their statistics.
Read-only. No side effects. Use at session start to discover available
projects; use ``get_active_build`` for details on the currently active project.
``indexed_at`` and ``first_indexed_at`` are UTC, in ``"YYYY-MM-DD
HH:MM:SS"`` format — the same format that ``get_active_build`` returns.
``analysis`` holds the ``project`` and ``vendor`` counts only. For the
``model``, ``analyze_vendor``, and ``complete`` fields, call
``get_active_build`` for that project.
Args:
project_root: Project root. Auto-detected if omitted. Pass to
distinguish multiple indexed projects.
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.
Returns:
list of dicts, each with: project_id, name, root_path, build_system,
symbol_count, file_count, indexed_at (str — UTC), description (str),
first_indexed_at (str — UTC), schema_version, current_schema,
reindex_needed (bool), status (str — "ready" or "reindex_needed"),
db (path to SQLite database file),
variant_count (int — number of build variants),
image_count (int — number of sysbuild images),
analysis (dict — LLM-analysis coverage
{project: {analyzed, skipped, total},
vendor: {analyzed, skipped, total}}, or None when no build is
indexed).
When no project has an index, the result is a single dict with an
``info`` key. When fw-context cannot read a database, the result
holds a dict with ``db`` and ``error`` keys for that file.
list_variantsList every indexed build with its (variant, image, board) identity.
Read-only diagnostic — shows what is actually indexed, not what the config
declares. Each row is one ``(variant, image)`` build with its own
``config_hash`` and symbol count. For single-project indexes this returns
one row with ``variant``/``image`` empty.
This and ``get_active_build`` are the two tools that say what a query can
choose from. Both read the index, thus a build written by
``fw-context index --build --variant X`` is listed even when config.toml
no longer declares X — and ``resolve_build`` fails closed on that same
fact, so the two never disagree about whether a choice must be made.
Use ``get_active_build`` for the mandatory first-call health check and the
human-readable ``variants``/``images`` discovery; use this tool to see the
per-build ``config_hash`` and symbol counts (authoritative per-build state).
Args:
project_root: Project root directory. Auto-detected from CWD 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.
Returns:
dict: {builds (list[dict]), multi (bool — True when the config
declares variants or a build has a non-empty variant name)}.
Each build dict holds: variant (str — empty for a single-project
index), image (str — empty for a single-project index), board (str),
config_hash (str), symbol_count (int), file_count (int),
manifest_verification (str — "full" or "none"),
entry_point (str — the `ENTRY()` of the linker script of this build,
empty when no script names one),
memory (list[dict] — the `MEMORY` regions of this build:
{name, attributes, origin, length, origin_value, length_value,
file_path, line}). `origin` and `length` are the expression the
script writes; `origin_value` and `length_value` are numbers, and
they are None for an expression that names a symbol such as
`ORIGIN(RAM) + LENGTH(RAM)`. Empty for a build whose system
records no linker script — see the note below.
THIS is where a per-build memory map lives, not in the `images`
list of ``get_active_build``: that list holds one entry per image
NAME, and one name can belong to two variants with different
addresses.
When the project is not initialized, or has no index, the result is
{builds: [], multi: False, error (str)}.
reindex_fileRe-parse a single source file with libclang and update its symbols in the index.
Not read-only — uses the exact compiler flags from ``compile_commands.json``.
Use after editing a file to keep the index current without a full rebuild.
A source file must be listed in ``compile_commands.json``. A header is
not listed there, thus it is re-parsed through one unit that includes
it. That answer covers a single compilation context, thus the result
carries a ``warning`` — only a full ``fw-context index`` covers every
unit that includes the header.
Also regenerates LLM analysis and method override relationships for
affected symbols when those features are enabled in config. An
unchanged symbol keeps its stored analysis.
Args:
file_path: Path to the file to re-parse. A source file must be in
compile_commands.json; a header goes through one including unit.
project_root: Project root directory. 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.
Returns:
dict: {file, translation_units, symbols_updated, elapsed_s,
analysis_updated (if LLM enabled), or error}.
reindex_file_implRe-parse a single source file with libclang and update its symbols in the index.
Not read-only — uses the exact compiler flags from ``compile_commands.json``.
Use after editing a file to keep the index current without a full rebuild.
A source file must be listed in ``compile_commands.json``. A header is
not listed there — compile_commands.json names translation units — so it
is re-parsed through one unit that includes it, taken from the manifest.
That answer describes a single compilation context, thus the result
carries a ``warning``: another unit can see the header under a different
set of ``#define`` values and still hold stale symbols. Only a full
``fw-context index`` covers every context. One unit and not all of them
is a cost decision — an application header reaches a median of 3 units
but as many as 266 on a real project, at tens of seconds each.
Also regenerates LLM analysis and method override relationships for
affected symbols when ``with_analysis=True``. The analysis is
content-addressed, thus an unchanged symbol is never re-analysed.
Args:
file_path: Path to the file to re-parse. A source file must be in
compile_commands.json; a header goes through one including unit.
project_root: Project root directory. 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.
with_analysis: When True (default), also regenerates LLM symbol analysis,
method override relationships, PageRank, and embeddings. Set False
for a fast symbol-only update (used by background auto-reindex).
Returns:
dict: {file, translation_units, symbols_updated, elapsed_s,
analysis_updated (if LLM enabled with analysis), or error}.
On failure the dict holds only ``error`` with the reason.
reset_indexDelete the entire symbol index for a project.
Not read-only — permanently deletes the SQLite database and WAL files.
Call with ``confirm=False`` first (dry-run) to see what would be deleted.
Re-index with ``fw-context index`` afterwards.
Handles corrupt databases gracefully — you can delete a corrupt index
without needing to open it first.
Args:
project_root: Project root directory. 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.
confirm: Must be True to execute. Call without first as dry-run.
Returns:
dict: {project_root, db, project_id, action: "dry_run"|"deleted",
message, symbol_count, indexed_at (dry-run)}.
A ``warning`` key means that the database is corrupt — the
integrity check failed, thus the counts can be incomplete.
On failure the dict holds only ``error`` with the reason.
lookup_symbolLook up a C/C++ symbol by name via libclang index — exact or prefix
matching. Finds symbols text-based search can miss: build-conditional
code, template instantiations, macro-expanded names. Macros are
extracted via ``clang -dM -E`` during indexing so ``#ifdef``-conditional
macros resolve correctly for the active build config. Prefer this over
search_code when you know the exact symbol name or a prefix
(``uart_`` finds all UART symbols). Use search_code for
keyword/concept search.
Read-only: yes. May auto-reindex stale files (non-blocking).
Args:
name: Symbol name (exact match) or prefix (set exact=False).
E.g. 'uart_init' finds the exact function; 'uart_' finds
all symbols starting with 'uart_'.
project_root: Project directory. 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.
exact: True = exact name match, False = prefix LIKE match (default).
limit: Maximum results of one page (default 50, max 100).
offset: Skip this many results (default 0). A common method name
lives in many classes — ``read`` and ``write`` match dozens of
symbols — and this walks past the ones already seen. The page
notice names the offset to use. The order is stable (a
definition first, then the line, then the file and the USR),
thus two pages never overlap and never skip a symbol.
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[dict]: The page notice leads the answer — ``total``, ``offset``,
``shown``, ``more`` — where ``total`` counts every symbol the name
matches. Read it before you conclude that a page holds them all.
Each symbol that follows has name, qualified_name, kind, file,
line, signature, docstring, is_definition, is_template, is_virtual,
is_pure_virtual fields, and ``class`` — the class, struct or union
that declares the symbol, absent for a free function. ``class`` is
what tells two same-name methods apart at a glance.
Enum constants include ``enum_value``
with the integer value. Macro results include ``kind="macro"``,
``signature`` (how the macro is invoked: ``#define NAME``,
``#define NAME()`` or ``#define NAME(a, b)``), ``is_function_like``,
``value`` (the replacement text ALONE — the parameter list is not
part of it), and ``expanded_value`` (preprocessor-resolved value).
May also include ``template_usr``,
``parent_usr``, and ``llm_analysis`` (``{summary, inputs,
outputs}``) when available. A model wrote the text in
``llm_analysis``, and the code did not — use it to find a symbol,
and quote ``signature``, ``docstring``, or ``get_source`` instead.
When no results found, may include ``_did_you_mean`` with suggested
symbol names. When no symbol matches, the list is empty — there is
then no page notice, because there is no page. An ``info`` entry
comes back for one case only: an offset past the end of an answer
that does hold rows.
**Note:** C++ constructors share their name with the enclosing
class, so ``lookup_symbol("Foo")`` may return both ``class Foo``
and ``constructor Foo::Foo()``. Use the ``kind`` field to
filter when you need a specific symbol type.
A symbol that comes from the relaxed prefix fallback carries
``_fallback: True`` — the name is not an exact match of *name*.
A list with one dict that holds an ``error`` key means that the
project has no index, or that the lookup failed. Read that key
before you read the result fields.
Choose Fw Context MCP when