Shared memory for client engagements: decisions with reasons, blockers, promises, what was tried.
Scored across 2 tools
get_brief is explicitly a curated status snapshot (blockers, asks, decisions, tried/dropped), while search_memory is source-grounded recall over recorded meetings and agents. The two tools complement each other rather than overlap, and the instruction to call get_brief first removes ambiguity.
Both tools follow a clean verb_noun snake_case pattern: get_brief and search_memory. The naming is consistent, predictable, and accurately reflects each tool's action.
Two tools is on the thin side, but each serves a distinct and coherent retrieval purpose. It is borderline rather than clearly insufficient for a narrow context-retrieval server.
The pair covers the core read-only workflow well: get_brief provides the current engagement state and search_memory provides historical recall. The set is entirely read-only, with no way to persist or update briefs or memories, which is a minor gap if write access is expected.
Where an engagement stands: what is blocking it, what you owe and by when, the decisions in force and why, what the client has asked for, and what was already tried and dropped. Call it FIRST, before planning or changing anything — it is the cheapest way to avoid re-deciding something settled or contradicting a call you were not on. Called with no project, it lists the ones this user has.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | The output of `git remote get-url origin`. Kika resolves the engagement from it, so you never have to ask which project this is. Pass it whenever you are in a repo. | |
| project | No | Project name or handle, if you already know it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It specifies the content of the brief (blockers, obligations, decisions, client asks, dropped attempts) and the fallback behavior when called without a project. While it doesn't explicitly state the tool is read-only, the phrasing 'Call it FIRST' and the absence of any mutating language strongly imply a non-destructive retrieval, which is adequate given the 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 well-structured, leading with the core value proposition (what the brief contains) and then the crucial usage directive. It is a bit long (three sentences) but each sentence packs substantive information. The front-loading of the content list and the imperative 'Call it FIRST' makes it efficient and scannable, though it could be tightened slightly without losing meaning.
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?
Since there is no output schema, the description must convey what the agent will receive. It enumerates the brief's contents (blockers, obligations, decisions, client asks, tried/dropped items) and explains the no-project fallback. This is sufficient for an agent to know what to expect and when to use it. It does not describe the exact data structure or fields, but the semantic list is adequate for correct invocation and interpretation.
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 already provides descriptions for both parameters with 100% coverage, so the baseline is 3. The description adds value by explaining that the 'repo' parameter is used by Kika to resolve the engagement automatically, and that calling with no project lists the user's projects. This clarifies the optionality and the resolution mechanism beyond the schema alone, justifying a 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 what the tool returns: a snapshot of an engagement's status including blockers, obligations, decisions, client requests, and previously tried approaches. It names the resource ('engagement') and the action (retrieve brief), and the emphasis on 'Call it FIRST' establishes its role as a foundational lookup distinct from any modification tool.
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 instructs to call this tool first, before planning or changing anything, and explains the benefit: avoiding re-deciding settled matters or contradicting prior calls. It also covers the no-argument behavior (lists the user's projects), giving clear guidance on when and how to invoke it. It does not mention the sibling tool search_memory, but the usage context is so specific that an agent knows exactly when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search what this user’s meetings and agents recorded. Pass entity whenever the question names a project, person or company — it anchors the search to that thing rather than to wording, which is more accurate and lets the answer be traced to a source. Call it more than once, broad then narrow.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 8. | |
| query | Yes | What to look for. | |
| types | No | Restrict to these kinds. ["Decision"] for "what did we decide and why". | |
| entity | No | The project, person or company it is about. Slugs and paths are fine. | |
| project | No | Search inside one engagement. Handle or name, from get_brief. | |
| include_history | No | Include what was true once and is not now. Set it for "what did we originally plan", or before proposing an approach that may already have been rejected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses meaningful behavior: entity anchoring rather than literal wording, and source-traceable answers. It does not mention read-only or rate limits, but search semantics make the main behavior sufficiently 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?
Three sentences with no filler. The core purpose is front-loaded, followed by a targeted parameter heuristic and a multi-call strategy. Every sentence earns its place.
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 6-parameter search tool with no output schema and full schema coverage, the description is adequate: it identifies data sources, gives a key usage heuristic, and lets the well-described schema handle parameter specifics. It could mention the get_brief relationship, but this is not essential.
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 coverage is 100%, so the baseline is 3. The description adds real value for the entity parameter by explaining why it improves accuracy and traceability beyond the schema's 'project, person or company' wording. Other parameters are left to the schema, which is acceptable.
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?
States a specific verb ('Search') and resource ('what this user’s meetings and agents recorded'), making the scope clear. It does not explicitly contrast with get_brief, but the target data is described concretely enough to avoid confusion.
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?
Gives explicit tactical guidance: pass entity when the question names a project/person/company and call more than once broad then narrow. It lacks an explicit when-not-to-use statement or sibling comparison, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_briefsearch_memoryGoverned company memory: search decisions, rules and client facts; propose updates for review.
Per-client shared AI memory: approved notes that Claude, ChatGPT and Cursor read over MCP.
Shared project memory that keeps teammates and AI agents aligned across sessions.
Shared memory for a team in Claude Code: what one person records, everyone has.
Add one secure layer between your agents and this server.
