The fish-bridge-mcp server lets AI agents manage conversational context by building and querying a session-scoped knowledge graph. Here's what you can do:
Record conversation turns: Ingest user/assistant messages to incrementally update the session knowledge graph.
Retrieve full session context (get_context): Return the compressed session graph as XML for AI recall.
Get focused context (get_focus): Query the graph with a natural language question to retrieve only the most relevant nodes and their neighborhood.
Mark items resolved (mark_resolved): Mark questions, tasks, or errors as resolved, with optional resolution notes.
Add nodes manually (add_node): Insert typed nodes (question, decision, concept, skill, file, error, or task) with a label, summary, and status.
Export the session graph (export_session): Serialize the full graph to a portable JSON string for backup or transfer.
Import a prior session (import_session): Merge a previously exported session graph into the current one, carrying forward decisions and reactivating deferred nodes.
List deferred items (list_deferred): Show all parked questions, tasks, decisions, and errors.
Show active session thread (show_active): Display open questions, pending tasks, active errors, and key decisions in plain text.
Allows ingesting Docker Compose files to incorporate infrastructure context into the knowledge graph.
Allows ingesting Jest test output to add error nodes for failing tests and integrate test results into the session graph.
Enables merging notes from an Obsidian vault, including wikilinks and frontmatter, into the knowledge graph.
Provides a local backend for offline knowledge graph extraction using Ollama models (e.g., qwen2.5:7b).
Provides a cost-effective backend for knowledge graph extraction using OpenAI's GPT-4.1-mini model.
Allows ingesting pytest test output to add error nodes for failing tests and integrate test results into the session graph.
Allows ingesting Swagger 2.0 API specifications as part of the OpenAPI merge source to incorporate API documentation into the graph.
Enables ingesting Terraform infrastructure-as-code files to add infrastructure context to the knowledge graph.
Session-scoped knowledge graph engine for AI chat context compression.
Converts raw AI chat (40k+ tokens) into a compact typed knowledge graph (~300–800 tokens) and writes it to .github/copilot-instructions.md or CLAUDE.md — automatically included in every AI turn across all modes (ask, edit, agent). No MCP server required for the core workflow.
Raw session (40k tokens) → [fish_bridge] → Compressed graph (350 tokens)
written to copilot-instructions.md
picked up by every AI turn automaticallyDon't have
uv? Get it first:curl -LsSf https://astral.sh/uv/install.sh | sh(macOS/Linux) or see uv docs. It replaces pip + pipx + pyenv in one tool — no virtualenv management needed.
Recommended — uv tool install (installs both the fish-bridge CLI and fish-bridge-mcp MCP server on your PATH):
# Local Ollama backend — free, offline (requires Ollama running)
uv tool install fish-bridge-mcp
# Gemini backend (~$0.0002/turn, ~95% quality — recommended cloud option)
uv tool install "fish-bridge-mcp[gemini]"
export GEMINI_API_KEY=...
# Claude backend (~$0.002/turn, ~97% quality)
uv tool install "fish-bridge-mcp[claude]"
export ANTHROPIC_API_KEY=sk-ant-...
# OpenAI backend (~$0.0003/turn, ~93% quality)
uv tool install "fish-bridge-mcp[openai]"
export OPENAI_API_KEY=sk-...
# Everything
uv tool install "fish-bridge-mcp[all]"After install, two commands are available on your PATH:
fish-bridge — the main CLI (ingest, compile, show, serve, ...)
fish-bridge-mcp — the MCP server for VS Code agent mode
MCP config only (no permanent install needed): use uvx directly in your .vscode/mcp.json — it downloads and runs the MCP server on demand:
{ "command": "uvx", "args": ["fish-bridge-mcp"] }See the MCP server section below for the full config.
pip install fish-bridge-mcp
pip install "fish-bridge-mcp[gemini]" # with Gemini backend
pip install "fish-bridge-mcp[claude]" # with Claude backend
pip install "fish-bridge-mcp[all]" # everythingRelated MCP server: better-code-review-graph
# 1. Initialize for your project
fish-bridge init --tool copilot --project ./
# 2. Ingest the latest Copilot session (auto-discovers JSONL on macOS/Linux/Windows)
fish-bridge ingest --source copilot
# 3. View the graph
fish-bridge show
# 4. Compile to your instructions file (done automatically after ingest)
fish-bridge compileThat's it. .github/copilot-instructions.md now contains a ~350-token compressed summary of your session, replacing raw history in every future turn.
Backend | Install extra | Model | Quality | Cost/turn |
| (none — requires Ollama) | qwen2.5:7b | ~85% | $0 |
|
| gemini-2.5-flash | ~95% | ~$0.0002 |
|
| gpt-4.1-mini | ~93% | ~$0.0003 |
|
| claude-opus-4-7 | ~97% | ~$0.002 |
|
| local+cloud | best | mixed |
Configure with:
fish-bridge config --backend gemini
# or set GEMINI_API_KEY / ANTHROPIC_API_KEY / OPENAI_API_KEY as env vars# --- Session init ---
fish-bridge init # create session for current project
fish-bridge init --tool claude # → writes to CLAUDE.md instead
# --- Ingest chat turns ---
fish-bridge ingest --source copilot # auto-discover latest VS Code Copilot session
fish-bridge ingest --source copilot --session <id> # target specific session
fish-bridge ingest --source paste # paste any chat text — opens $EDITOR (universal fallback)
fish-bridge ingest --source file --file export.json # from a saved export file
fish-bridge watch --source copilot # tail JSONL, auto-update on new turns
# --- Merge external knowledge ---
fish-bridge merge --source document --file HANDOVER.md
fish-bridge merge --source codebase --path ./ # git log + README
fish-bridge merge --source obsidian --vault ~/notes
fish-bridge merge --source deps --path ./ # package.json / pyproject.toml etc.
fish-bridge merge --source testout --file results.json # jest / pytest / JUnit
fish-bridge merge --source iac --path ./ # Terraform / CDK / CloudFormation
fish-bridge merge --source openapi --file openapi.yaml
fish-bridge merge --source session --file prior.chatgraph.json
# --- Compile & view ---
fish-bridge compile # update instruction file (runs after ingest by default)
fish-bridge compile --mode digest # full handover markdown
fish-bridge compile --mode focus --query "Redis caching"
fish-bridge show # pretty-print active nodes
fish-bridge show --all # include resolved/deferred items
fish-bridge serve # open Cytoscape.js graph viewer at localhost:8080
fish-bridge digest # generate handover digest
# --- Node management ---
fish-bridge resolve "DNC caching strategy"
fish-bridge defer "v16 index validation"
fish-bridge add "Use Redis for session cache" --type decision
fish-bridge conflict show
fish-bridge conflict resolve <node-id> --keep old
# --- Export / import / diff ---
fish-bridge export # save .chatgraph.json
fish-bridge import prior-session.chatgraph.json
fish-bridge diff session-a.chatgraph.json session-b.chatgraph.json
# --- Config ---
fish-bridge config --show
fish-bridge config --backend geminiThe MCP server adds real-time record_turn capture when using VS Code agent mode. It is not required — the file-based workflow above works in all modes without it.
Add to .vscode/mcp.json (uses uvx — no prior install needed):
{
"servers": {
"fish-bridge": {
"command": "uvx",
"args": ["fish-bridge-mcp"],
"env": { "FISH_BRIDGE_BACKEND": "gemini", "GEMINI_API_KEY": "${env:GEMINI_API_KEY}" }
}
}
}If you used uv tool install fish-bridge-mcp, you can also reference the installed binary directly:
{ "command": "fish-bridge-mcp" }See examples/ for Claude Desktop, Cursor, and Windsurf configs.
MCP tools: record_turn, get_context, get_focus, mark_resolved, add_node, export_session, import_session, show_active, list_deferred
Source | Command | What it ingests |
Copilot |
| VS Code Copilot JSONL transcript (auto-discovered) |
Paste |
| Any chat text — universal fallback |
Document |
| Markdown, JSON, YAML specs and ADRs |
Codebase |
| Git commits + README + HANDOVER |
Obsidian |
| Vault notes with wikilinks and frontmatter |
Session |
| Prior |
Deps |
| package.json, pyproject.toml, Cargo.toml, go.mod, Gemfile, pom.xml |
Test output |
| Jest JSON, pytest JSON, JUnit XML — error nodes per failing test |
IaC |
| Terraform, CDK (synth output), CloudFormation, docker-compose |
OpenAPI |
| OpenAPI 3.x / Swagger 2.0 / AsyncAPI specs |
Ingest — reads raw chat turns from JSONL (Copilot), paste, or any file format
Extract — LLM extracts typed nodes (questions, decisions, errors, tasks, skills, files) and edges
Dedup — semantic similarity merges near-duplicates; conflict detection flags status reversals
Compile — graph is compressed to ~300–800 token XML/markdown block
Write — block is written to .github/copilot-instructions.md (or CLAUDE.md)
Deliver — AI tool reads the file automatically on the next turn — no injection, no agent required
MIT — see LICENSE
Manually add a node to the session graph.
Args: label: Short descriptive label (≤8 words). node_type: One of: question | decision | concept | skill | file | error | task summary: Optional 1-2 sentence description. status: Optional status (default depends on type).
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | ||
| node_type | No | task | |
| summary | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks behavioral details beyond the action itself. No mention of side effects, prerequisites, or what happens after adding (e.g., return value). Annotations are absent, so description carries full burden but does not disclose mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise with a structured Args list. Each sentence adds value, though the Args section could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Presence of an output schema reduces need to describe return values, but the description does not mention what the tool returns or any configuration requirements. Missing context for a creation tool without annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description compensates with useful details: label length constraint, node_type allowed values, summary and status optionality. Adds meaning beyond the raw schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (add) and resource (node to session graph). Differentiates from sibling tools like export_session, record_turn, etc., as the only tool explicitly adding nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites or contexts where manual addition is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full session graph as a JSON string.
Useful for saving a portable snapshot or importing into another session.
The JSON can be saved as a .chatgraph.json file and imported with
fish-bridge import <file>.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It mentions the output format (JSON string) and file extension (.chatgraph.json), but does not specify side effects, size limits, or performance implications. Since exporting is typically safe, the disclosure is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences. The first sentence directly states the purpose. The remaining two provide context on usage without waste. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately explains the return value (JSON string of full session graph) and how to use the output (save as .chatgraph.json, import later). This is sufficient for a simple export function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema description coverage is 100%. The description does not need to explain parameters. It adds value by describing the output format, earning a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'the full session graph as a JSON string'. The verb 'export' is implied by the name, and the resource is the session graph. It distinctly separates from the sibling 'import_session' by nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains it is 'useful for saving a portable snapshot or importing into another session', providing clear use cases. It indirectly contrasts with import_session by mentioning import as a separate step, but it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current compressed session context as XML.
This is the same content written to .github/copilot-instructions.md. Use this when you need to recall the session state mid-conversation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description effectively discloses the behavior: returns compressed XML, same as file content. No hidden side effects or surprises; transparency is high enough for a stateless read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description, front-loaded with purpose and immediate usage guidance. Every word contributes, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description fully covers what the agent needs: purpose, usage context, and output nature. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description adds value by describing the output format and its source, aiding understanding beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns the current compressed session context as XML, specifying both the verb (Return) and resource (session context). It also notes equivalence to .github/copilot-instructions.md, aiding identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when you need to recall the session state mid-conversation.' While no alternatives or exclusions are given, the context is clear for a simple read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a query-scoped subgraph context XML.
Finds the nodes most relevant to query and their graph neighborhood. Use this for targeted technical questions where full session context is too broad.
Args: query: Natural language question or topic (e.g. "CORS headers configuration")
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the output is XML but does not detail performance, side effects, or read-only nature. For a simple retrieval tool, the description is minimally adequate but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded purpose statement and a separate usage line. The Args section is somewhat redundant with the schema but not overly verbose. It efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required string parameter) and the existence of an output schema, the description sufficiently covers purpose, usage context, and parameter guidance. It could mention session scope or limitations, but overall it is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds meaning by explaining the 'query' parameter as 'Natural language question or topic (e.g. 'CORS headers configuration')'. This clarifies format beyond the type string, though more examples would help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return a query-scoped subgraph context XML,' which specifies the verb, resource, and output format. It distinguishes from siblings like 'get_context' by noting this is for targeted questions where full context is too broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for targeted technical questions where full session context is too broad,' providing clear guidance on when to use. It implicitly contrasts with siblings that provide broader context, though it does not list explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a prior session graph and merge it into the current session.
Pass the JSON content of a .chatgraph.json file (from export_session or
fish-bridge export). Deferred nodes from the prior session become active;
resolved and adopted decisions carry forward.
Returns a summary of how many nodes and edges were merged.
| Name | Required | Description | Default |
|---|---|---|---|
| json_str | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that deferred nodes become active, resolved and adopted decisions carry forward, and it returns a summary. It does not describe potential merge conflicts or side effects, but the merge semantics are reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place. The first sentence states the purpose, the second gives input details, and the third describes the output. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (though not shown), the description covers the input format, the merging behavior, and the return value. It is complete for a simple import operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'json_str' with no description (0% coverage). The description adds essential meaning by stating it expects the 'JSON content of a .chatgraph.json file', which compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Load a prior session graph and merge it into the current session.' It explicitly states what the tool does and distinguishes it from sibling tools like export_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies the source of the input ('JSON content of a .chatgraph.json file from export_session or fish-bridge export'), providing clear context. However, it does not explicitly state when not to use it or mention alternatives, though export_session is implied as the counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all deferred items in the current session as plain text.
Shows questions, tasks, decisions, and errors that have been parked.
Use mark_resolved or fish-bridge resolve to act on them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the output format ('as plain text') and types of items, but lacks explicit safety information (e.g., read-only, non-destructive). It is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action, and contains no extraneous information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and an output schema (inferred), the description is fairly complete: it explains what is returned, the types, and suggests next steps. However, it lacks details on ordering or limits, which are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so no parameter descriptions are needed. The description adds no parameter info, but since schema coverage is 100% (none to cover), a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'return', resource 'deferred items', and scope 'in the current session'. It distinguishes from sibling tools like 'show_active' and 'mark_resolved'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent what the tool does and suggests using 'mark_resolved' or 'fish-bridge resolve' to act on the items. It implicitly provides usage context but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a question, task, or error as resolved.
Args: label: The label of the node to resolve (partial match, case-insensitive). note: Optional note explaining how it was resolved.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | ||
| note | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but does not disclose behavioral traits such as side effects, permissions, or state changes beyond 'mark resolved'. This is insufficient for an agent to understand consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and parameter list, front-loading the purpose. Every part is necessary and free of extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool with two parameters, but lacks details on state changes, reversibility, or success indicators. With no annotations and a present output schema, some behavioral context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description adds meaningful details: label supports partial match and case-insensitive, note clarifies its purpose. This significantly enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool marks a question, task, or error as resolved, specifying the verb and resource. However, it does not explicitly distinguish itself from sibling tools, though siblings are not directly related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or when not to use it. The description only explains the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ingest one user/assistant exchange into the session graph.
Call this after each response in agent mode. The graph is updated incrementally — no full re-extraction required.
Returns a brief acknowledgement with node/edge counts.
| Name | Required | Description | Default |
|---|---|---|---|
| user_message | Yes | ||
| assistant_message | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions incremental update and return of node/edge counts, but lacks details on side effects, idempotency, or error conditions. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with action and context, no redundant words. Efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With simple parameters and no output schema, the description adequately covers return format and usage context. However, missing details on error states and rate limits prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 required string parameters (user_message, assistant_message) with 0% description coverage. The description adds no additional meaning beyond the parameter titles, failing to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ingests a user/assistant exchange into the session graph. It uses specific verb 'Ingest' and resource 'session graph', and its purpose (recording a turn) is distinct from siblings like add_node or export_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Call this after each response in agent mode,' providing clear context of use. It also notes incremental updates avoid full re-extraction. However, it does not explicitly exclude alternative tools or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the active session thread as plain text (not XML).
Lists open questions, pending tasks, active errors, and key decisions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses output format (plain text, not XML) and content areas. However, it does not mention read-only nature or error conditions, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and immediately list contents. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with an output schema, the description adequately explains what is returned. It could mention prerequisites (e.g., requires an active session) but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description adds value by explaining the output contents. Baseline is 4 due to no parameters needing documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the active session thread as plain text, listing specific contents (open questions, pending tasks, active errors, key decisions). This distinguishes it from sibling tools like add_node or export_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to get the current session state, but does not explicitly state when to use it versus alternatives, nor does it provide any usage restrictions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct purpose within session graph management: adding nodes, exporting/importing, retrieving context, focusing on subgraphs, listing deferred items, marking resolved, recording turns, and showing active thread. No two tools overlap in function.
All 9 tools follow a consistent verb_noun pattern (e.g., add_node, export_session, get_context, list_deferred), using lowercase with underscores. No deviations or mixed conventions.
With 9 tools, the server is well-scoped for session graph management. Each tool addresses a core operation (add, retrieve, list, resolve, import/export, record), without unnecessary bloat or deficiency.
The tool set covers the main lifecycle: adding nodes, resolving them, recording turns, listing deferred items, and exporting/importing sessions. Minor gaps exist (e.g., no explicit update or delete node tool), but the core workflows are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
Hosted MCP memory: save sessions/decisions once, search from Claude, Cursor, ChatGPT. EU-hosted FTS.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MakeaMouse/fish-bridge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
