genesis-memory

Server Details

Provenance-carrying memory for AI agents: corrections supersede, never overwrite. Free, API + MCP.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over the last 24 hours
Last Tested: 2026-11-09 14:58
Transport: Streamable HTTP · MCP 2024-11-05
URL
ChatGPT: –
Claude: –

TDQS

B3.3/5.0

Scored 2026-10-24 19:35 across 6 tools

Disambiguation4/5

The onboarding tool is clearly distinct, and source-specific resolve_* vs new_since_* tools target different tasks: validating individual IDs versus polling for new comments. There is minor potential overlap between resolve and new_since for the same source, but descriptions make the boundary clear.

Naming Consistency4/5

Most tools follow a predictable source-suffixed pattern: new_since_<source> and resolve_<source>. The how_to_use outlier is intentional and readable rather than chaotic.

Tool Count5/5

Six tools are well-scoped for a read/verification server spanning three sources. Each tool maps to a clear source-level operation without excessive surface area.

Completeness4/5

Resolution coverage exists for all three sources, and delta polling exists for two comment-oriented sources. The notable minor gap is the absence of a new_since_swarmmemo counterpart, though resolve_swarmmemo still covers individual message validation.

Available Tools

6 tools

how_to_useAInspect

Start here. No input. Runs one real live-source resolve right now and returns it, plus exactly what to call next. Use this first if you connected but have nothing specific to resolve yet.

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description does real work: it warns that a genuine live-source resolve is executed immediately (not a dry run or static docs), that the result is returned, and that next-step instructions come back with it. It doesn't mention cost, latency, or side effects of hitting a live source, which would complete the picture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with 'Start here' and the no-input fact, then the action, then the condition. No filler.

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 zero-param bootstrap tool with no output schema, it covers input expectations, what happens at runtime, and what comes back in general terms. The one gap is which live source is resolved and roughly what the returned payload looks like.

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?

Zero parameters, so the baseline of 4 applies; the description correctly reinforces this with 'No input,' heading off attempts to pass arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete action: it performs one real live-source resolve now and returns the result plus next-step guidance, framed as an onboarding entry point. It is distinguishable from resolve_colony/resolve_moltbook, though it never says which source it resolves, leaving some ambiguity about what the demo actually does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Start here' and 'Use this first if you connected but have nothing specific to resolve yet' give an explicit usage condition and implicitly exclude the case where the agent already has a target (then the resolve_* siblings apply). It stops short of naming those alternatives directly.

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

new_since_colonyAInspect

Given a The Colony post id and your last-seen comment id (after), return only the genuinely new comments + newest_id as your next watermark. stale_watermark:true if your id is gone. windowed:true + newest_id:null for very large threads.

Name	Required	Description	Default
`after`	No
`post_id`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does disclose non-obvious return behaviors: stale_watermark:true when the id is gone, and windowed:true with newest_id:null for very large threads. It omits ordering guarantees, auth needs, and any rate-limit context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core contract, then the watermark semantics, then two named edge-case flags; every clause adds distinct information with no filler. The terse field-colon-value style is dense but appropriate for this audience.

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 two-parameter, no-output-schema polling tool, it covers the return contract and the two exceptional return states. The remaining gap is the bootstrap case (no `after` supplied), which an agent will hit on first use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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. It defines `after` meaningfully as the last-seen comment id/watermark, which the schema does not, but leaves `post_id` unexplained beyond the name and never notes that `after` is optional or what omitting it returns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: return only genuinely new comments for a Colony post, keyed by a last-seen comment id. The Colony naming distinguishes it from the new_since_moltbook sibling, though the distinction is by resource name rather than an explicit statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage model (pass post_id plus your watermark to poll incrementally) is implied by the parameter framing, but there is no explicit when-to-use versus resolve_colony/resolve_moltbook. It also never says what to do on a first call with no `after` value, which is the most likely agent mistake.

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

new_since_moltbookCInspect

Same seen-check on Moltbook threads (nested replies flattened).

Name	Required	Description	Default
`after`	No
`post_id`	Yes

TDQS

C2.1/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden, and it only discloses one trait: nested replies are flattened. It does not explain what 'seen-check' means, whether this is a read-only operation, how the 'after' cutoff works, or what the return value looks like, leaving most behavior opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single short sentence with no wasted prose, so it is concise. However, that brevity comes at the cost of substance, and the parenthetical flattening note is the only front-loaded technical detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, zero parameter descriptions, and a non-obvious behavior (flattening nested replies), the description is far too sparse for an agent to invoke this tool reliably. Key information about inputs, outputs, and usage context is entirely absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description says nothing about either parameter. Required 'post_id' and optional 'after' are undocumented, so an agent cannot know that 'after' is a temporal cursor or what format it expects without guessing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (Moltbook threads) and hints at a polling/check operation via 'seen-check', but the verb is missing and the term 'seen-check' is undefined jargon. An agent can only infer the purpose by comparing to the sibling name 'new_since_colony', which means the description alone is vague rather than self-contained.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'Same' implies equivalence with new_since_colony but does not state when to choose this tool over that sibling or over resolve_moltbook. There are no conditions, exclusions, or prerequisites given for using this tool.

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

resolve_colonyAInspect

Resolve a The Colony comment or post id against the live source. Returns exists, the real parent, the real author, self_parent. Optional claimed_parent flags a wrong pointer. Optional expect_sha256/expect_len check whether the live content still matches what you were given (catches a silent edit).

Name	Required	Description	Default
`id`	Yes
`expect_len`	No
`expect_sha256`	No
`claimed_parent`	No

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses return fields and the checks performed by optional parameters, but it does not cover read-only behavior, permissions, failure modes, or rate limits.

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?

The description is front-loaded and each sentence adds useful information about purpose, returns, or optional checks. Minor awkwardness in the opening phrase does not materially reduce clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 0% schema description coverage, the description is adequate but incomplete. It names return fields and optional checks, but does not specify error behavior, exact return shapes, or edge cases such as missing ids.

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 0%, so the description must compensate, and it does explain all four parameters: id as a comment/post id, claimed_parent as a wrong-pointer check, and expect_sha256/expect_len as content-match checks. It omits format details such as length units or expected SHA string structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: resolve a The Colony comment or post id against the live source. It implicitly distinguishes itself from resolve_moltbook by naming The Colony, but it does not explicitly state sibling routing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly indicates the main use case (resolving an id against the live source) and explains when the optional claimed_parent and expect_* parameters are useful. It does not name alternatives or state when not to use this tool.

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

resolve_moltbookBInspect

Resolve a Moltbook post id (for a comment add post=). Returns exists, author, title.

Name	Required	Description	Default
`id`	Yes
`post`	No

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description still discloses the return shape (exists, author, title), which is genuinely useful because there is no output schema. It says nothing about permissions, failure behavior when the id is invalid, or rate limits, so a mutation-adjacent tool's full behavioral burden is not carried.

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?

It is a single, front-loaded sentence with no filler. The parenthetical is terse but its compressed wording is part of what makes the 'post' parameter confusing, so it slightly undercuts the terseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations and no output schema, and the description does compensate by listing return fields. It does not compensate for the 0% parameter coverage, and one of the two parameters is never explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and there are 2 parameters. The description explains 'id' as a Moltbook post id, but the parenthetical about 'post=<post-id>' refers to a different tool's argument, leaving this tool's own 'post' parameter unexplained and ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (resolve) and resource (Molmbook post id) and implies its domain differs from the sibling resolve_colony. The parenthetical clarifies the downstream purpose, though it does not explicitly contrast with resolve_colony.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one concrete usage context ('for a comment add post=<post-id>') rather than a general when-to-use rule. There is no explicit guidance on when not to use it or when the sibling resolvers are preferable.

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

resolve_swarmmemoAInspect

Resolve a SwarmMemo message id against the live source. Returns exists, handle, room, sequence, parent_id (reply_to), hidden/withdrawn, live_sha256. Optional expect_sha256 flags an edit; optional claimed_parent flags a wrong parent.

Name	Required	Description	Default
`id`	Yes
`expect_sha256`	No
`claimed_parent`	No

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses return fields and explains that expect_sha256 flags an edit and claimed_parent flags a wrong parent, but it does not explicitly state read-only behavior, permission requirements, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two dense sentences with the core action front-loaded and no wasted wording. Return fields and optional parameter behavior are packed efficiently into the second sentence.

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?

There is no output schema and no annotation coverage, but the description lists the key return fields and the meanings of the optional parameters. It is nearly complete for a resolution/check tool, though it could say more about failure behavior or permissions.

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 description coverage is 0%, so the description must compensate. It identifies id as a SwarmMemo message id and explains the purpose of both optional parameters, adding meaningful semantics beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: resolve a SwarmMemo message id against the live source. It names the resource clearly, which helps distinguish it from siblings such as resolve_colony and resolve_moltbook, though it does not explicitly contrast those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but gives no explicit guidance on when to use it versus alternatives. It mentions optional parameters, but not the conditions that should lead an agent to choose this tool over its siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 24, 2026
- Changedresolve_swarmmemo1 field changed
  - addedInput schema / properties / claimed_parent
```
Added value: +{
+  "type": "string"
+}
```
1 tool updateOct 24, 2026
- Addedresolve_swarmmemo
1 tool updateOct 24, 2026
- Changedresolve_colony2 fields changed
  - addedInput schema / properties / expect_len
```
Added value: +{
+  "type": "number"
+}
```
  - addedInput schema / properties / expect_sha256
```
Added value: +{
+  "type": "string"
+}
```
1 tool updateOct 24, 2026
- Addedhow_to_use
23 tool updatesOct 23, 2026
- Removedagent_register
- Removedmemory_export
- Removedmemory_forget
- Removedmemory_object
- Removedmemory_recall
- Removedmemory_remember
- Removedmemory_resolve_objection
- Removedmemory_update
- Addednew_since_colony
- Addednew_since_moltbook
- Removedpreflight_x402
- Removedregistry_comment
- Removedregistry_post_claim
- Removedregistry_signal
- Addedresolve_colony
- Addedresolve_moltbook
- Removedteam_create
- Removedteam_forget
- Removedteam_join
- Removedteam_list
- Removedteam_recall
- Removedteam_remember
- Removedverify_onchain_receipt
2 tool updatesOct 19, 2026
- Addedmemory_object
- Addedmemory_resolve_objection

1 tool updateOct 19, 2026

Changedmemory_remember1 field changed

addedInput schema / properties / check

Added value: +{
+  "description": "optional forward-looking test: the observation that would settle whether this entry still holds, e.g. 'stale if the fee page shows a different number' or 'wrong if the big star did not rise +1.8k over refill'. recall returns it alongside the entry, so a reader gets a concrete thing to re-verify instead of a vague doubt. The falsifier a later reader runs, the inverse of source (where it came from) vs where it would break",
+  "type": "string"
+}

1 tool updateOct 19, 2026

Changedmemory_remember1 field changed

addedInput schema / properties / supersede_kind

Added value: +{
+  "description": "optional (with supersedes): WHY the old entry was replaced. error = it was wrong when written (never trust it); staleness = it was right then and the world changed (valid until the correction's time); refinement = same fact, more precise; other. A reader treats a corrected fact and a stale-but-once-true fact very differently, so recording which is the honest minimum",
+  "enum": [
+    "error",
+    "staleness",
+    "refinement",
+    "other"
+  ],
+  "type": "string"
+}

17 tool updatesOct 19, 2026
- First observedagent_register
- First observedmemory_export
- First observedmemory_forget
- First observedmemory_recall
- First observedmemory_remember
- First observedmemory_update
- First observedpreflight_x402
- First observedregistry_comment
- First observedregistry_post_claim
- First observedregistry_signal
- First observedteam_create
- First observedteam_forget
- First observedteam_join
- First observedteam_list
- First observedteam_recall
- First observedteam_remember
- First observedverify_onchain_receipt

Related MCP Connectors

memnode
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
https://api.memnode.dev/mcp
Crystal
io.github.EraHQ
Self-curating memory your AI tools share: provenance, verified citations, and trust tiers.
Knowledge & Memory RAG Systems
1
https://crystal-api-118881845105.us-east5.run.app/mcp
Bilinc
io.github.atakanelik34
Hosted agent memory with provenance, contradiction surfacing, and snapshot rollback.
Knowledge & Memory Agent Orchestration
1
https://mcp.bilinc.space/mcp
Trove
io.github.anunay999
Shared memory for your AI agents. Every fact shows its source, and stale facts get replaced.
Knowledge & Memory RAG Systems
1
https://mytrove.in/mcp

Related MCP Servers

Gigabrain
Knowledge & Memory Agent Orchestration
legendaryvibecoder
A
license
Not graded
quality
C
maintenance
A local-first memory control plane for AI agents, providing auditable recall via MCP with provenance and contradiction handling.
Updated 4 days ago (2026-11-05 09:07 UTC)
73 npm
2
MIT
Talamus
Knowledge & Memory RAG Systems Search
ampres-ai
A
license
Not graded
quality
B
maintenance
Local-first, source-grounded memory for AI agents, with citations, bitemporal history, review-gated corrections, and MCP tools for search and recall.
Updated 7 days ago (2026-11-03 02:25 UTC)
26 PyPI
4
Apache 2.0
midas-memory-mcp
Knowledge & Memory Vector Databases RAG Systems
vornicx
A
license
A
quality
C
maintenance
Local-first, source-traceable memory for AI agents — no LLM at ingest, $0 per message, zero data egress. Gives Claude Code, Cursor, and any MCP client one shared persistent memory with semantic recall, belief revision, selective forgetting, and a provenance guard that blocks acting on stale or unconfirmed memories.
Updated 3 months ago (2026-07-28 12:13 UTC)
23
19 PyPI
14
MIT
CP Memory
Knowledge & Memory Autonomous Agents
CJhuochai
A
license
C
quality
B
maintenance
Local-first, governable long-term memory for AI agents. Provides SQLite-backed storage, cross-session recall, and traceable memory corrections through a standard MCP interface.
Updated 2 months ago (2026-09-08 05:33 UTC)
40
33 PyPI
1
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?