M3 Memory

Overview Schema Source Related Servers Discussions Admin

m3_call

Invoke any M3 catalog tool by name without loading its domain, including tools not loaded at startup. Run single calls or isolated batches, with dry-run validation before execution.

Instructions

Invoke ANY m3 catalog tool by name without loading its domain — the low-token path to the full tool surface, and the way to reach every tool not loaded at startup. Single call: pass tool (e.g. 'files_stats') and args (an object). Batch: pass batch, a list of {tool, args} (each isolated — one failure won't abort the rest; capped at 100). Set dry_run to validate args + check the destructive gate WITHOUT executing. Returns JSON. Call m3_index first if you don't know a tool's args. Destructive tools are refused unless mcp.allow_destructive is enabled (m3 config set mcp.allow_destructive true).

Input Schema

Name	Required	Description
`args`	No	Arguments object for the target tool.
`tool`	No	Catalog tool name (see m3_index).
`batch`	No	List of {tool, args} for one-round-trip batch dispatch.
`store`	No	Named store for this call only: main, or a [stores.<name>] in m3_config.toml.
`dry_run`	No	Validate + gate-check only; do not execute.
`timeout`	No	Per-call timeout in seconds; <=0 disables.
`database`	No	SQLite file for this call only (legacy; prefer store). SQLite backend only.

Schema Changelog

Changes observed during successful MCP inspections.

Changed19 schema fields changedv0.1.21Oct 22, 2026
- removedInput schema / properties / args / additionalProperties
```
Removed value: -true
```
- addedInput schema / properties / args / description
```
Added value: +"Arguments object for the target tool."
```
- removedInput schema / properties / args / title
```
Removed value: -"Args"
```
- addedInput schema / properties / batch / description
```
Added value: +"List of {tool, args} for one-round-trip batch dispatch."
```
- removedInput schema / properties / batch / items
```
Removed value: -{}
```
- removedInput schema / properties / batch / title
```
Removed value: -"Batch"
```
- removedInput schema / properties / database / default
```
Removed value: -""
```
- addedInput schema / properties / database / description
```
Added value: +"SQLite file for this call only (legacy; prefer store). SQLite backend only."
```
- removedInput schema / properties / database / title
```
Removed value: -"Database"
```
- addedInput schema / properties / dry_run / description
```
Added value: +"Validate + gate-check only; do not execute."
```
- removedInput schema / properties / dry_run / title
```
Removed value: -"Dry Run"
```
- addedInput schema / properties / store
```
Added value: +{
+  "description": "Named store for this call only: main, or a [stores.<name>] in m3_config.toml.",
+  "type": "string"
+}
```
- removedInput schema / properties / timeout / default
```
Removed value: -30
```
- addedInput schema / properties / timeout / description
```
Added value: +"Per-call timeout in seconds; <=0 disables."
```
- removedInput schema / properties / timeout / title
```
Removed value: -"Timeout"
```
- addedInput schema / properties / tool / description
```
Added value: +"Catalog tool name (see m3_index)."
```
- removedInput schema / properties / tool / title
```
Removed value: -"Tool"
```
- addedInput schema / required
```
Added value: +[]
```
- removedInput schema / title
```
Removed value: -"m3_callArguments"
```
Addedv0.1.9Jul 28, 2026
Removedv0.1.6Jul 26, 2026
Changed1 schema field changedv0.1.2Jul 6, 2026
- addedInput schema / properties / timeout
```
Added value: +{
+  "default": 30,
+  "title": "Timeout",
+  "type": "number"
+}
```
First observedv0.1.0Jun 28, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations: batch items are isolated so one failure won't abort the rest, batches are capped at 100, dry_run validates args and checks the destructive gate without executing, and the destructive-refusal policy is spelled out with the enabling command. This is rich operational context the structured fields do not convey.

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?

Front-loads the core purpose and the single-call path before batch and dry_run details, with no filler sentences. It is dense with parenthetical asides, but each clause carries actionable information.

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 7-param dispatcher with nested objects, the description covers the dispatch model, batch isolation, dry_run, and the destructive gate, and defers arg discovery to m3_index. No output schema exists, but 'Returns JSON' plus the schema's own parameter docs make this nearly complete; only store/timeout/database behavior is left to the schema.

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 coverage is 100%, so the baseline is 3; the description adds value by showing the tool/args pairing (e.g. 'files_stats') and the {tool, args} shape for batch, plus the exact meaning of dry_run. It does not explain `store`, `timeout`, or `database`, but the schema documents those adequately.

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 a specific verb and resource: 'Invoke ANY m3 catalog tool by name', plus the distinct value proposition ('low-token path to the full tool surface', 'reach every tool not loaded at startup'). An agent can immediately tell this is a meta-dispatcher distinct from concrete siblings like memory_write or chatlog_search.

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 routes the agent: 'Call m3_index first if you don't know a tool's args', and defines when to set dry_run versus execute. It also states the prerequisite for destructive tools ('refused unless mcp.allow_destructive is enabled') with the exact config command, leaving little to inference.

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

Deploy Server

m3_call

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools