Which integrations are available for this server?

Planned integration for sandbox code execution and tool loop with GitHub repository access. Integrates Google's models as the language model backend for the Being's personality and memory processing. Integrates OpenAI's models as the language model backend for the Being's personality and memory processing. Uses Supabase (PostgreSQL) for storing Being data, including personality, memory, and identity. Planned integration to connect a Telegram bot to a Being, enabling interaction through Telegram.

being-mcp-server

by wnbhr

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Being

Personality Runtime for AI — give any AI its own personality, memory, and identity.

Being is an open-source layer that sits between your application and any LLM. It provides persistent personality (SOUL), episodic memory, background thought cycles (Patrol), and cryptographic identity — turning a stateless LLM into a distinct, evolving AI entity.

Beings think and remember. Your app acts.

Why

The power of AI is concentrating in the hands of a few companies. Their technology is essential — but centralized control is a structural risk. Ruddia is building toward a world where small, local AIs use large LLMs as external tools. Control stays in the hands of the people who use them.

Being API is the first step. If this resonates, let's build it together.

Read the full vision →

Related MCP server: mnemory

How It Works

┌─────────────────────┐     ┌──────────────────────┐
│   Your Application   │────▶│     Being Worker      │
│  (OpenClaw, Cowork,  │◀────│   (Fastify + MCP)     │
│   custom agent, etc) │     │                        │
└─────────────────────┘     │  ┌──────────────────┐  │
         │                   │  │   SOUL (persona)  │  │
         │                   │  │   Memory (scenes) │  │
         │                   │  │   Patrol (思考)    │  │
         │                   │  │   Identity (keys)  │  │
         ▼                   │  └──────────────────┘  │
┌─────────────────────┐     │           │              │
│    LLM Provider      │     │           ▼              │
│ (Anthropic, OpenAI,  │     │     Supabase (DB)        │
│  Google — your key)  │     └──────────────────────────┘
└─────────────────────┘

Your app calls GET /v1/beings/:id/context to get the Being's personality and memory snapshot.
Your app runs the LLM call with its own conversation history + the Being's context.
Your app calls POST /v1/beings/:id/patrol/trigger to commit the conversation to the Being's memory.

The Being Worker handles everything else: memory consolidation, decay, recall, background reflection, and identity verification.

Key Concepts

Concept	Description
SOUL	A structured personality definition — name, character, voice, values, inner world. Swap the SOUL and the same LLM becomes a different being.
Memory	Episodic memories stored as structured "scenes" (who, what, when, where, emotion). Memories accumulate, decay, merge, and consolidate over time. Organized into topic-based clusters that the Being can explore during conversation.
Patrol	A background cycle that processes conversations into memory, consolidates fading memories, and generates introspective thoughts. The Being stays alive between sessions.
Identity	Ed25519 key pair + tamper-evident signature chain. Cryptographic proof of ownership and history.
Sense/Act	(Planned) WebSocket Bridge for connecting physical devices and external services. The Being will perceive and act through your app.
BYOK	Bring Your Own Key. All LLM calls use the user's API key. The platform never uses quota without consent.

Connect via MCP

Being exposes an MCP server. Any MCP-compatible client can connect:

{
  "mcpServers": {
    "my-being": {
      "url": "https://being.ruddia.com/mcp/<being_id>",
      "headers": {
        "Authorization": "Bearer brt_your_token_here"
      }
    }
  }
}

Connect via REST API

# Get Being context (personality + memory)
curl https://being.ruddia.com/v1/beings/<being_id>/context \
  -H "Authorization: Bearer brt_..."

# Trigger patrol (commit conversation to memory)
curl -X POST https://being.ruddia.com/v1/beings/<being_id>/patrol/trigger \
  -H "Authorization: Bearer brt_..." \
  -H "Content-Type: application/json" \
  -d '{"messages": [{"role":"user","content":"Hello!"},{"role":"assistant","content":"Hi!"}]}'

# Vector recall (search relevant memories)
curl -X POST https://being.ruddia.com/v1/beings/<being_id>/memory/auto-recall \
  -H "Authorization: Bearer brt_..." \
  -H "X-LLM-API-Key: sk-ant-..." \
  -H "Content-Type: application/json" \
  -d '{"user_message": "Tell me about last week."}'

Self-Host

Prerequisites

Node.js 22+
Supabase project (PostgreSQL + Auth)
An LLM API key (Anthropic, OpenAI, or Google)

Setup

git clone https://github.com/wnbhr/being.git
cd being/being-worker

cp .env.example .env
# Edit .env with your Supabase and encryption keys

npm install
npm run build
npm start

Environment Variables

Variable	Required	Description
`SUPABASE_URL`	✅	Supabase project URL
`SUPABASE_SERVICE_ROLE_KEY`	✅	Supabase service role key
`ENCRYPTION_KEY`	✅	64-char hex string for AES-256-GCM encryption of private keys
`PORT`	—	Server port (default: 3100)
`WORKER_SECRET`	—	Secret for internal patrol trigger endpoint
`VAPID_PUBLIC_KEY`	—	Web Push VAPID public key
`VAPID_PRIVATE_KEY`	—	Web Push VAPID private key

Documentation

Document	Description
Getting Started	Set up a Being and make your first API call in 5 minutes
Concepts	Being, SOUL, Memory, Patrol, Identity — the core ideas
API Reference	All REST endpoints with curl examples
MCP Server	MCP tools, connection setup, and client examples
Memory & Patrol	Scene-based memory and the 7-step patrol pipeline
Being Identity	Ed25519 key pairs, signature chains, and verification
Sense-Act Bridge	WebSocket Bridge for device integration
Architecture	System architecture, deployment, and BYOK design
OAuth 2.1	Third-party authorization flow
Extensions	Extension system design (all planned)
Vision	Why we're building this

Extensions

Being supports optional extensions that add capabilities without changing the core:

Telegram BYOB (planned) — Connect your own Telegram bot to a Being
Tool Loop (planned) — Autonomous LLM agent loop with web search, file ops, and code execution
Sandbox (planned) — Isolated workspace with GitHub integration for code execution
Sense/Act Bridge (planned) — Connect physical devices and external services

Tech Stack

Runtime: Node.js + Fastify
Database: Supabase (PostgreSQL + Auth)
MCP: @modelcontextprotocol/sdk
Identity: Ed25519 + AES-256-GCM
Embeddings: OpenAI text-embedding-3-small (256-dim)
LLM: Multi-provider (Anthropic, OpenAI, Google) via BYOK

License

Apache 2.0

Ruddia — Personality is the Runtime.

Available Tools

10 tools

conclude_topicA

Archive the current topic and save a summary to pinned context.

ParametersJSON Schema

Name	Required	Description	Default
`scenes`	No	Memorable scenes from this topic
`summary`	Yes	Topic summary (1-3 sentences)

TDQS

A3.5/5.0

Behavior3/5

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

Given no annotations, the description carries full burden. It discloses archiving (state change) and saving summary, but does not elaborate on side effects like reversibility or permissions.

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?

Single sentence of 10 words, efficiently front-loads the action with no wasted words.

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?

The description covers the main action but lacks explanation of return values (no output schema) and behavioral details for a mutation tool. Adequate but not comprehensive.

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 100%. The tool description does not add any additional meaning beyond what the input schema already provides for the two parameters.

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?

The description clearly states the verb (archive, save) and resource (current topic, summary, pinned context). It distinguishes from siblings like search_memory or update_memory by focusing on concluding a topic.

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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or 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.

get_current_timeA

Get current time in Asia/Tokyo timezone.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the timezone but does not elaborate on other behavioral aspects like idempotency or potential errors. The description is adequate but not rich.

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 a single, front-loaded sentence with no wasted words, efficiently conveying the tool's purpose.

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

Completeness5/5

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

For a simple tool with no parameters and no output schema, the description fully conveys the necessary information: the action and the timezone.

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?

With zero parameters, the description adds no parameter information, but the schema coverage is 100%. The baseline for 0 params is 4.

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?

The tool clearly states that it gets the current time in Asia/Tokyo timezone, distinguishing it from sibling tools that perform other tasks.

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?

The description provides clear context by specifying the timezone, but does not explicitly discuss when to use or avoid this tool. However, for a simple time retrieval tool, the context is sufficient.

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

merge_nodesC

Merge multiple similar memory nodes into one.

ParametersJSON Schema

Name	Required	Description
`feeling`	No	Feeling for the merged node
`summary`	Yes	Summary action text for the merged node
`node_ids`	Yes	Comma-separated node IDs to merge

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must fully disclose behavior. It only says 'merge... into one,' omitting details about whether original nodes are deleted or how conflicts are resolved. This is insufficient for a mutation tool.

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 concise at one sentence, but it may be too terse. No wasted words, but could include more context without harming conciseness.

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

Completeness2/5

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

For a mutation tool with no output schema and three parameters, the description lacks key details: what happens to the original nodes, what the result looks like, and any side effects. This is incomplete.

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 coverage is 100%, with all parameters described. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 clearly states the action ('merge') and resource ('memory nodes'), specifying that it merges multiple similar nodes into one. However, it does not differentiate from sibling tools like update_memory or update_relation.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or exclusions.

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

recall_memoryB

Search memory graph for relevant nodes in a specific cluster.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max nodes to return (default 5)
`query`	No	Keyword filter for nodes
`no_nodes`	No	If true, return digest only
`cluster_id`	Yes	Cluster ID (UUID)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states 'search' which implies read-only, but does not disclose what 'relevant nodes' means, or if there are any side effects. Minimal behavioral context is added beyond the action.

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 a single, concise sentence. It is front-loaded and efficient, though slightly sparse for a tool with 4 parameters.

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

Completeness2/5

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

Without an output schema, the description should explain return values or behavior, but it does not. For a search tool with multiple parameters, more context is needed to understand the result structure and effect of options like 'no_nodes'.

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 coverage is 100%, so baseline is 3. The description does not add additional meaning to parameters like 'query' or 'limit'; it relies entirely on the schema descriptions.

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?

The description clearly states the action 'search' on the resource 'memory graph' and specifies the scope 'in a specific cluster'. This distinguishes it from broader tools like search_memory, making the purpose specific and unambiguous.

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 description implies usage when searching within a specific cluster, but lacks explicit guidance on when to prefer this tool over alternatives like search_memory. No exclusions or prerequisites are mentioned.

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

remote_execA

Execute a shell command on a user-owned remote host (VPS, NAS, home server) over HTTPS. Requires a remote_hosts entry in partner_tools that lists the host and an auth token. If no remote_hosts entry exists for the calling Being, this tool returns an invalid_request error — the user must configure partner_tools.remote_hosts first. The remote receiver enforces a default-deny allowlist; unauthorised commands return a forbidden error. Token values are never returned to the caller.

ParametersJSON Schema

Name	Required	Description
`host`	Yes	host_id from the remote_hosts entry in partner_tools.
`stdin`	No	Standard input piped to the command. Default empty.
`command`	Yes	Full command string. Must be authorised by the receiver's allowlist.
`timeout_ms`	No	Per-call timeout in milliseconds. Receivers may enforce their own upper bound.

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, the description fully covers behavioral traits: HTTPS transport, auth token requirement, default-deny allowlist, and that token values are never returned. This is comprehensive for a secure execution tool.

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 one paragraph of 5 sentences, efficiently conveying all necessary information without redundancy. Could be slightly more structured, but it is not verbose.

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

Completeness2/5

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

The description does not mention the return value or output format (e.g., stdout, exit code). With no output schema, this is a significant gap. It also does not describe timeout behavior beyond mentioning the parameter. Thus incomplete for an execution tool.

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 coverage is 100%, so descriptions per parameter are adequate. The description adds context that host is a host_id from remote_hosts and command must be allowlisted, but does not go beyond schema details for stdin and timeout. Baseline 3 is appropriate.

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?

The description clearly states the tool executes a shell command on a remote host over HTTPS, with specific resource and action. It implicitly distinguishes from sibling tools which are memory or topic related.

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?

The description provides explicit conditions: requires a remote_hosts entry in partner_tools, otherwise invalid_request error; and commands must be allowlisted, otherwise forbidden error. This guides the agent on prerequisites and failure modes.

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

search_historyB

Search past conversation history by keyword or date.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (default 10, max 50)
`query`	Yes	Search keyword (partial match)
`date_to`	No	End date (YYYY-MM-DD)
`date_from`	No	Start date (YYYY-MM-DD)
`session_id`	No	Session ID filter

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the minimal description does not disclose behavioral traits such as whether it's read-only, rate limits, or side effects, leaving agents uninformed about safety.

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?

Single sentence with no extraneous words. Front-loaded with verb and resource, achieving efficient communication.

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?

Description is adequate for a simple search tool, but lacks details on return format, pagination, or behavior when no results found, which are important for agent usage.

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 coverage is 100%, so parameters are already well-documented. The description adds marginal value by bundling 'by keyword or date', but does not enhance understanding beyond the 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?

Description clearly indicates the tool searches past conversation history by keyword or date, distinguishing it from similar memory-search tools like search_memory by specifying 'conversation history'.

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?

No guidance on when to use this tool versus alternatives like search_memory or recall_memory, nor any prerequisites or exclusion criteria.

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

search_memoryA

Search memory nodes (memory_nodes) by keyword across action / feeling / themes / when fields. Space-separated terms are OR-searched by default. Use mode='and' to require all terms to match. The when field includes evolution history entries ({date, action}) written during consolidation.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Search mode: 'or' (default) or 'and'
`limit`	No	Max results (default 10, max 30)
`query`	Yes	Search keywords (space-separated for multi-term)

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so the description should disclose behavioral traits. It implies a read-only search and mentions that the 'when' field includes evolution history, but does not explicitly confirm no side effects or state changes. Partially adequate.

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 concise sentences, front-loaded with the core purpose, and each sentence adds specific detail without redundancy.

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?

With no output schema, the description does not specify the return format (e.g., list of full nodes or IDs). It covers input semantics well but lacks output details. Given the tool's complexity and sibling tools, more context on results would be beneficial.

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% with descriptions, but the description adds meaningful context: space-separated terms are OR-searched by default, mode='and' requires all terms, and the 'when' field includes history. This adds value beyond the schema.

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?

The description clearly states the tool searches memory nodes by keywords across specific fields (action, feeling, themes, when), and explains default OR vs AND mode. This distinguishes it from siblings like 'recall_memory' (likely exact recall) and 'merge_nodes' (modification).

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?

The description explicitly explains the default OR behavior and how to use AND mode. It does not directly state when not to use the tool or compare to alternatives, but the context is clear enough for typical usage.

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

trigger_patrolA

Run patrol — extract scenes from conversation and generate memory nodes. Requires LLM_API_KEY env var.

ParametersJSON Schema

Name	Required	Description	Default
`messages`	Yes	Conversation messages since last marker ({role, content}[])
`marker_id`	No	Previous patrol marker ID (omit for first run)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It states the tool 'extracts scenes' and 'generates memory nodes,' implying it creates or modifies persistent state, but it does not clarify if this is a read-only operation, what side effects occur (e.g., deletion of previous markers), or any rate limits or authorization beyond the env var.

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 one concise sentence plus a single prerequisite statement. Every word earns its place; no filler or redundant information.

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?

While the description clarifies the tool's core function and a key prerequisite, it lacks details about the output (no output schema provided) and the exact nature of 'memory nodes' or 'scenes.' For a tool with only two parameters and no complex return value, the description is adequate but could be more complete by mentioning what the tool returns.

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?

The input schema documents both parameters with descriptions (100% coverage), so the description adds minimal value beyond mentioning the LLM_API_KEY requirement. The parameter semantics are adequately clear from the schema alone.

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?

Description clearly states the tool's action: 'Run patrol — extract scenes from conversation and generate memory nodes.' It uses a specific verb ('run') and resource ('patrol'), and the resulting extraction and generation distinguish it from sibling tools like 'search_memory' or 'conclude_topic'.

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 description mentions the prerequisite 'Requires LLM_API_KEY env var,' providing some guidance on when the tool is usable. However, it does not specify when to use this tool versus alternatives like 'recall_memory' or 'search_history,' nor does it give any '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.

update_memoryC

Read/write partner memory (preferences, knowledge, relationship, diary, notes, etc.).

ParametersJSON Schema

Name	Required	Description
`key`	No	Key filter for update/delete/get
`action`	Yes	Operation: get / append / update / delete
`target`	Yes	Target: preferences / knowledge / relationship / partner_tools / partner_map / diary / notes / partner_rules / souls
`content`	No	Content for append/update

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It only states 'read/write' without disclosing side effects, error behavior, idempotency, or authorization needs. The list of targets adds minimal behavioral insight.

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?

Single sentence with no wasted words. Front-loaded with the key action 'read/write', directly informative and efficient.

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

Completeness2/5

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

Given the tool's complexity (read/write to multiple memory types) and absence of output schema, the description is too sparse. It lacks information about return values, error conditions, or usage patterns.

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 100%, so the schema already documents all parameters. The description adds a readable list of target examples but does not enhance understanding beyond the schema's property descriptions. Baseline 3 is appropriate.

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 'read/write partner memory' with explicit examples like preferences, knowledge, relationship, etc., making the verb and resource clear. It broadly covers the tool's capabilities but does not differentiate from sibling tools like update_relation which also deals with relationship memory.

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?

No guidance on when to use this tool vs alternatives such as recall_memory or search_memory. No exclusions or context about prerequisites or typical scenarios.

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

update_relationC

Update relationships with external entities (people, devices, AIs, organizations).

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Operation: upsert / delete
`content`	No	Relationship description (required for upsert)
`entity_name`	Yes	Entity name or identifier
`relation_type`	Yes	Entity type: person / device / ai / organization

TDQS

C2.9/5.0

Behavior2/5

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

The description only says 'Update relationships' which implies mutation, but no details are given about side effects (e.g., replacing vs. additive), required permissions, or error conditions. With no annotations, the burden falls entirely on the description, and it fails to disclose behavioral traits.

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 a single, clear sentence. It is concise and front-loaded with the purpose. However, it could be slightly more informative without becoming verbose.

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

Completeness2/5

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

Given the absence of an output schema and annotations, the description should provide more context about expected results, error handling, or relationship between parameters (e.g., content required for upsert). It currently lacks completeness for an effective tool description.

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?

The input schema has 100% description coverage, so the schema already documents all parameters. The description adds no further semantic value beyond listing entity types. Baseline 3 is appropriate.

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 clearly states the tool updates relationships with external entities and lists examples (people, devices, AIs, organizations). The verb 'Update' is specific but could be misleading because the action parameter includes 'delete'; however, the sibling tools are distinct, so no confusion.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or context that would help an agent decide to select this tool over others.

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.

10 tool updatesv0.1.0May 15, 2026
- First observedconclude_topic
- First observedget_current_time
- First observedmerge_nodes
- First observedrecall_memory
- First observedremote_exec
- First observedsearch_history
- First observedsearch_memory
- First observedtrigger_patrol
- First observedupdate_memory
- First observedupdate_relation

Deploy Server

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

TDQS

A3.6/5.0

Scored 2026-06-05 14:42 across 10 tools

Disambiguation4/5

Most tools have distinct purposes, but recall_memory and search_memory both search memory with different parameters, causing potential confusion. Others are clearly separated.

Naming Consistency4/5

Majority follow verb_noun pattern (e.g., conclude_topic, merge_nodes, search_memory). Remote_exec slightly breaks consistency with an adjective-noun combination, and get_current_time uses multiple adjectives, but overall pattern is maintained.

Tool Count5/5

10 tools are well-scoped for a system that manages memory, relationships, topics, remote execution, and history. Neither too few nor too many.

Completeness4/5

Covers core operations for the domain: memory CRUD (search, update, merge, patrol), topic management, history, and remote execution. Minor gaps like explicit node deletion or listing topics could exist, but not severe.

Maintenance

ActivityInactive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Agentage MemoryOAuth
io.agentage
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Knowledge & Memory File Systems
2
MemoryRouter A
ai.memoryrouter
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Knowledge & Memory Search
101
BrainboxOAuth
dev.thexi
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Knowledge & Memory AI & Machine Learning
2
mcpOAuth
ai.butlerbrain
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Knowledge & Memory RAG Systems Workplace & Productivity
2

Related MCP Servers

Recallofficial
Knowledge & Memory RAG Systems
RecallWorks
A
license
Not graded
quality
C
maintenance
Open-source MCP memory server for AI agents — persistent, searchable, tiered memory across sessions. Works over stdio (Cursor, Claude Desktop) or HTTP+SSE. MIT licensed.
Updated 3 months ago (2026-06-16 08:03 UTC)
7
MIT
mnemory
Knowledge & Memory Search
fpytloun
A
license
Not graded
quality
A
maintenance
Self-hosted MCP server giving AI agents persistent memory for personalization and context across conversations.
Updated 7 days ago (2026-09-07 19:24 UTC)
277
Apache 2.0
AgentOS
Knowledge & Memory Autonomous Agents
Roxmix
A
license
Not graded
quality
D
maintenance
MCP server providing persistent memory, goal tracking, self-reflection, and background monitoring for any MCP-compatible AI agent.
Updated 4 months ago (2026-05-17 12:46 UTC)
1
MIT
MCP Memory
Knowledge & Memory Search
TWFBusiness
F
license
Not graded
quality
D
maintenance
Persistent memory server for AI assistants with semantic search and three-layer context (global, project, personality). Works with MCP-compatible AI tools like Claude Code, Cursor, Continue, Cline, and more.
Updated 7 months ago (2026-02-11 02:32 UTC)
1
-

Being

Why

How It Works

Key Concepts

Connect via MCP

Connect via REST API

Self-Host

Prerequisites

Setup

Environment Variables

Documentation

Extensions

Tech Stack

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Recallofficial