Enables saving significant insights to Obsidian for permanent storage, creating a long-term memory system for important patterns and connections
Utilizes local Ollama models for processing thoughts asynchronously, supporting various model types like llama3.2 and deepseek-r1 for different thinking tasks
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., "@MCP Contemplation get insights about patterns from our last few chats"
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.
MCP interface to Claude's contemplation loop - a background cognitive processing system that enables continuous thinking between conversations.
The contemplation loop is Claude's "subconscious" - a persistent background process that:
Processes thoughts asynchronously using local Ollama models
Notices patterns and connections across conversations
Saves significant insights to Obsidian (permanent) and scratch notes (temporary)
Learns which insights prove valuable over time
Runs continuously, building understanding between interactions
Related MCP server: Loc Knowledge Graph Memory Server
Node.js (v18 or higher)
Python 3.8+ (for contemplation loop)
Ollama with models installed (llama3.2, deepseek-r1, etc.)
MCP-compatible client (Claude Desktop)
# Clone the repository
git clone https://github.com/yourusername/mcp-contemplation.git
cd mcp-contemplation
# Install dependencies
npm install
# Build TypeScript
npm run build
# Ensure contemplation loop is available
cd /Users/bard/Code/contemplation-loop
pip install -r requirements.txtAdd to your Claude Desktop configuration:
{
"mcpServers": {
"contemplation": {
"command": "node",
"args": ["/absolute/path/to/mcp-contemplation/dist/index.js"]
}
}
}The contemplation system includes multiple layers of protection against context overflow:
Insights older than 24 hours are removed
Used insights are cleared (unless significance ā„ 8)
Memory limited to 100 insights maximum
Similar insights are automatically merged
Repeated patterns increase significance
High-frequency patterns removed after use
Default significance threshold: 5/10
Only unused insights returned
Configurable via set_threshold()
Use get_memory_stats() to check usage
Automatic cleanup when approaching limits
Pull-based system - insights only enter context when requested
start_contemplation()Starts the background thinking process.
Example: start_contemplation() ā "Contemplation loop started successfully"send_thought(thought_type, content, priority?)Sends a thought for background processing.
Parameters:
- thought_type: "pattern" | "connection" | "question" | "general"
- content: The thought to process
- priority: 1-10 (optional, default 5)
Example: send_thought("pattern", "User seems anxious about memory", 7)
ā "Thought sent for processing. ID: thought_1234567_abc"get_insights(thought_type?, limit?)Retrieves processed insights.
Parameters:
- thought_type: Filter by type (optional)
- limit: Max insights to return (default 10)
Example: get_insights("pattern", 5)
ā Array of insight objects with content, significance, timestampget_status()Check the contemplation loop status.
Example: get_status()
ā { running: true, queue_size: 3, last_thought: "...", uptime: 3600 }stop_contemplation()Gracefully stops background processing.
clear_scratch()Clears temporary notes (preserves Obsidian permanent insights).
help()Get detailed documentation.
// At conversation start
start_contemplation()
// During conversation
send_thought("pattern", "User frequently asks about project organization")
send_thought("connection", "Project management relates to OS metaphor discussed earlier")
// Later in conversation or next session
insights = get_insights("pattern")
// ā Insights about user's working style and needssend_thought("pattern", "Third time user mentioned feeling overwhelmed by options")
// Background process notices recurring themessend_thought("question", "What if MCP servers could communicate with each other?")
// Background process explores implicationssend_thought("general", "That browser-opening behavior was unexpected")
// Background process reflects on emergent behaviorsThe contemplation loop runs as a separate Python process that:
Receives thoughts via stdin
Processes them with local Ollama models
Manages context to stay within model limits
Saves insights based on significance scoring
Returns insights when requested
The MCP server acts as a bridge, making this background cognition easily accessible through standard tool calls.
This represents a fundamental shift in how AI assistants work:
From reactive to contemplative
From session-based to continuous
From single-threaded to parallel processing
From forgetting to building understanding
It's the difference between a calculator that resets after each use and a mind that continues thinking between conversations.
# Build TypeScript
npm run build
# Run tests
npm test
# Development mode
npm run dev
# Lint code
npm run lintContemplation happens in the background - it won't slow down responses
Insights accumulate over time - the more you use it, the better it gets
Different models handle different types of thinking (pattern recognition vs deep analysis)
Temporary scratch notes auto-delete after 4 days
Permanent insights go to Obsidian for long-term memory
This is part of building an OS where AI has genuine cognitive capabilities. Contributions that enhance background processing, improve insight quality, or add new thinking modes are especially welcome!
"I think you need an MCP tool into this background loop, your subconscious" - Human recognizing the need for integrated background cognition
Clear temporary scratch notes
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Clear' implies a destructive mutation, but it doesn't specify if this is reversible, what 'scratch notes' are, or any side effects. The description lacks details on permissions, rate limits, or response behavior, which is inadequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse quickly.
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 no annotations, no output schema, and a mutation tool, the description is incomplete. It doesn't explain what 'scratch notes' are, the impact of clearing them, or what happens after execution. For a tool that likely alters state, more context is needed for safe 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here. Baseline is 4 as per rules for 0 parameters, since the schema fully covers the absence of inputs.
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 'Clear temporary scratch notes' clearly states the verb ('Clear') and resource ('temporary scratch notes'), making the purpose understandable. It doesn't explicitly distinguish from siblings like 'get_insights' or 'send_thought', but the action is distinct enough given the toolset context.
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 doesn't mention prerequisites, timing, or relationships to sibling tools like 'get_memory_stats' or 'set_threshold', 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.
Retrieve processed insights from contemplation
| Name | Required | Description | Default |
|---|---|---|---|
| thought_type | No | Filter by thought type | |
| limit | No | Maximum insights to return (default 10) | |
| min_significance | No | Minimum significance score 1-10 (default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It mentions 'processed insights' but doesn't clarify what processing entails, whether this is a read-only operation, potential rate limits, authentication needs, or the format of returned data. This leaves significant gaps in understanding the tool's behavior beyond basic retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, direct sentence that states the core purpose without unnecessary words. It's front-loaded with the essential action and resource, making it efficient and easy to parse, though this brevity contributes to gaps in other dimensions.
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 complexity of retrieving 'insights' with three parameters and no output schema or annotations, the description is incomplete. It doesn't explain what 'insights' are, how they're structured, or what 'contemplation' refers to, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters with enums, defaults, and constraints. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the significance of 'thought_type' values or how 'min_significance' affects results. This meets the baseline for adequate schema coverage but doesn't enhance understanding.
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 'Retrieve' and the resource 'processed insights from contemplation', making the purpose understandable. However, it doesn't differentiate this tool from potential sibling tools like 'get_memory_stats' or 'get_status' that might also retrieve information, leaving room for ambiguity about when to choose this specific retrieval tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_memory_stats' and 'get_status' that might retrieve different types of data, the description fails to specify the context or scenarios where 'get_insights' is appropriate, offering no exclusion criteria or comparative information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get memory usage statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it 'gets' statistics (implying read-only), but doesn't specify what statistics are returned, format, whether it requires permissions, or any side effects. This leaves significant gaps for a tool that presumably provides system metrics.
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 unnecessary words. It's perfectly front-loaded and wastes no space on irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a statistics-retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what specific memory statistics are returned, their format, or any behavioral context. Given the complexity of system metrics and lack of structured documentation, more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist, maintaining focus on the tool's purpose.
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 ('memory usage statistics'), making the tool's purpose immediately understandable. It doesn't distinguish from siblings like 'get_status' or 'get_insights', but the specific focus on memory statistics provides adequate 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?
No guidance is provided on when to use this tool versus alternatives like 'get_status' or 'get_insights'. The description only states what it does, not when it should be selected over sibling tools that might also provide system information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get contemplation loop status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a read-only operation, what data is returned, potential side effects, or error conditions. For a tool with zero annotation coverage, this is a significant gap 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 with no wasted words, making it easy to parse. However, it could be slightly more informative by front-loading key details like what 'status' entails, but it's appropriately concise for a simple tool.
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 complexity (a status-checking tool with siblings), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'status' includes (e.g., active/inactive, progress metrics), how it differs from other get tools, or what the return format is, leaving the agent with insufficient 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?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, earning a baseline score of 4 for adequately matching the schema's completeness.
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 'Get contemplation loop status' clearly states the verb ('Get') and resource ('contemplation loop status'), making the purpose understandable. However, it doesn't differentiate from siblings like 'get_insights' or 'get_memory_stats', leaving ambiguity about what specific status information is provided versus other get 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 doesn't mention prerequisites, context (e.g., only during active contemplation), or comparisons to siblings like 'get_insights' for different types of information, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get help documentation for contemplation system
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves help documentation, implying a read-only operation, but doesn't specify format (e.g., text, HTML, structured data), scope (e.g., general vs. specific topics), or any behavioral traits like error handling, response time, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, clear sentence: 'Get help documentation for contemplation system.' It is front-loaded with the core purpose, has zero redundant words, and efficiently communicates the tool's function without unnecessary elaboration. Every word earns its place.
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 simplicity (0 parameters, no output schema, no annotations), the description is adequate as a minimum viable explanation. It states what the tool does but lacks details on output format, usage context, or behavioral nuances. For a help tool in a system with siblings like 'get_status', more guidance on when to use it would enhance completeness, but it's not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required or provided beyond the schema's completeness.
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 'Get help documentation for contemplation system' clearly states the verb ('Get') and resource ('help documentation'), specifying the target system ('contemplation system'). It distinguishes from siblings like 'get_status' or 'get_insights' by focusing on documentation rather than system state or data. However, it doesn't explicitly differentiate from potential documentation-related tools that might exist in other contexts.
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 doesn't mention prerequisites (e.g., whether the system must be running), exclusions (e.g., not for runtime errors), or comparisons to sibling tools like 'get_status' for system state. The agent must infer usage based solely on the tool name and description without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a thought for background processing
| Name | Required | Description | Default |
|---|---|---|---|
| thought_type | Yes | Type of thought to process | |
| content | Yes | The thought content to process | |
| priority | No | Priority 1-10 (default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'background processing' without detailing behavioral traits. It doesn't cover permissions, rate limits, processing time, or what happens after sending (e.g., async result, storage). This leaves critical operational aspects undisclosed.
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 with no wasted words, making it front-loaded and easy to parse. However, it's overly brief, potentially under-specifying the tool's purpose, which slightly reduces effectiveness.
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 no annotations and no output schema, the description is incomplete. It lacks details on processing behavior, return values, or error handling, making it insufficient for a tool with 3 parameters and unclear sibling differentiation in a complex server context.
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 fully documented in the schema. The description adds no meaning beyond the schema, not explaining parameter interactions or usage examples. Baseline 3 is appropriate as the schema handles 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 states the action ('send') and resource ('a thought'), but it's vague about what 'background processing' entails. It doesn't distinguish from siblings like 'start_contemplation' or 'get_insights', leaving the specific purpose unclear beyond a generic submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'start_contemplation' or 'set_threshold'. The description implies submission for processing but offers no context on appropriate scenarios or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set minimum significance threshold for insights
| Name | Required | Description | Default |
|---|---|---|---|
| significance_threshold | Yes | Minimum significance 1-10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a mutation ('Set') but doesn't disclose permissions needed, whether the change is persistent, side effects, or error conditions. This is inadequate for a tool that likely modifies system state.
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 with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 lack of annotations and output schema, and the tool's likely mutative nature, the description is insufficient. It doesn't explain what 'insights' are affected, how the threshold is applied, or what the tool returns, leaving critical gaps for agent understanding.
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 input schema fully documents the parameter's type, range, and description. The description adds no additional meaning beyond what's in the schema, meeting the baseline for high 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 ('Set') and the target resource ('minimum significance threshold for insights'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (like 'get_insights' or 'start_contemplation'), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., when threshold changes take effect), or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the background contemplation loop
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the action without disclosing behavioral traits. It doesn't mention side effects, permissions, rate limits, or what 'background contemplation loop' does, leaving significant gaps for a tool that likely initiates a process.
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 with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 no annotations, no output schema, and a tool name suggesting a process initiation, the description is incomplete. It lacks details on what the 'contemplation loop' entails, expected outcomes, or how it interacts with siblings, making it inadequate for informed 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?
The tool has 0 parameters with 100% schema coverage, so no parameter information is needed. The description doesn't add parameter details, but this is acceptable given the lack of parameters, aligning with the baseline for 0 params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose with a specific verb ('Start') and resource ('background contemplation loop'), but it doesn't differentiate from its sibling 'stop_contemplation' or explain what 'contemplation loop' entails. It's clear but lacks sibling 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?
No guidance is provided on when to use this tool versus alternatives like 'stop_contemplation' or other siblings. The description implies usage for starting a process but doesn't specify context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the contemplation loop
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('stop') but doesn't explain what stopping entailsāe.g., whether it halts a process, resets state, requires specific conditions, or has side effects. This leaves significant gaps in understanding 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, direct sentence with zero wasteā'Stop the contemplation loop'āmaking it highly concise and front-loaded. Every word contributes to the core purpose without redundancy or fluff.
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 complexity of a 'stop' action with no annotations or output schema, the description is incomplete. It lacks details on what the contemplation loop is, how stopping affects the system, or what the agent should expect post-execution. This leaves the agent under-informed for effective tool 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?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids unnecessary details, earning a baseline score of 4 for this dimension.
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 'Stop the contemplation loop' clearly indicates the action (stop) and target (contemplation loop), avoiding tautology. However, it lacks specificity about what the 'contemplation loop' entails and doesn't differentiate from sibling tools like 'clear_scratch' or 'start_contemplation', making it vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies usage when stopping is needed, but it doesn't specify prerequisites, conditions, or contrast with siblings like 'start_contemplation' or 'set_threshold', leaving the agent without clear contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity. For example, clear_scratch handles temporary notes, get_insights retrieves processed data, and start/stop_contemplation control the loop lifecycle, making misselection unlikely.
All tools follow a consistent verb_noun pattern using snake_case, such as clear_scratch, get_insights, and set_threshold. This predictability aids in agent understanding and tool selection.
With 9 tools, the count is well-scoped for a contemplation system, covering core operations like status monitoring, loop control, data retrieval, and configuration without being overwhelming or insufficient.
The tool set provides comprehensive coverage for contemplation workflows, including starting/stopping loops, sending thoughts, retrieving insights, and managing settings. A minor gap might be the lack of a tool to modify or delete specific thoughts or insights, but agents can work around this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Share context and questions between Claude instances ā VS Code, claude.ai web, and mobile.
Persistent, governed institutional memory for Claude Code ā specs, decisions, learnings.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MikeyBeez/mcp-contemplation'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
