Skip to main content
Glama
Lyellr88

marm-memory

marm_code_context

Get task-relevant code symbols, source, and memory in one call. Understand how something works, where it's handled, or what a change would affect.

Instructions

🧩 Composed code context for a task: ranked symbols + source + memory, in ONE call.

Prefer this over marm_code_lookup when the question is "how does X work",
"where is X handled", or "what would changing X affect" -- it answers with
the symbols that matter, their source read from disk, and what memory
records about them, instead of leaving you to fetch each part yourself.

Ranking is personalised PageRank over the call graph seeded from `task`, so
a result is central *to this task* rather than globally popular or merely
word-matching. Read `markdown` and stop; the structured fields are the same
content for programmatic callers.

Parameters:
- task: what you are trying to do or understand
- project: code-graph project name or repo path; omit to resolve from cwd
- cwd: directory to resolve the project from (optional)
- budget: character budget for the returned source, 500-100000 (default 12000)
- include_graph: also return the ranked call neighbourhood as `graph_edges`;
  off by default because it is several KB of JSON only a visualiser reads
- answer: also answer the task from the composed context with a local
  model, citing the symbols it used. Off by default -- it is the slow step,
  and for an agent that reads code the ranked context IS the answer.
  `answer_status` is "ok" only when its citations resolve to composed
  symbols and none name anything else, otherwise "unverified" with
  `answer_unresolved`; "unavailable" rather than a failure when
  generation is off or no model is up
- detail: how much to return. 1 is markdown only and is the default,
  because `markdown` already contains the source and the memory text --
  asking for 3 means paying for the same bytes twice. 2 adds symbol and
  memory metadata without repeating bodies; 3 adds them. 0 means "use the
  server default" (MARM_CODE_CONTEXT_DETAIL)

Returns: status, project, markdown, symbols, memories, links, graph_nodes,
notes -- or a no_project/unavailable status carrying the next step to take.
Each symbol carries `label` (the code KIND) and, when it arrived through the
call graph rather than by matching the task, a `provenance` object with hop,
strategy, confidence and risk; `provenance` is null for a seeded symbol

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNo
taskYes
answerNo
budgetNo
detailNo
projectNo
include_graphNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.52.0
    • addedInput schema / properties / answer
      Added value: +{
      +  "default": false,
      +  "title": "Answer",
      +  "type": "boolean"
      +}
  2. Addedv2.50.1

TDQS

A5/5.0
Behavior5/5

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

No annotations are present, but the description fully carries the burden: it discloses personalized PageRank ranking, disk-read behavior, answer_status semantics ('ok', 'unverified', 'unavailable'), the cost of detail=3 duplicating bytes, and the JSON size of include_graph.

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?

Long but tightly structured: front-loaded summary, a usage-routing paragraph, and a bullet list where each parameter earns its place. No repeated schema information.

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?

With no output schema or annotations, the description still covers return fields, failure statuses, symbol provenance, and the next-step hint in no_project/unavailable statuses. Nothing an agent needs to invoke this complex tool safely 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?

Schema coverage is 0%, yet the description documents every parameter with meaningful guidance: task purpose, project/cwd resolution, budget bounds, default behavior, include_graph cost, answer citation semantics, and detail levels including the default 0 server fallback.

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?

States exactly what it does: composed code context for a task with ranked symbols, source, and memory in one call. Immediately contrasts with marm_code_lookup, letting an agent distinguish the two without opening schemas.

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?

Explicitly says 'Prefer this over marm_code_lookup' for specific question types (how X works, where X is handled, what changing X affects), and gives operational guidance like 'Read markdown and stop' and when to enable optional flags.

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