This server is a deterministic, evidence-verifying memory substrate for agents: it stores only supported claims, answers with abstentions instead of guesses, and provides receipts, verification, and erasure proof.
remember — commit a fact only if the cited evidence supports it; unsupported claims are refused with typed, actionable reasons.
add_source — register source documents so claims bind to verifiable byte ranges and receipts.
recall — search memory; returns grounded claims with byte ranges, or abstains and names the term it could not ground.
verify_receipts — re-hash sources and re-check every stored range, making tampering detectable.
forget — erase everything about a subject and issue a signed certificate showing closure, abstention from probes, and surviving bystanders.
export_memory — dump the entire substrate as a portable open-format blob readable without this server or any model.
memory_stats — inspect substrate size, entities, held sources, and operational mode.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fireweed-mcp recall what we know about Priya"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Agent memory where every fact carries a receipt.
remember(claim = "Priya joined Acme in 2019 under duress.",
evidence = "Priya Raman joined Acme in 2019 as a logistics analyst.")
REFUSED (asserts_more_than_evidence) — the claim adds something the evidence does not say.
claim : Priya joined Acme in 2019 under duress.
evidence: Priya Raman joined Acme in 2019 as a logistics analyst.recall("Priya's salary")
ABSTAINED (unknown_predicate) — no claims ground "salary"; 1 claim about Priya Raman exists
This is a refusal, not an empty result.forget("Priya")
ERASED Priya Raman — certificate issued
signature : hmac-sha256:f4d0768ef3b0fec624afec12f25bfd91…
nodes in closure : 1
every probe abstains : True
bystanders surviving : 1That last one is the artifact behind "delete me from your agent's memory — and prove it."
uvx fireweed-mcp # try it
pip install fireweed-mcp # keep itclaude mcp add fireweed -- uvx fireweed-mcpNo dependencies. No API keys. No model — nothing in this server calls an LLM.
Related MCP server: Nahuali
tool | |
| admits a claim only if the evidence you cite supports it. Refusals are typed and say what to fix. |
| grounded claims with the byte range they came from; abstains and names the term it could not ground |
| re-hash every source, re-slice every range — tamper-evident |
| audit one memory backwards to its evidence's arrival: the bytes it binds, whether they still match, the ledger event that recorded the document, and whether the chain verifies |
| what has been asked of this substrate and what it answered — off by default, and queries are salted fingerprints unless you also opt into recording text |
| erasure with exact closure and a signed certificate; bystanders survive |
| the whole substrate as a portable open-format blob |
Most memory servers store what the model says and return what's nearest. This one adjudicates.
The rule is the model proposes, deterministic code decides. Across an RPC boundary that stops being a slogan: your agent is the proposer, and it cannot talk its way past the gate, because the gate is not a prompt. Pass a claim and the text you're quoting; pure functions check that the evidence names the subject, preserves the relation, invents no numbers, and asserts nothing the span doesn't say. What survives is stored with a byte range into the source.
Then anyone can check it afterwards — including someone who trusts neither your agent nor this server. That is the whole product.
Stated up front, because this project's last headline number turned out to be measuring nothing (see the retraction, which ships with a script that proves it):
The server itself does not extract memories from free text. You supply the claim and the
evidence, and nothing in this server calls a model. Since 0.5.0 an optional companion,
fireweed_extractor, will propose claim/evidence pairs from a transcript using a model you
run — and it is never trusted: every proposal goes through the same four checks a
hand-written one does. Measured across four model families, admitted yield ranged from 0% to
99.3% while every unfaithful proposal was rejected with a typed reason. One 4B model produced
46 pairs its own cited span did not support; all 46 were refused. The failure mode is fewer
memories, never false ones.
It does not make an LLM truthful. It governs what enters the record and what can be proven about it. Your model can still say whatever it likes in its own prose.
Recall is the weak half, and the honest number is far worse than this page used to claim. A previous version of this README said the gate finds a stored fact 98.4% of the time. That figure is withdrawn. It was measured on a corpus whose fourteen question phrasings all have a matching entry in the hand-written category table that answers them — because those entries were derived from that same corpus's failures. It measured the table's coverage of one question set, not the system's recall.
Measured 2026-08-27 against a corpus held out on both axes — unseen personas and, crucially, unseen question phrasings:
asked with… | default install refuses |
the phrasings the table was built from | 4.8% |
phrasings it has never seen | 99.2% |
A default install answers almost nothing phrased in words nobody tuned for. That is the number that describes the system, and it replaces every recall claim this page previously made.
What is genuinely strong is the other axis. On absent-answer traps the gate correctly refuses 96.1% — it is far better at declining than at answering, and it does not fabricate. If you need a memory that never invents, this is that. If you need one that reliably finds things, it is not there yet, and the number above is why.
It does not yet handle multi-subject questions with scope. Questions naming exactly one subject are scoped to that subject; questions naming two or more still match against the whole store.
Numbers come from a calibrated instrument that prints its own controls before measuring. The corpora and method live in the private evaluation repo, so treat these as reported rather than independently checkable — the write path, receipts, provenance and erasure are the parts you can verify yourself with the commands above.
~/.fireweed/mcp/ (FIREWEED_MCP_STORE to change). The substrate is an open format — see
open_format/SPEC.md — and open_format/reference_reader.py reads it with
the standard library alone. Your memory outlives this server, this engine, and any model. A test
asserts that round trip.
Do not install fireweed-mcp[semantic]. It enables paraphrase matching in recall, and
measured against the absent-answer traps it collapses correct refusal from 96.1% to 32.8% — it
answers two thirds of questions whose answer is simply not in the store. A threshold sweep found no
setting where it buys recall without that cost: tightened far enough to be safe, it contributes
nothing at all. It stays installable because the mechanism may be salvageable when scoped to a
subject's own predicates, which is untested. Until then it is off, and memory_stats tells you
which mode you are in.
FSL-1.1-ALv2 — source-available. Free for everything except building a competing product;
converts to Apache 2.0 on 2028-01-01. Full text in LICENSE.md.
Want to use Fireweed in a commercial product or competing service? → sanyamsood2@gmail.com
Register a source document so claims remembered against it bind to verifiable byte ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| origin | No | where these bytes came from (path, URL, endpoint). RECORDED BUT NOT VERIFIED. | |
| source_id | Yes | ||
| origin_kind | No | the kind of origin. Recorded but not verified. | |
| supplied_by | No | who handed these bytes over. Recorded but not verified. | |
| validated_by | No | what checked these bytes before ingest, if anything. Recorded but not verified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that registering a source enables claims to bind to verifiable byte ranges, but it does not explain idempotency, duplicate handling, storage side effects, or what happens to unverified origin metadata.
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 focused sentence with no filler. It front-loads the core action and immediately states the downstream 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 6 parameters, no output schema, and no annotations, more context is needed. The description omits required parameter semantics, return behavior, and lifecycle guidance such as whether re-registering an existing source_id overwrites or errors.
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 67%, and the required params source_id and text have no individual descriptions. The description adds some meaning by identifying a 'source document' and 'byte ranges', which implies text contains the document bytes, but it does not clarify source_id semantics or format.
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 ('Register') and resource ('source document') and explains the purpose: binding claims to verifiable byte ranges. It does not explicitly name sibling tools but the contrast with 'remembered' claims makes its role reasonably distinct.
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 when to use the tool: before claims are remembered, to give them verifiable byte ranges. It does not provide explicit when-not-to-use guidance or compare against alternatives like remember or recall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the whole substrate as a portable open-format blob. Readable without this server, without any model, with a stdlib-only reference reader.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No |
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 the blob is portable and readable without the server or model, which is useful behavioral context. However, it does not mention side effects (e.g., whether the export is read-only), output size, error handling, or any performance implications, leaving gaps for an agent assessing risk or expectations.
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: two short sentences that immediately state the action and the key differentiator (portability and independence). Every word earns its place, and the most important information is front-loaded.
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 tool with one parameter and no output schema, the description is missing critical details: the purpose of 'path' and what the output actually looks like beyond 'portable open-format blob'. It does not explain the return format, size limits, or any requirements for calling it, leaving the agent to guess.
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 defines a single 'path' parameter with no description, and the tool description makes no mention of it at all. With 0% schema description coverage, the description completely fails to clarify what the path parameter means or how to use it, providing no added value beyond the bare 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 states a clear action (export) and resource (the whole substrate) as a portable blob. It is distinct from sibling tools like remember or recall by its export operation, but it does not explicitly name an alternative or contrast it with siblings, so it falls short of a 5.
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 when you need to export the entire substrate, but it gives no explicit guidance about when to use it over alternatives or when not to use it. There is no mention of prerequisites, permissions, or contexts where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Erase everything about a subject and issue a SIGNED CERTIFICATE: exact closure, a probe battery that must all abstain, and bystanders left intact. This is the artifact for a 'delete me and prove it' request.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes |
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 goes well beyond a simple 'erase' by describing the output as a SIGNED CERTIFICATE, the requirement that a probe battery must all abstain, and that bystanders are left intact. This gives the agent a strong understanding of what to expect and the guarantees provided. Minor gaps: no mention of reversibility, permissions, or side effects, but for an erasure tool these are adequately covered by the explicit guarantees.
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 sentences, front-loaded with the core action and the unique deliverable (signed certificate). It packs all essential details — closure, probe battery, bystanders — into a compact, scannable format without any filler words or 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?
For a tool with a single parameter and no output schema, the description fully explains what the tool does, what it returns (the signed certificate and its guarantees), and the trigger context. There is no missing information an agent would need to decide to call this tool and understand its result. The description is self-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 schema has one required string parameter 'subject' with 0% description coverage. The tool description contributes the meaning that 'subject' is the entity to be erased, which is essential. However, it does not specify the expected format (e.g., name, ID, or any canonical form) or constraints beyond being a string. Given the simplicity of the parameter, the addition of meaning earns a 3, but it could be more explicit.
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 (erase), the resource (subject), and the unique guarantee (issue a SIGNED CERTIFICATE with exact closure, probe battery all abstain, bystanders intact). It clearly differentiates from siblings like recall or verify_receipts by explicitly framing this as the artifact for a 'delete me and prove it' request.
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 provides a clear use case: 'delete me and prove it' requests. It implicitly guides the agent to use this tool when deletion with verifiable proof is needed, and by contrast other tools (remember, recall, etc.) serve other purposes. However, it does not explicitly name alternative tools or discuss when not to use it, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Substrate size, entities, sources held, and mode.
| Name | Required | Description | Default |
|---|---|---|---|
No 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 merely lists output fields and does not state that it is a read-only operation, describe any side effects, or explain the output format. The agent cannot infer safety or side effects from this description.
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 fragment, not a full sentence, and omits the verb. While it is short, it is under-specified and lacks the structure of an effective description. The fragment does not earn its place because it fails to communicate the tool's action.
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 no output schema, no parameters, and no annotations, the description is minimal. It lists fields but does not explain what 'substrate size', 'entities', 'sources held', or 'mode' mean, nor does it state the purpose or expected usage. An agent has insufficient information to invoke this tool correctly.
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?
There are zero parameters, so the baseline is 4 per the rubric. The description does not need to add parameter meaning because none exist. However, it also does not enrich the tool's overall semantics beyond the schema, so no higher score is warranted.
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 is a noun phrase listing data fields ('Substrate size, entities, sources held, and mode') without a verb or explicit resource. It does not state that this tool retrieves or returns these statistics, so the agent cannot be sure what action the tool performs. It also does not differentiate this from sibling tools like recall or export_memory.
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 on when to use this tool versus the sibling tools. No context about prerequisites, conditions, or typical scenarios (e.g., checking memory state before an operation) is provided. The agent is left entirely to guess 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 memory. Returns grounded claims with the byte ranges they came from. If the substrate cannot answer, it ABSTAINS and says which term it could not ground — treat that as a real answer, not an empty result.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does real work: it discloses the return shape (grounded claims with byte ranges) and, critically, the abstention behavior — telling the agent to treat an ungrounded-term disclosure as a real answer, not empty results. This prevents a serious misinterpretation. It stops short of covering error conditions or permission needs, but the abstention quirk is the highest-value disclosure for this tool.
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, front-loaded with the core purpose first, then return format, then behavioral caveat. Every sentence earns its place with no filler. Slightly dense but tightly constructed — no waste.
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 single-parameter search tool with no output schema, the description covers the essential behavioral contract (search, grounded return format, abstention semantics). However, it is vague on what 'the substrate' is, and beyond the byte-range note it gives no sense of result volume, ordering, or pagination — minor gaps for such a simple tool.
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 undocumented query parameter — and it does not. Nothing clarifies query format, length, phrasing guidance, or how a good query is constructed. The single parameter's meaning is somewhat self-evident from 'Search memory,' but the description adds no value beyond the schema itself.
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-resource pair ('Search memory') that cleanly separates it from every sibling (remember, add_source, verify_receipts, forget, export_memory, memory_stats — none of which search). The byte-range grounding detail further differentiates it as a retrieval-with-evidence 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 verb 'search' implies the tool is for retrieval, which is enough to distinguish it from mutation siblings like remember and forget. But the description never explicitly says when to use it over alternatives or states any exclusions — usage guidance is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Commit a fact to memory. The claim is admitted ONLY if the evidence you cite supports it — you are the proposer, a deterministic gate decides. Refusals are typed and explain what to fix. Evidence must be text you are quoting verbatim, not a paraphrase.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | the fact to remember | |
| evidence | Yes | verbatim text supporting it | |
| source_id | No | source this came from (default: agent) | |
| source_text | No | the full document this evidence was quoted from. Pass it and the claim binds to a verifiable BYTE RANGE in it — the receipt. Optional, but this is the point. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it delivers: it discloses that admission is conditional on evidence, that refusals are typed and actionable, and that the tool is a write operation ('commit'). The schema adds the byte-range binding and receipt behavior. Gaps: it does not describe what a successful call returns (the receipt format) or explicitly state the response envelope beyond typed refusals.
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 dense sentences, zero wasted words. The primary verb is front-loaded, the gating mechanic follows immediately, and the verbatim constraint closes it out. Every clause earns its place and no structured-field content is redundantly repeated.
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 tool of moderate complexity — a gated mutation with typed refusals and byte-range receipt binding — the description plus schema covers the essentials: purpose, evidence requirement, failure mode, and the optional source_text binding. The main omission is the success response shape (what the receipt actually is on the happy path), which is hinted at in the schema but never fully described.
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 interpretive value beyond the schema: framing the caller as 'proposer' subject to a 'deterministic gate' explains WHY claim and evidence matter and how they interact, and the verbatim emphasis reinforces the constraint on the evidence parameter. This contextual rationale is more than the schema's terse field descriptions provide.
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?
Opens with a specific verb+resource construction — 'Commit a fact to memory' — and immediately distinguishes itself from the sibling set: it is not recall (reading), not forget (deleting), not verify_receipts (checking), and not add_source (storing a source document). The added detail about the deterministic gate and verbatim evidence requirement makes the tool's identity unambiguous.
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 when to use the tool — when an agent holds a fact supported by verbatim quoted evidence — and the gate/verbatim constraints effectively rule out using it for paraphrased claims. However, it never explicitly names alternatives or states when-not-to-use, leaning entirely on implicit context. No exclusion guidance such as 'for uncited facts use add_source first' is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List claims the firewall held for review rather than storing. These were NOT written to memory; a QUARANTINE verdict means the claim could not be classified confidently, not that it was rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | most recent N (default 20) |
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 clearly states that quarantined claims were not written to memory and explains the meaning of a QUARANTINE verdict, adding valuable semantic context. It omits details like ordering or side effects, but 'List' implies read-only 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?
Two tight sentences. The first states the core function, and the second clarifies a potential misinterpretation. There is no filler or redundant phrasing.
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 list tool with one parameter and no output schema, the description covers the essential behavioral context: what is listed, that it was not stored, and how to interpret the verdict. It does not describe output fields, but that is a minor gap for a tool with this simplicity.
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 documents the single parameter 'limit' with its default and meaning (most recent N), so schema coverage is 100%. The description adds no extra parameter-level detail, but it also does not need to; the schema handles parameter semantics adequately.
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 ('List') with a clear resource ('claims the firewall held for review') and adds a distinguishing detail: these claims were NOT written to memory. This differentiates the tool from memory-listing siblings like recall and review_reads.
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 gives clear context for when to use this tool: when you need to see claims quarantined by the firewall. It also clarifies an important semantic point (quarantine is not rejection). However, it does not explicitly name alternatives or state 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.
What has been asked of this substrate and what it answered. Off unless FIREWEED_MCP_READ_AUDIT=1; query text is recorded only if FIREWEED_MCP_READ_AUDIT_TEXT=1 as well, otherwise queries appear as salted fingerprints.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | how many recent reads to show |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait: the tool is effectively disabled unless FIREWEED_MCP_READ_AUDIT=1, and query text is only recorded if FIREWEED_MCP_READ_AUDIT_TEXT=1 is also set. It also clarifies that queries may appear as salted fingerprints. This is useful context beyond the minimal schema. No annotations are provided, so the description carries the full burden; it covers the audit-gating behavior but does not mention whether this is a read-only operation or what the output looks like.
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 compact and front-loads the core purpose in the first sentence. The second sentence provides essential configuration caveats without excess. It earns a 4 because it is appropriately sized, though the phrasing could be slightly more direct.
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 one optional parameter and no output schema, the description covers the main feature and the critical audit-gating behavior. However, it does not specify what the tool returns (list structure, fields, format), nor does it explain how to interpret salted fingerprints, which an agent likely needs to use the output correctly.
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 100%, and the single parameter 'limit' is already documented as 'how many recent reads to show'. The description does not add further meaning to the parameter, but the schema fully covers it, so a baseline score of 3 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 says the tool shows what has been asked and answered, so it is a read-audit/review tool. However, it does not name the operation explicitly with a direct verb+resource structure like 'List read queries', relying on indirect phrasing, and it does not differentiate itself from siblings such as review_quarantine or trace_evidence.
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 when-to-use or when-not-to-use guidance is given, and no alternatives are named. The description focuses on configuration prerequisites (FIREWEED_MCP_READ_AUDIT) rather than agent decision-making about choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit BACKWARDS from a stored memory to the arrival of the evidence it rests on: the byte range it binds, whether those bytes still match, whether the document's arrival is in the append-only ledger, and whether the chain verifies. States plainly which fields are attested and which are caller-declared.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | any distinctive substring of the stored claim to trace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it discloses the backward trace direction, the byte-match check, ledger verification, chain verification, and the distinction between attested and caller-declared fields. It does not mention failure modes or permissions, but the audit framing suggests a read-oriented 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 sentences with no filler. The action and direction are front-loaded, and every phrase contributes to the audit semantics without repetition.
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 single-parameter tool with no output schema, the description covers the operation, the checks performed, and the nature of the result (attested vs caller-declared fields). It does not describe the exact output structure or error behavior, but it gives enough for an agent to call the tool correctly.
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 100% coverage of the single parameter with 'any distinctive substring of the stored claim to trace'. The description reinforces the link to stored memory but does not add meaningful semantic detail 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 anchors on a specific action ('Audit BACKWARDS') and resource ('stored memory... evidence'), then spells out concrete checks: byte range, byte match, append-only ledger arrival, and chain verification. This clearly distinguishes it from siblings like recall or verify_receipts.
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 gives a clear use context: trace evidence provenance backward from a stored memory and determine which fields are attested versus caller-declared. It does not explicitly name alternatives or state when not to use it, so it lacks the strongest routing guidance but is not ambiguous about its intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-hash every held source and re-slice every receipt. Tamper-evident: change one byte of a source and its receipts stop verifying.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 does reveal a key property: tamper-evidence (changing a source breaks receipt verification). However, it does not state whether the operation is read-only or mutating, whether it can fail, or what output it produces. The disclosed property is useful but incomplete.
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 sentences with no filler. The primary action is front-loaded, and the tamper-evident detail is added efficiently. Every sentence contributes meaningful information, earning a high score for 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 tool has no parameters and no output schema, so the description must convey enough context for correct invocation. It explains the action but omits side effects, error conditions, and return values. It also does not place the tool in the broader workflow (e.g., when to verify receipts). This leaves some ambiguity about the expected behavior.
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, and schema coverage is trivially 100% given the empty schema. Per the rubric, 0 parameters earns a baseline of 4. The description adds no parameter-specific detail, but none is needed since there are no parameters to explain.
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 ('re-hash every held source and re-slice every receipt') and a resource (sources and receipts). The tamper-evident note adds a distinctive property that separates it from siblings like remember and recall. It is not a tautology and clearly communicates what the tool does.
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 gives no explicit guidance on when to use this tool versus the sibling tools (e.g., after adding a source, before exporting memory). It does not mention prerequisites or exclusions. An agent is left to infer the appropriate invocation context.
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. Dates show when Glama detected each change.
v0.5.0add_source4 fields changedInput schema / properties / originAdded value: +{
+ "description": "where these bytes came from (path, URL, endpoint). RECORDED BUT NOT VERIFIED.",
+ "type": "string"
+}Input schema / properties / origin_kindAdded value: +{
+ "description": "the kind of origin. Recorded but not verified.",
+ "enum": [
+ "conversation",
+ "file",
+ "url",
+ "api",
+ "user_submitted",
+ "unknown"
+ ],
+ "type": "string"
+}Input schema / properties / supplied_byAdded value: +{
+ "description": "who handed these bytes over. Recorded but not verified.",
+ "type": "string"
+}Input schema / properties / validated_byAdded value: +{
+ "description": "what checked these bytes before ingest, if anything. Recorded but not verified.",
+ "type": "string"
+}review_quarantinereview_readstrace_evidencev0.1.2add_sourceexport_memoryforgetmemory_statsrecallrememberverify_receiptsEach tool targets a distinct operation: writing, recalling, erasing, exporting, auditing reads, tracing provenance, verifying receipts, and reviewing quarantine. The closest pairs (review_reads vs review_quarantine, trace_evidence vs verify_receipts) are clearly separated by their descriptions.
Most tools follow a verb_noun pattern (add_source, export_memory, verify_receipts, trace_evidence, review_reads, review_quarantine), but remember, recall, and forget are bare verbs and memory_stats is noun_noun. The style is readable and lowercase-snake throughout, but the convention is genuinely mixed.
Ten tools is well-scoped for a verifiable memory substrate. Each tool covers a necessary capability—ingestion, recall, deletion with proof, export, audit, verification, quarantine review, and statistics—without redundant or filler tools.
The surface covers the full evidentiary memory lifecycle: add_source and remember for writing, recall for reading, forget for erasure with proof, export for portability, plus trace_evidence and verify_receipts for auditability. The append-only, evidence-bound design makes an update tool unnecessary; corrections would naturally flow through new evidence.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent memory that refuses to guess: evidence-gated recall, exact-source reads, verifiable deletion.
Verified memory for AI agents. Signed assertions, billing attestation, session continuity.
Evidence-grounded, graph-connected, correctable memory for agents.
Machine-native utility network: verified evidence services for autonomous agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Starksood/fireweed-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
