Memory MCP

ingest_codebase_summary

Bootstrap project memory from a high-level codebase summary, extracting structured facts so future sessions across tools retain project context.

Instructions

Bootstrap project memory from a high-level codebase description.

Pass a description of the project — what it does, its architecture, the main modules and their responsibilities, key decisions, deployment setup, domain terminology. Memory MCP will extract structured facts and store them.

Ideal for onboarding: describe your project once, and every future session (across all connected tools) will already have the context.

How to resolve the project_name

Same as remember: auto-match if unambiguous. If ambiguous, call list_projects() and explicitly ask the user to choose. Once chosen, session-lock it.

Args: summary: A description of the codebase/project. Can be multi-paragraph. Include as much detail as useful: what the project is, its modules, architecture, tech stack, deployment, key decisions, domain terms. project_name: Project name. Facts will be stored under this project. If omitted, stored as global. tool: Calling tool name (for audit + provenance).

Returns counts of extracted/created/merged/superseded facts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "summary": "<summary>"
    },
    "name": "ingest_codebase_summary"
  }
}

Input Schema

Name	Required	Default
`tool`	No	unknown
`summary`	Yes
`project_name`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 31, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose the key traits: text is parsed into structured facts, stored persistently and visible to future sessions across connected tools, and omitted project_name means global storage. It stops short of saying what happens to conflicting pre-existing facts beyond the return-count mention of superseded/merged.

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?

Purpose is front-loaded in the first line, followed by a usage note and a clearly headed resolution procedure, so an agent can stop reading early. The 'Args:' block partly duplicates the opening paragraph (the list of things to include in summary) and costs some redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a bootstrap/ingest tool this covers the essentials: what to supply, how to resolve ambiguity, where facts land, and a note on return values (counts of extracted/created/merged/superseded), which is more than required given an output schema exists. Ingestion cost or size limits on the summary are not mentioned.

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 description coverage is 0%, so the description must compensate, and it does: summary is described as multi-paragraph with suggested content categories, project_name is explained including the omit-to-global default, and tool is labeled as audit/provenance. Only the exact format of project_name (slug vs. display name) is left unstated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: bootstrap project memory from a high-level codebase description, with a sentence on what gets stored (extracted structured facts). It doesn't explicitly contrast with the nearest sibling ingest_conversation, so the distinction (codebase prose vs. conversation transcript) must be inferred from the word 'codebase'.

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?

Gives an explicit use case ('Ideal for onboarding: describe your project once') and a procedural rule for the tricky part – auto-match project_name if unambiguous, otherwise call list_projects() and ask the user, then session-lock. It also names the sibling (remember) whose semantics are reused.

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

Deploy Server