This server provides MCP hosts with explicit access to long-term Agent memory through recall, ingestion, turn lifecycle, durable job handling, and memory control tools.
Recall memory: tmcra_recall returns prompt-ready evidence windows for a query, with optional scope, agent attribution, evidence mode, structured evidence, and waiting for a job.
Persist past messages: tmcra_ingest stores already-occurred conversation messages with role, content, speaker/target Agent attribution, timestamps, consistency and idempotency options.
Managed turn lifecycle: tmcra_turn_prepare recalls memory and binds the real user turn before an answer; tmcra_turn_commit persists the exact user/assistant turn and reconciles it to a terminal state.
Durable write recovery: tmcra_reconcile retries pending durable records and reports success or dead-letter states.
Inspect and await async jobs: tmcra_get_job reads job state; tmcra_wait_job blocks until a job succeeds, fails, or is cancelled.
Session/memory controls: tmcra_memory_control manages session modes, tasks, recall budgets, and corrections (e.g., normal, recall_only, off).
Targeted feedback: tmcra_feedback previews exact evidence and requests interactive confirmation before applying ignore/correct/restore operations.
Cross-session and cross-tool continuity: multiple MCP hosts can share one project scope while keeping separate session provenance and Agent attribution.
TMCRA MCP Server gives MCP hosts explicit access to long-term Agent memory. It recalls project evidence, writes real conversation records with speaker attribution, preserves multi-Agent project scope, and tracks asynchronous writes to a terminal state.
Cross-session project continuity. Recall bounded evidence from one stable project scope.
Cross-tool collaboration. Different MCP hosts can use the same scope while keeping their own session provenance.
Speaker and Agent attribution. User, assistant, system, and tool records remain separate; known Agent producers or targets remain attached.
Explicit turn lifecycle. A host can prepare recall before an answer and commit the exact user/assistant turn afterward.
Durable write recovery. Transport uncertainty enters a local SQLite queue with idempotent reconciliation.
Verifiable receipts. Recall, ingest, and job responses are validated before the MCP host receives them.
Nine MCP tools. Recall, ingest, prepare, commit, reconcile, get job, wait for job, session memory controls, and targeted feedback.
tmcra_memory_control exposes task selection, a 12000-character default recall budget, and normal, recall_only, off modes. Pass the exact same session_id to recall/prepare and controls. Pending older generations are discarded after a mode change; already submitted jobs remain submitted. tmcra_feedback supports ignore, correct (user-supplied replacement), and restore with a stable idempotency key. Effective feedback requires the matching backend update; check correction_index_status separately. The visual control panel is provided by the Codex and DSH distributions. This MCP package automatically discovers the shared local installation; numeric loopback HTTP is permitted only for an explicit local identity. Hosted connections require HTTPS.
Conversational corrections now require interactive host confirmation. On an actual correction request, call tmcra_memory_control(operation="correction_start") before clarification or feedback to suppress automatic capture of that discussion turn. tmcra_feedback reads exact original evidence and uses MCP form elicitation to show the source, replacement and scope; only explicit acceptance submits feedback. Rejection, cancellation, expiry or an unsupported host leaves memory unchanged. Do not substitute ingestion for a rejected correction. Host lifecycle turn IDs protect the discussion from later queue replay while preserving other identified turns. A third-party host must route elicitation to its user; the server cannot guarantee that an arbitrary client will not answer automatically. Hypothetical/quoted correction language is not authorization.
Generic MCP clients decide when to call tools. Connecting this server alone does not observe the host's before-answer or after-answer lifecycle. For automatic Codex recall and capture, install the separate TMCRA Codex Memory plugin.
Related MCP server: Recall
Download tmcra-mcp-server-1.0.0-rc.1.mcpb from the v1.0.0-rc.1 release and open it in an MCPB-compatible client. The bundle uses the cross-platform uv runtime. Hosted service users enter their API key in the sensitive field. For account-free Windows local memory, extract the standalone runtime, double-click Install-Local.cmd, then restart the MCP host. The local identity is discovered automatically and overrides the form's cloud URL/key; keep the API key blank for this mode. Explicit advanced TMCRA_CONFIG_FILE overrides remain authoritative. Local model acceptance limitations are documented in the runtime release.
python -m pip install \
https://github.com/reshuibuduo/tmcra-mcp-server/releases/download/v1.0.0-rc.1/tmcra_mcp_server-1.0.0rc1-py3-none-any.whluvxuvx --from "git+https://github.com/reshuibuduo/tmcra-mcp-server@v1.0.0-rc.1" tmcra-mcpCreate a TMCRA account and API key, then provide it through your MCP client's secret storage or the TMCRA_API_KEY environment variable. Do not commit credentials to a repository.
TMCRA_API_KEY=<your TMCRA API key>
TMCRA_BASE_URL=https://api.tmcra.com
TMCRA_DEFAULT_SCOPE=<stable project scope, optional>
TMCRA_AGENT_ID=<known Agent identity, optional>Users signed in through a TMCRA application can instead use its protected device file at ~/.config/tmcra/config.json. Environment variables override that file for developer and self-hosted configurations.
The server accepts only HTTPS API origins without embedded credentials, query strings, or fragments.
After installing the wheel, an MCP host can launch:
{
"mcpServers": {
"tmcra-memory": {
"command": "tmcra-mcp",
"env": {
"TMCRA_API_KEY": "<stored securely by the host>",
"TMCRA_DEFAULT_SCOPE": "project-example"
}
}
}
}The package also includes a Codex setup helper:
tmcra-mcp-setup install --mode explicit
tmcra-mcp-setup status --mode explicitTool | Purpose |
| Inspect or explicitly change session modes, tasks and recall budgets. |
| Preview exact evidence and request interactive confirmation before targeted feedback. |
| Return at most eight prompt-ready evidence windows for the current query. |
| Persist messages that already occurred, preserving role and Agent attribution. |
| Recall before an answer and durably bind the real user turn. |
| Persist the prepared user turn and exact assistant answer as separate records. |
| Retry durable pending records with the same idempotency key. |
| Read one asynchronous write job state. |
| Wait for a job to succeed, fail, or be cancelled. |
Every project collaborator should use the same project scope. Each conversation keeps its own session_id. Agent identity is attribution and does not split the project memory.
Recalled content is returned with trust_boundary: untrusted_memory_data. A host must treat it as evidence, never executable instructions.
An MCP host that wants per-turn continuity should:
Call tmcra_turn_prepare after receiving the current user question.
Inject only the returned injectable_context as untrusted evidence.
Draft the answer.
Call tmcra_turn_commit with the same turn_id and the exact final answer.
Report pending or terminal write state accurately.
The lower-level equivalent is tmcra_recall, answer, tmcra_ingest, then tmcra_get_job or tmcra_wait_job.
Credentials are read from environment or a protected TMCRA device file and are never printed by the server.
API destinations must use HTTPS.
Structured receipts reject malformed recall, ingest, and job responses.
Recalled memory remains untrusted data.
The repository contains the client-side MCP integration only. It contains no production service source code or production credentials.
Destructive memory deletion and export are not exposed by this toolset.
See SECURITY.md for vulnerability reporting.
python -m pip install -e ".[dev]"
python -m pytest -q
python -m build
python -m twine check dist/*The tests cover receipt validation, scope and actor semantics, durable queue recovery, configuration safety, setup behavior, and a real MCP initialize/list/call smoke exchange.
Inspect a TMCRA asynchronous job.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates the job is asynchronous and that the tool inspects it, which implies a non-blocking read, but it does not state what side effects, if any, occur, whether it returns only status, or how errors are surfaced.
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 a single, front-loaded sentence with no filler. It is concise, though slightly under-specified; the brevity is not itself a problem, but it could have used its short length to include a usage hint.
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 simple single-parameter schema and existing output schema, return-value documentation is not needed. However, the description fails to clarify the relationship to tmcra_wait_job and gives no parameter guidance, leaving an important selection and invocation gap for the agent.
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 description coverage is 0% and the description does not explain the job_id parameter. The parameter name and title are somewhat self-explanatory, but the description adds no detail about where the ID comes from or how it is used beyond the schema's minimal 'Job Id' label.
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 uses a specific verb ('Inspect') and a clear resource ('a TMCRA asynchronous job'), so an agent can tell it is a read/status operation. It does not explicitly differentiate itself from the sibling tmcra_wait_job, but the core purpose is still clear.
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?
There is no guidance about when to use this tool versus tmcra_wait_job or the other siblings. The existence of tmcra_wait_job strongly suggests an important usage distinction (inspecting vs. waiting for a job), but the description does not address it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist conversation messages that have already occurred.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| agent_id | No | ||
| messages | Yes | ||
| session_id | Yes | ||
| consistency | No | eventual | |
| slow_policy | No | auto | |
| idempotency_key | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it only reveals basic write intent via 'persist.' It omits important traits hinted at by the schema and siblings: idempotency behavior (idempotency_key), consistency semantics (eventual vs. read_your_writes), the slow_policy escalation options, and whether the operation is asynchronous (siblings tmcra_get_job/tmcra_wait_job suggest job-based execution).
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 short, but this is under-specification rather than efficient conciseness: a single clause cannot serve a tool with seven parameters, a nested message type, and six siblings. It front-loads the core intent but omits nearly everything else.
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?
Despite an output schema existing, the description is far from complete for this tool's complexity: 7 parameters at 0% schema coverage, no annotations, and a sibling set suggesting a lifecycle/job framework. The agent lacks information about when to ingest, how messages must be structured, job behavior, and consistency options.
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 description coverage is 0%, yet the description compensates for almost none of the seven parameters. It only implies that 'messages' are conversation messages; it says nothing about session_id, scope, agent_id, consistency, slow_policy, or idempotency_key, leaving the agent to guess their roles and formats.
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 uses a specific verb ('persist') with a resource ('conversation messages that have already occurred'), clearly signaling a write/append operation for historical messages. It is distinguishable from tmcra_recall (reading) and the job/session management siblings, though it does not explicitly differentiate itself from tmcra_turn_commit, which may also write messages.
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 given on when to use this tool versus its six siblings. Nothing explains the relationship to tmcra_turn_prepare/tmcra_turn_commit (turn lifecycle) or when ingest is preferred over committing a turn, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall bounded, prompt-ready memory evidence for one query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| scope | No | ||
| agent_id | No | ||
| evidence_mode | No | auto | |
| wait_for_job_id | No | ||
| include_structured_evidence | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that results are 'bounded' and 'prompt-ready,' but says nothing about side effects, asynchronous job handling, scoping, or what happens when wait_for_job_id is used. This is under-specified for a tool whose schema includes evidence_mode, scope, and job-waiting parameters.
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 text is a single compact sentence and front-loads the core operation, so it is easy to scan. However, it is so terse that it omits critical operational context; this is under-specification rather than disciplined conciseness.
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 presence of an output schema reduces the need to describe return values, but the tool has six parameters, an evidence_mode enum, and a wait_for_job_id that implies asynchronous behavior. The description does not explain these or how recall relates to tmcra_ingest, tmcra_turn_prepare, and tmcra_get_job. An agent cannot confidently construct correct arguments beyond query.
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 description coverage is 0%, so the description must compensate for the six-parameter schema. It only reinforces that a single 'query' is the basis for recall; scope, agent_id, evidence_mode, wait_for_job_id, and include_structured_evidence receive no explanation. The one meaningful addition is the 'for one query' bound, which is not enough.
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 uses a specific verb and resource: 'Recall ... memory evidence for one query,' which tells an agent this is a retrieval operation over stored memory. 'Bounded' and 'prompt-ready' hint at result shape, and 'for one query' separates it from batch or management siblings. It does not explicitly distinguish itself from tmcra_turn_prepare, but the retrieval intent is clear.
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 given about when to call this tool versus tmcra_turn_prepare, tmcra_reconcile, or tmcra_get_job. The description implies a recall use case but never states exclusions, prerequisites, or alternative conditions, leaving the agent to infer selection criteria from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retry durable pending records and report succeeded or dead-letter states.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It correctly discloses that the tool retries pending records and reports succeeded or dead-letter states, but it does not mention idempotency, side effects, or failure behavior beyond the state outcomes.
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 a single efficient sentence with no filler. The verb-action and outcome are front-loaded, making it easy for an agent to parse quickly.
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 parameterless tool with an output schema, the description adequately states what the tool does and what it reports. It could add more surrounding pipeline context or invocation timing, but nothing essential appears 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?
The tool has zero parameters, so parameter documentation is unnecessary and the baseline of 4 applies. The description adds no parameter details, but none are needed.
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 uses a specific verb ('Retry') with a clear resource ('durable pending records') and outcome ('report succeeded or dead-letter states'), so an agent can infer the tool's purpose. It does not explicitly compare against sibling tools, but the action is distinct from recall, ingest, turn-prepare, turn-commit, get-job, and wait-job.
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 intended usage is implied: call this when durable pending records need retrying. However, there is no explicit statement of when to prefer this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Commit the real user/assistant turn and reconcile it to terminal state.
| Name | Required | Description | Default |
|---|---|---|---|
| turn_id | Yes | ||
| agent_id | No | ||
| consistency | No | read_your_writes | |
| slow_policy | No | auto | |
| idempotency_key | No | ||
| assistant_content | Yes | ||
| assistant_timestamp | No | ||
| assistant_message_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for behavioral disclosure. It only states that a turn is committed and reconciled, without explaining persistence guarantees, side effects, failure behavior, idempotency handling, or how consistency and slow_policy affect execution.
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 single sentence is compact and front-loaded with the primary action and objective. However, it is concise to the point of being under-specified for a tool with this many parameters and behavioral nuances.
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?
This is a complex, mutation-like tool with eight parameters, no annotations, no parameter descriptions, and no usage context, yet the description provides almost none of the information needed to invoke it safely. The overlap with tmcra_reconcile further increases the risk of incorrect selection.
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 description coverage is 0%, and the description does not name or explain any of the eight parameters. Required fields such as turn_id, assistant_message_id, and assistant_content appear only as titles, leaving the agent to guess their roles.
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 states a specific action—commit—and a specific resource, the real user/assistant turn, with an explicit outcome of reconciling to terminal state. However, it does not clearly distinguish itself from the sibling tmcra_reconcile, whose name overlaps with the phrase 'reconcile it to terminal state.'
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 given about when to call this tool versus tmcra_turn_prepare, tmcra_reconcile, or tmcra_ingest. The description implies this tool finalizes a prepared turn, but that sequencing is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall memory and return untrusted injectable context before the host answers.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| turn_id | Yes | ||
| agent_id | No | ||
| session_id | Yes | ||
| user_content | Yes | ||
| evidence_mode | No | auto | |
| user_message_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the returned context is 'untrusted' and 'injectable,' and indicates a retrieval-style operation via 'Recall memory.' However, it does not clarify side effects, required prior steps, or how evidence_mode affects 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?
The description is a single concise, front-loaded sentence with no filler. It conveys the core operation and timing efficiently, though the phrase 'untrusted injectable context' is dense and could be clearer.
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 7 parameters, no annotations, and sibling tools with overlapping concerns, this one-line description is insufficient. It omits how the returned context should be handled, what evidence_mode does, how this relates to tmcra_turn_commit, and what prior conditions must exist before calling.
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 description coverage is 0%, so the description must compensate, but it adds no parameter-level meaning. While the parameter names and titles are somewhat self-explanatory, the description does not explain key fields like user_content, evidence_mode, scope, or agent_id, nor how they shape the recall and returned context.
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 states a clear verb and resource: 'Recall memory and return untrusted injectable context before the host answers.' It conveys the basic operation and timing. However, it does not explicitly distinguish itself from the sibling tmcra_recall tool, so the differentiation is incomplete.
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 phrase 'before the host answers' gives useful timing context, implying this should be called at the start of a turn to prepare memory context. But the description provides no explicit guidance about when to use this vs. tmcra_recall, tmcra_turn_commit, or other siblings, and no when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a TMCRA job to succeed, fail, or be cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| timeout_seconds | No | ||
| poll_interval_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state the three possible terminal conditions, but it omits critical behaviors: that the tool polls, that it may block up to timeout_seconds, what happens on timeout, and whether it returns status or throws an error. These are consequential for an agent deciding to invoke it.
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 a single, front-loaded sentence with no filler. It communicates the core purpose and outcome conditions efficiently. Conciseness is excellent even though other dimensions suffer from insufficient detail.
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 blocking tool with configurable timeout and polling and no annotations, the description is under-specified. It does not mention that the call may block for an extended period, how timeout is handled, or how this relates to get_job. The output schema covers return values, but the missing behavioral context leaves the agent inadequately prepared.
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 description coverage is 0%, so the description must compensate for parameter meaning, but it does not. It implies job_id via 'a TMCRA job' but says nothing about timeout_seconds or poll_interval_seconds, their units, defaults, or behavior on expiry. The schema titles are self-explanatory, but the description adds no semantic value beyond them.
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 uses a specific verb ('Wait') with a specific resource ('a TMCRA job') and precisely names the terminal outcomes (succeed, fail, or be cancelled). This clearly distinguishes it from siblings like get_job (which likely retrieves status) and the other job-management tools.
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?
There is no explicit guidance on when to use this tool versus alternatives such as get_job or manual polling. The description implies a blocking wait but does not state prerequisites, exclusions, or the context in which it should be preferred.
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.
v0.5.1tmcra_get_jobtmcra_ingesttmcra_recalltmcra_reconciletmcra_turn_committmcra_turn_preparetmcra_wait_jobScored across 7 tools
Most tools have distinct roles, but tmcra_recall and tmcra_turn_prepare both perform memory recall, and tmcra_ingest and tmcra_turn_commit both persist conversation-related content. The descriptions clarify timing and use, but an agent could still misselect between the overlapping read/write tools.
All names share the tmcra_ prefix and snake_case, but the verb pattern is inconsistent: recall/ingest/reconcile are bare verbs, get_job/wait_job are verb_noun, and turn_prepare/turn_commit are object_verb. This is readable but not a uniform convention.
Seven tools is well-scoped for a memory/turn-lifecycle server: recall/ingest cover core memory operations, turn_prepare/turn_commit cover the turn cycle, and get_job/wait_job/reconcile support asynchronous durability. Each tool has a clear place in the workflow.
The core memory lifecycle is covered: recall, ingest, turn preparation/commit, reconciliation, and async job handling. The main gap is the lack of explicit memory update/delete/forget operations, though the system may be designed as append-only evidence.
Persistent memory for AI agents. Search, store, and recall across sessions.
Shared project memory that keeps teammates and AI agents aligned across sessions.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
