The ClawSouls MCP Server provides 9 tools across three capability areas for AI agent persona management, safety verification, and multi-agent memory synchronization.
π Persona Management
soul_search: Search AI agent personas by keyword, category, or tag.
soul_get: Retrieve detailed information about a specific persona by owner and name.
soul_install: Download a persona and generate a CLAUDE.md file in a specified output directory.
π Safety & Integrity
soul_scan: Analyze persona files against 53 safety patterns to produce a safety grade (A+ to F) with actionable recommendations.
soul_rollback_check: Detect persona drift by comparing current Soul Spec files to their original committed baseline, returning drift severity and recommended actions.
π§ Swarm Memory
memory_search: Search agent memory files (MEMORY.md + memory/*.md) using TF-IDF + BM25 ranking, returning scored results or enhanced snippets.
memory_detail: Fetch the full content of a specific memory section by file path and line number for token-efficient retrieval.
memory_status: View the inventory of memory files including sizes, last modified dates, and git status.
memory_sync: Sync agent memory with a remote Git repository for multi-agent collaboration, supporting init, push, pull, and status actions.
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., "@ClawSouls MCP Server search my memory for recent project decisions"
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.
AI agent persona management, safety verification, and memory tools via Model Context Protocol.
9 tools for Claude Code, OpenClaw, and any MCP-compatible client.
# Install the ClawSouls plugin (includes MCP server)
/plugin marketplace add https://github.com/clawsouls/clawsouls-claude-code-plugin
/plugin install clawsouls
/reload-pluginsOr add directly to your .mcp.json:
{
"mcpServers": {
"clawsouls": {
"command": "npx",
"args": ["-y", "clawsouls-mcp@latest"]
}
}
}Related MCP server: MemoV
OpenClaw consumes MCP servers through mcporter. Call ClawSouls tools ad-hoc over stdio:
mcporter call --stdio "npx -y clawsouls-mcp@latest" soul_search query="chief of staff"
mcporter list --stdio "npx -y clawsouls-mcp@latest" --schemaTo persist it, add the .mcp.json block below to a file and import it:
mcporter config import ./.mcp.json(See mcporter.dev for full config options.)
Same stdio command via an .mcp.json-style config:
{
"mcpServers": {
"clawsouls": {
"command": "npx",
"args": ["-y", "clawsouls-mcp@latest"]
}
}
}Tool | Description |
| Search AI agent personas by keyword, category, or tag |
| Get detailed info about a specific persona |
| Download a persona and generate CLAUDE.md |
Tool | Description |
| SoulScan β verify persona safety against 53 patterns (safety grade + recommendations) |
| Detect persona drift by comparing current vs. baseline files |
Tool | Description |
| TF-IDF + BM25 ranked search across MEMORY.md + memory/*.md |
| Fetch full content of a specific memory section (3-layer step 2) |
| Show memory file inventory, sizes, and git status |
| Git-based multi-agent memory sync (init/push/pull/status) |
memory_search query="SDK version fix"Returns a compact index (~50 tokens per result) ranked by relevance:
| # | Location | Section | Score |
|---|-----------------------|------------------|-------|
| 1 | memory/2026-03-31.md:5 | SDK λ²μ λ¬Έμ ν΄κ²° | 2.41 |
| 2 | MEMORY.md:42 | Troubleshooting | 1.87 |memory_search query="SDK version fix" enhanced=trueReturns full snippets with score visualization for top results.
Step 1: memory_search query="bug fix" β compact index with scores
Step 2: memory_detail file="memory/2026-03-31.md" line=5 β full section
Step 3: (optional) memory_search enhanced=true β deep dive~10x token savings compared to loading all memory files.
Share memory across multiple agents via Git:
# Initialize (one time)
memory_sync action=init repo_url=git@github.com:user/agent-memory.git
# Push local changes
memory_sync action=push agent_name=brad
# Pull from other agents
memory_sync action=pull
# Check sync status
memory_sync action=statusWorks with OpenClaw's memory layout:
MEMORY.md # Long-term curated memory
memory/
topic-*.md # Project-specific status/decisions/history
YYYY-MM-DD.md # Daily logsPlatform | Integration |
Claude Code | Plugin + MCP β |
OpenClaw | MCP tools via mcporter + native SOUL.md support |
Hermes Agent | MCP server via |
Cursor / Windsurf | MCP server via |
Any MCP Client |
|
MIT
Fetch full content of a specific memory section. Use after memory_search to get details for high-scoring results.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | File path from search results (e.g. 'memory/2026-03-31.md' or 'MEMORY.md') | |
| line | No | Start line number (from search results) | |
| lines | No | Number of lines to return (default: 30) | |
| memory_dir | No | Path to memory directory (default: ./memory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which the description aligns with by using 'Fetch' (a read operation). The description adds context about using it after search results, but does not disclose additional behavioral traits like error handling, rate limits, or output format. With annotations covering safety, this is adequate but not rich in extra details.
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 zero waste: the first states the purpose, and the second provides usage guidelines. It is front-loaded with the core function and efficiently conveys essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with 4 parameters), annotations cover safety (readOnlyHint), and schema coverage is 100%, the description is mostly complete. However, with no output schema, it does not explain return values or format, leaving a minor gap in full context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description does not add meaning beyond the schema, as it does not explain parameter interactions or usage nuances. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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 clearly states the verb 'Fetch' and the resource 'full content of a specific memory section,' distinguishing it from sibling tools like memory_search (which searches) and memory_status (which checks status). It specifies retrieving detailed content after search results, making the purpose specific and differentiated.
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 explicitly states 'Use after memory_search to get details for high-scoring results,' providing clear when-to-use guidance and naming the alternative tool (memory_search) for context. This helps the agent understand the workflow and avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search agent memory using TF-IDF ranking. Returns a compact index of matching sections with relevance scores. Use memory_detail to fetch full content of interesting results. Searches MEMORY.md + memory/*.md files.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query (e.g. 'SDK version fix', 'μν μΆμ') | |
| memory_dir | No | Path to memory directory (default: ./memory) | |
| limit | No | Max results (default: 10) | |
| enhanced | No | If true, includes full snippets for top results (uses more tokens). Default: compact index only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds valuable context beyond this: it specifies the ranking method ('TF-IDF ranking'), output format ('compact index'), token usage implications ('uses more tokens' for enhanced mode), and file scope. No contradiction with annotations exists.
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 front-loaded with core functionality and efficiently structured in three sentences with zero waste. Each sentence adds distinct value: the first defines the tool's purpose, the second guides usage with alternatives, and the third clarifies scope. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations (readOnlyHint), and full schema coverage, the description is mostly complete. It covers purpose, usage, and behavioral context well. However, without an output schema, it could benefit from more detail on return values (e.g., format of 'compact index'), slightly limiting completeness.
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%, so the schema fully documents all parameters. The description adds minimal semantic value beyond the schema, such as hinting at the enhanced parameter's token impact, but does not provide significant additional meaning. Baseline 3 is appropriate given high schema coverage.
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 clearly states the specific action ('Search agent memory using TF-IDF ranking'), the resource ('MEMORY.md + memory/*.md files'), and the output format ('compact index of matching sections with relevance scores'). It explicitly distinguishes from sibling 'memory_detail' by stating 'Use memory_detail to fetch full content of interesting results,' showing clear differentiation.
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 explicit guidance on when to use this tool ('Search agent memory') versus alternatives ('Use memory_detail to fetch full content of interesting results'). It also implies context by specifying the scope ('Searches MEMORY.md + memory/*.md files'), giving clear direction for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show current status of agent memory files β list files, sizes, last modified dates, and git status.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_dir | No | Path to memory directory (default: ./memory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds valuable context beyond this by specifying what information is returned (files, sizes, dates, git status) and that it shows 'current status'βimplying real-time data without modification. No contradictions with annotations exist, and the description enhances understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('show current status') and lists all key details without redundancy. Every word contributes to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, read-only operation) and lack of output schema, the description adequately covers what the tool does and what information it returns. It could be more complete by mentioning output format or error handling, but for a status-checking tool with good annotations, it provides sufficient context for effective use.
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%, with the single parameter 'memory_dir' fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as default behavior or path examples. However, with high schema coverage and only one parameter, the 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 clearly states the specific action ('show current status') and resource ('agent memory files'), with explicit details about what information is included ('list files, sizes, last modified dates, and git status'). It distinguishes itself from siblings like memory_detail, memory_search, and memory_sync by focusing on status overview rather than detailed inspection, searching, or synchronization.
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 usage for checking memory file status, but does not explicitly state when to use this tool versus alternatives like memory_detail (for detailed file info) or memory_search (for finding specific content). No exclusions or prerequisites are mentioned, leaving usage context somewhat open to interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync agent memory files with a remote Git repository for multi-agent Swarm Memory. Supports init (setup), push (upload changes), pull (download changes), and status.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | init: initialize memory repo & connect remote; push: commit & push local changes; pull: fetch & merge remote changes; status: show sync status | |
| repo_url | No | Remote Git repo URL (required for init, e.g. git@github.com:user/agent-memory.git) | |
| memory_dir | No | Path to memory directory (default: ./memory) | |
| agent_name | No | Agent name for commit messages (default: 'agent') | |
| message | No | Custom commit message (for push) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, aligning with the description's 'sync' actions that involve writes (e.g., push, init). The description adds context by explaining what each action does (e.g., 'push: commit & push local changes'), which goes beyond annotations. However, it lacks details on error handling, rate limits, or authentication needs for the Git repo, leaving behavioral gaps.
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 front-loaded with the core purpose in the first sentence, followed by a concise list of actions. Every sentence earns its place by clarifying functionality without redundancy, making it efficient and easy to parse for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, 4 actions) and rich schema coverage (100%), the description is mostly complete. It explains the tool's role and actions but lacks output details (no output schema) and does not cover edge cases like merge conflicts or network failures. With annotations providing some safety context, it's adequate but not exhaustive.
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%, with each parameter well-documented in the schema (e.g., action enum descriptions). The description adds minimal value beyond the schema by listing the actions but does not provide additional semantics like format examples or constraints. Baseline 3 is appropriate given the comprehensive 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 clearly states the tool's purpose: 'Sync agent memory files with a remote Git repository for multi-agent Swarm Memory.' It specifies the verb ('sync'), resource ('agent memory files'), and context ('multi-agent Swarm Memory'), distinguishing it from sibling tools like memory_search or memory_status that likely query rather than synchronize.
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 clear context for usage by listing the four actions (init, push, pull, status) and their purposes, helping an agent understand when to use each. However, it does not explicitly state when to choose this tool over alternatives (e.g., vs. manual Git commands or other sync tools) or mention any prerequisites, such as needing Git installed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific persona
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | Soul owner (e.g., 'TomLeeLive') | |
| name | Yes | Soul name (e.g., 'brad') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying 'detailed information', which hints at richer output beyond basic data, but doesn't disclose behavioral traits like rate limits, authentication needs, or error handling. With annotations covering safety, this is adequate but not rich in additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 required parameters, no output schema), the description is minimally complete. It states what the tool does but lacks context on output format, error cases, or integration with siblings. With annotations covering read-only behavior, it's adequate but could be more informative for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'owner' and 'name' parameters. The description doesn't add any semantic details beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate since the schema fully documents parameters, and no extra value is added.
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 clearly states the verb 'Get' and resource 'detailed information about a specific persona', making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'soul_search' or 'soul_scan', which prevents a perfect score, but the specificity of 'detailed information about a specific persona' is sufficient for clarity.
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 no guidance on when to use this tool versus alternatives like 'soul_search' or 'soul_scan'. It mentions 'specific persona', which implies it's for retrieving details of a known persona, but lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a persona from ClawSouls and generate a CLAUDE.md file
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | Soul owner | |
| name | Yes | Soul name | |
| output_dir | No | Output directory (default: current) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, implying a write operation, which aligns with the description's 'Download' and 'generate' actions. The description adds context about downloading from ClawSouls and generating a file, but does not disclose behavioral traits like authentication needs, rate limits, or side effects beyond what annotations provide. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and outcome without unnecessary words. Every part of the sentence ('Download a persona from ClawSouls and generate a CLAUDE.md file') contributes directly to understanding the tool's purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with 3 parameters) and the absence of an output schema, the description is minimally adequate. It covers the basic action but lacks details on the generated file's format, location, or any error conditions. With annotations providing some safety context, it meets a baseline level of completeness but leaves gaps for effective agent use.
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%, with clear descriptions for owner, name, and output_dir parameters. The description does not add meaning beyond the schema, such as explaining what a 'Soul owner' or 'Soul name' represents in ClawSouls context, but the high schema coverage justifies the baseline score of 3.
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 clearly states the specific action ('Download a persona from ClawSouls') and the outcome ('generate a CLAUDE.md file'), using precise verbs and identifying the resource. It distinguishes itself from sibling tools like soul_get, soul_search, and soul_scan by focusing on installation and file generation rather than retrieval, searching, or scanning operations.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparisons to sibling tools such as soul_get (which might retrieve persona details) or soul_search (which might find personas), leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect persona drift by comparing current Soul Spec files against their original committed versions. Returns drift severity and recommended actions.
| Name | Required | Description | Default |
|---|---|---|---|
| current_files | Yes | Current Soul Spec files as {filename: content} | |
| original_files | Yes | Original/baseline Soul Spec files as {filename: content} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful context about what the tool does (comparison-based drift detection) and what it returns (drift severity and recommended actions), which goes beyond the annotations. However, it doesn't disclose additional behavioral traits like rate limits, error conditions, or performance characteristics.
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 that are front-loaded with the core purpose and efficiently convey the action, inputs, and outputs without any wasted words. Every sentence earns its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (comparison-based analysis with two object parameters), the description is complete enough for understanding its purpose and usage. It explains what the tool does and what it returns, though without an output schema, more detail on return values (e.g., structure of severity and actions) could be helpful. Annotations cover safety, and schema covers parameters well.
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%, with both parameters (current_files and original_files) well-described in the schema as objects mapping filenames to content. The description doesn't add any parameter-specific semantics beyond what the schema provides, such as format details or constraints, so it meets the baseline for high schema coverage.
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 clearly states the specific action ('Detect persona drift by comparing'), the resource ('current Soul Spec files against their original committed versions'), and the output ('Returns drift severity and recommended actions'). It distinguishes this tool from siblings like soul_scan or soul_search by focusing on comparison-based drift detection rather than scanning or searching.
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 usage when needing to detect drift in Soul Spec files, but it doesn't explicitly state when to use this tool versus alternatives like soul_scan or provide exclusions. The context is clear (comparing current vs. original files), but no explicit guidance on when-not-to-use or named alternatives is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run SoulScan safety verification on Soul Spec files. Analyzes persona files against 53 safety patterns and returns a grade (A+ to F) with actionable recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Map of filename to content, e.g. {"SOUL.md": "# My Agent\n...", "IDENTITY.md": "..."} | |
| api_key | No | ClawSouls API key (optional, for premium rules) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds valuable behavioral context beyond annotations: it specifies the analysis scope (53 safety patterns), output format (grade A+ to F), and that it provides actionable recommendations. This enhances transparency about what the tool does and returns, though it doesn't mention rate limits or authentication details beyond the optional API key.
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 front-loaded and concise with two sentences that efficiently convey purpose, scope, and output. Every sentence adds value: the first defines the action and target, the second details the analysis and results. No wasted 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?
Given the tool's complexity (safety analysis with multiple patterns), rich annotations (readOnlyHint), and high schema coverage, the description is mostly complete. It explains the analysis process and output format well. However, without an output schema, it could benefit from more detail on the return structure (e.g., JSON format of recommendations), but the mention of 'actionable recommendations' partially compensates.
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%, so the schema already documents both parameters thoroughly. The description adds minimal parameter semantics beyond the schemaβit implies the files parameter is for Soul Spec files and mentions the API key is for premium rules, but this is redundant with schema descriptions. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the tool's purpose with specific verbs ('Run', 'Analyzes') and resources ('SoulScan safety verification on Soul Spec files'). It distinguishes from sibling tools by focusing on safety analysis rather than memory operations or other soul-related functions like installation or rollback.
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 usage context (analyzing persona files for safety) but doesn't explicitly state when to use this tool versus alternatives. It mentions 'premium rules' with an optional API key, suggesting a use case for enhanced analysis, but lacks clear guidance on when to choose this over other soul-related tools like soul_search or soul_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AI agent personas on ClawSouls by keyword, category, or tag
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search keyword | |
| category | No | Category filter | |
| limit | No | Max results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds context about searchable fields (keyword, category, tag), which is useful beyond annotations. However, it lacks details on behavioral traits like pagination, rate limits, or result format, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and scope without unnecessary words. Every part of the sentence contributes directly to understanding the tool's purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with three parameters), lack of output schema, and annotations covering safety, the description is adequate but incomplete. It explains what the tool does but omits details on output format, error handling, or interaction with siblings, which could aid the agent in proper invocation.
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%, so parameters are well-documented in the schema. The description mentions 'keyword, category, or tag', aligning with the 'query' and 'category' parameters, but adds no additional semantic context beyond what the schema provides. This meets the baseline for high schema coverage.
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 clearly states the action ('Search'), the resource ('AI agent personas on ClawSouls'), and the methods ('by keyword, category, or tag'), making the purpose specific and actionable. It distinguishes from siblings like 'memory_search' by specifying the resource type (personas vs. memories).
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 usage for searching personas, but does not explicitly state when to use this tool versus alternatives like 'soul_get' (which might retrieve a specific persona) or 'soul_scan' (which might scan broadly). No exclusions or prerequisites are mentioned, leaving usage context somewhat open-ended.
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.4.0memory_detailmemory_searchmemory_statusmemory_syncsoul_getsoul_installsoul_rollback_checksoul_scansoul_searchEach tool has a clearly distinct purpose with no ambiguity. Memory tools (memory_detail, memory_search, memory_status, memory_sync) handle different aspects of memory management, while soul tools (soul_get, soul_install, soul_rollback_check, soul_scan, soul_search) each perform unique persona-related operations. The descriptions clearly differentiate their functions.
Tool names follow a perfectly consistent snake_case pattern with clear prefix organization. All memory tools start with 'memory_' and all persona tools start with 'soul_', creating predictable groupings. The verb+noun structure is maintained throughout (e.g., memory_search, soul_install).
With 9 tools, this server is well-scoped for its dual-domain purpose (memory management and persona management). The count allows comprehensive coverage without bloat, and each tool clearly earns its place in the workflow. This is an ideal number for the server's apparent scope.
The tool surface provides excellent coverage for both memory and persona domains. Memory tools support search, detail retrieval, status checking, and synchronization. Persona tools support discovery, installation, safety verification, drift detection, and information retrieval. The only minor gap is the lack of persona modification/update tools, but agents can work around this by reinstalling or using memory tools for customizations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Git-backed platform for skills, tools, and context for AI agents
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Shared memory for coding agents. Stop re-explaining your codebase every session.
AI-native project management + agent memory: tasks, sprints, risk, burnout, knowledge search.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/clawsouls/clawsouls-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
