This server gives Claude persistent, cross-session context and learned instincts via MCP.
Manage static contexts: get tool-specific context, syntax rules, list available contexts, and apply auto-corrections.
Build combined injection payloads (contexts + instincts) for a given tool and input.
Manage instincts: list, store new candidates, approve, reject, and record outcomes with confidence changes.
Run as either stdio or HTTP MCP server, configurable via environment variables, with optional memory-bridge sync.
Use the mcp-cp CLI for instinct lifecycle management: list, show, approve, reject, tune confidence, record outcomes, import, and print the resolved store path.
Install as a Claude Code plugin or /instill skill, and optionally use the auto-trigger hook to suggest distilling sessions into instincts.
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 Context Provider load my GitHub workflow preferences and Jira syntax rules"
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.
Status: beta — feature-complete, API stabilizing. See CHANGELOG.md for the latest release.
https://github.com/user-attachments/assets/d9c6c325-00f1-44d9-a805-b1d6588c0acf
Persistent context and learned instincts for Claude Desktop and Claude Code — surviving across sessions.
A TypeScript MCP server that gives Claude persistent Contexts (static tool rules) and Instincts (learned, confidence-scored rules distilled from sessions). No more re-establishing context in every new chat.
Two core concepts:
Concept | Description | Size | Lifetime |
Context | Static tool rules, syntax preferences, auto-corrections | 200–1000 tokens | Permanent, manually authored |
Instinct | Learned rule extracted from sessions, confidence-scored | 20–80 tokens | Human-approved, evolves over time |
Four subsystems:
Engine — loads, matches, and merges contexts + instincts into injection payloads
MCP Server (src/server/index.ts) — stdio + HTTP transport, 10 MCP tools
CLI (mcp-cp) — approval registry for instinct lifecycle management
Memory Bridge — optional sync of instincts to mcp-memory-service
Related MCP server: Claude Memory MCP Server
git clone https://codeberg.org/doobidoo/MCP-Context-Provider.git
cd MCP-Context-Provider
npm install
npm run buildAdd to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"context-provider": {
"command": "node",
"args": ["/path/to/mcp-context-provider/dist/server/index.js"],
"env": {
"CONTEXTS_PATH": "/path/to/mcp-context-provider/contexts",
"INSTINCTS_PATH": "/path/to/mcp-context-provider/instincts"
}
}
}
}Add to ~/.mcp.json:
{
"mcpServers": {
"context-provider": {
"command": "node",
"args": ["/path/to/mcp-context-provider/dist/server/index.js"],
"env": {
"CONTEXTS_PATH": "/path/to/mcp-context-provider/contexts",
"INSTINCTS_PATH": "/path/to/mcp-context-provider/instincts"
}
}
}
}Important: Use absolute paths for both
argsandenvvalues. Claude Code does not support thecwdfield in MCP server configs — relative paths will resolve from the wrong directory and the server will fail to connect.
Install directly from the marketplace:
/plugin marketplace add codeberg/doobidoo/MCP-Context-Provider
/plugin install context-providerThis auto-configures the MCP server with correct paths — no manual .mcp.json editing needed.
/instill Skill (Claude Code)Install the skill globally (stays current with git pull):
mkdir -p ~/.claude/skills/instill
ln -s /path/to/mcp-context-provider/.claude/skills/instill.md ~/.claude/skills/instill/SKILL.mdThen use /instill at the end of productive sessions to distill learned patterns into instinct candidates.
The instill-trigger hook automatically detects mistakes during a session and nudges Claude to suggest /instill when a threshold is reached. It monitors:
User corrections (UserPromptSubmit) — "no not that", "that's wrong", "still broken", etc.
Tool failures (PostToolUse) — non-zero exit codes, tracebacks, permission errors
Install the hook:
cp hooks/instill-trigger.js ~/.claude/hooks/core/instill-trigger.jsRegister in ~/.claude/settings.json under both UserPromptSubmit and PostToolUse:
{
"type": "command",
"command": "node --no-warnings \"~/.claude/hooks/core/instill-trigger.js\"",
"timeout": 3
}Scoring: Corrections weighted 1.5x, tool failures 0.5x. Combined threshold: 3.0. Max 1 nudge per session. All tunable via CONFIG object in the hook file.
Tool | Description |
| Get complete context for a tool category |
| Get syntax-specific rules for a tool |
| List all loaded contexts |
| Apply correction patterns to text |
| Combined context + instinct injection payload |
| List all instincts with confidence scores, plus the resolved store path |
Variable | Default | Description |
| packaged | Path to |
|
| Path to |
| — | Memory service base URL (enables bridge) |
| — | API key for memory service |
|
| HTTP server port (only with |
The instincts store never depends on the directory the MCP host happened to launch the server from. It resolves in this order:
INSTINCTS_PATH — explicit override, always wins
./instincts — only when the working directory is an mcp-context-provider
checkout (the development case)
$XDG_DATA_HOME/mcp-context-provider/instincts — when XDG_DATA_HOME is set
~/.local/share/mcp-context-provider/instincts — the default
Contexts resolve the same way, except the fallback is the contexts/ directory
shipped with the package: contexts are authored and versioned with the code,
instincts are learned user data.
To see which store is active:
mcp-cp path # prints the resolved directory
node dist/server/index.js # logs both paths to stderr at startupThe resolved path is also part of the list_instincts response (store.path,
store.resolved_from) and of the /health payload in HTTP mode.
If the resolved store sits inside a git working tree that is not this repository's checkout, the server warns at startup — that is the signal it picked up a working directory by accident and that learned instincts are about to be committed somewhere they do not belong.
Merging a store from elsewhere:
mcp-cp import /path/to/learned.instincts.yaml --dry-run # preview
mcp-cp import /path/to/learned.instincts.yaml # mergeExisting ids are never overwritten — a merge only adds. Legacy file shapes
(top-level array, or instincts: as a list) are normalized on read.
Contexts are JSON files in contexts/*_context.json. Each file matches one or more tools via glob patterns and injects static rules.
{
"tool_category": "git",
"description": "Git workflow rules",
"auto_convert": false,
"metadata": {
"version": "1.0.0",
"applies_to_tools": ["git:*", "Bash"],
"priority": "high"
},
"syntax_rules": { ... },
"auto_corrections": {
"fix-1": { "pattern": "...", "replacement": "..." }
}
}Add a new context by dropping a *_context.json file in contexts/ and restarting the server.
Instincts are YAML files named *.instincts.yaml in the resolved store (see
Store Location). They are distilled from sessions via
/instill and require human approval.
version: "1.0"
instincts:
my-rule:
id: my-rule
rule: "Compact, actionable rule (20–80 tokens)."
domain: git
tags: [git, workflow]
trigger_patterns:
- "git commit"
confidence: 0.75
min_confidence: 0.5
approved_by: human
active: true
created_at: "2026-03-10T00:00:00Z"
outcome_log: []Manage instincts with the CLI:
mcp-cp list
mcp-cp show <id>
mcp-cp approve <id>
mcp-cp reject <id>
mcp-cp tune <id> --confidence 0.8
mcp-cp outcome <id> + "worked well"
mcp-cp path
mcp-cp import <file> [--into <name>] [--dry-run]npm run build # Compile TypeScript
npm run dev # Watch mode
npm run lint # Type-check only
npm test # Run tests (vitest)
npm start # stdio transport
npm run start:http # HTTP transport on port 3100/instill in Claude Desktop?No. /instill is a Claude Code skill (.claude/skills/instill.md) and only works in the Claude Code CLI. Claude Desktop does not have a skill system.
However, you can achieve the same result in Claude Desktop:
MCP tools work in both - The list_instincts and build_injection tools are available in Claude Desktop via the MCP server.
For the instill workflow, create a Claude Desktop Project and paste the instill instructions as Custom Instructions. Claude Desktop can then use desktop-commander or similar MCP servers to write YAML files.
The reason /instill is not exposed as an MCP tool: it is an interactive, multi-step workflow (analyze conversation, present candidates, await user decision, write YAML). MCP tools return a single response and cannot drive multi-turn interactions.
learned.instincts.yaml files contain sensitive data?Potentially yes. Instincts distilled from work sessions may contain internal hostnames, customer names, infrastructure details, or operational procedures.
This is why the default store is a user-level directory outside any repository
(~/.local/share/mcp-context-provider/instincts) and why the server warns when
the resolved store sits inside an unrelated git working tree. If you do point
INSTINCTS_PATH at a checkout, add instincts/learned.instincts.yaml to that
repository's .gitignore and review its contents before pushing.
Contexts | Instincts | |
Format | JSON ( | YAML ( |
Source | Manually authored | Distilled from sessions via |
Size | 200-1000 tokens | 20-80 tokens |
Matching | Tool-pattern globs | Regex trigger patterns |
Lifecycle | Static, versioned | Confidence-scored, evolves over time |
Approval | None needed | Requires |
See CHANGELOG.md.
Apache-2.0 — see LICENSE.
Apply auto-correction patterns from matching contexts to text
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to apply corrections to | |
| tool_name | Yes | Tool context to use for corrections |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states the high-level purpose. It does not mention whether the operation is read-only or destructive, what happens on failure, or any side effects like modifying underlying data.
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 short sentence, concise but lacking detail. It could be expanded while remaining efficient, e.g., by explaining the correction process or output.
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 output schema, the description should describe return values, but it does not. The tool has two required string parameters, and the description is too minimal to fully guide an agent on how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds 'from matching contexts' which loosely ties to the tool_name parameter, but does not provide additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool applies auto-correction patterns from matching contexts to text, which is a specific verb and resource. It distinguishes from siblings like 'get_syntax_rules' or 'list_available_contexts' by focusing on application rather than retrieval.
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 such as 'build_injection' or 'approve_instinct'. There is no mention of prerequisites or context-matching steps, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve an instinct for active use (sets approved_by to human)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Instinct ID to approve |
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 that it sets 'approved_by' to human, indicating a mutation. However, it does not disclose side effects, permission requirements, or whether the instinct must be in a specific state. A higher score would require more detail.
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 sentence with no extraneous information. It is front-loaded with the action and purpose, making it concise and easy to read.
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 low complexity (1 parameter, no output schema, no annotations), the description is minimal. It fails to mention the return value or confirmation of success, and does not address idempotency or preconditions. This is a significant gap for a state-changing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the single parameter 'id' ('Instinct ID to approve'). The description adds no additional meaning beyond what the schema provides. With 100% schema coverage, a baseline 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 verb 'Approve', the resource 'instinct', and the specific effect 'sets approved_by to human'. This distinguishes it from siblings like 'reject_instinct' and 'list_instincts'.
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 approving an instinct, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. The sibling tools suggest it is for approval, but explicit context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a complete injection payload (contexts + instincts) for a tool/input combination
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool name or pattern | |
| input | Yes | Input text to match instincts against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states what it does without disclosing behavioral traits like side effects, permissions, or output format. For a build operation, more transparency needed (e.g., whether it modifies 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?
Single sentence, no redundancy, efficiently communicates the core function.
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?
While simple, description lacks explanation of what an injection payload is, and no mention of output format or return value, leaving gaps for unfamiliar users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions; description adds marginal context by explaining the parameters are used to generate a payload with contexts and instincts, but does not significantly enhance understanding beyond 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?
Description clearly states the action 'Build' and the resource 'complete injection payload', specifying it combines contexts and instincts for a tool/input combination, which distinguishes it from sibling tools like list_instincts or get_tool_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 guidance on when to use this tool versus alternatives; does not mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get syntax-specific rules for a tool category
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | Tool name or category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description needs to disclose behavior. It only states what it gets, not side effects, auth needs, rate limits, or return format. Minimal 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?
Extremely concise: a single sentence of 7 words that is front-loaded and to the point. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fails to explain what 'syntax-specific rules' means or the structure of the response. Inadequate for an agent to fully understand the tool's output.
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 defines the parameter. The description adds no extra meaning beyond 'tool name or category', hence no additional value.
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 it retrieves 'syntax-specific rules for a tool category', which is a specific verb and resource. However, it does not differentiate from sibling tools like 'get_tool_context', making it slightly generic.
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 on when to use this tool versus its siblings or alternatives. There is no mention of prerequisites, when-not-to-use, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete context (rules, syntax, preferences) for a specific tool
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | Tool name or category (e.g. "git", "dokuwiki", "terraform") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description discloses that the tool returns 'rules, syntax, preferences' but does not mention safety (e.g., read-only) or any side effects. Minimal but adequate.
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?
Single, concise sentence with no extraneous words, effectively front-loading the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple interface (one parameter, no output schema), the description sufficiently explains the tool's return content, though it could hint at the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add extra meaning to the 'tool_name' parameter beyond the schema's existing example and description, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('complete context') and distinguishes from siblings like 'get_syntax_rules' by mentioning 'rules, syntax, preferences' as a comprehensive set.
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 on when to use this tool versus siblings like 'get_syntax_rules' or 'list_available_contexts', though the word 'complete' implies it is the comprehensive version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all loaded context categories and their descriptions
| 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. It accurately describes a read-only listing operation with no side effects. It does not mention edge cases like empty results or loading state, but for a simple list tool, this is acceptable.
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?
A single sentence that conveys the essential purpose without any extraneous information. It is highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description adequately explains the tool's function. It mentions what is listed (categories and descriptions), but lacks details about output format or error conditions. Still, it is sufficient for a straightforward listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined, so the baseline is 4. The description does not add parameter information because none are needed. It correctly implies no input is required.
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 (list) and the resource (loaded context categories), with a mention of also returning descriptions. It distinguishes from sibling tools like get_tool_context, which likely retrieves context for a specific tool. However, it could be more precise about what 'loaded' means.
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 (e.g., get_tool_context, list_instincts). The description gives no context about typical use cases or prerequisites. This leaves the agent without direction for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all loaded instincts with their confidence scores
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a read operation and mentions returning confidence scores, but lacks details on authentication, side effects, or behavior when no instincts are loaded. Without annotations, more info would be helpful.
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 that is front-loaded and concise. However, it could briefly mention the output structure without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description is adequate but does not specify if the list includes identifiers or if it is sorted/paginated. It mentions confidence scores but not other potential fields.
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?
No parameters exist, and the schema coverage is 100%. The description does not add parameter meaning beyond what is evident from the schema, which is fine but not additive.
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 that the tool lists loaded instincts with confidence scores, using a specific verb and resource. It is distinct from sibling tools like approve_instinct or reject_instinct.
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 on when to use this tool versus alternatives, such as before approving/rejecting an instinct. No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a positive, negative, or neutral outcome for an instinct
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Instinct ID | |
| result | Yes | Outcome result | |
| delta | Yes | Confidence change (e.g. +0.05 or -0.1) | |
| note | No | Optional note explaining the outcome |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It only says 'record an outcome' but does not mention side effects (e.g., updating confidence via delta), permissions, idempotency, or response behavior. The schema shows delta but description omits that detail.
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, well-structured sentence that is front-loaded with the verb and resource. No extraneous words.
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 4 parameters and no output schema or annotations, the description is too minimal. It does not explain return values, expected behavior on delta, or how this tool relates to siblings like approve_instinct. Essential context is missing.
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 having a description. The tool description adds no additional meaning beyond the schema, so 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 verb 'record' and the resource 'outcome for an instinct' and specifies the types (positive, negative, neutral). It distinguishes from sibling tools like approve_instinct or reject_instinct, which serve different purposes.
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 this tool is for recording outcomes but provides no explicit guidance on when to use it versus alternatives like approve_instinct, reject_instinct, or store_instinct. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reject/deactivate an instinct and lower its confidence
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Instinct ID to reject |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the main effect (reject/deactivate and lower confidence) but lacks details on side effects, permissions, or reversibility, which are important for a mutation tool without annotations.
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 concise sentence that immediately conveys the tool's purpose, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is fairly complete in stating the action, but could benefit from mentioning return values or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'id' parameter (100% coverage). The description adds behavioral context (lowering confidence) but does not enhance the parameter's meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'reject' and 'deactivate' identifying the tool's action on an 'instinct', clearly distinguishing it from siblings like 'approve_instinct'.
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 (e.g., approve_instinct, record_outcome). It does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a new instinct candidate. Created as inactive with auto approval — use approve_instinct for human approval.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique kebab-case ID (e.g. "git-conventional-commits") | |
| rule | Yes | The instinct rule text (20-80 tokens) | |
| domain | Yes | Knowledge domain (e.g. "git", "typescript", "docker") | |
| tags | Yes | Tags for matching and categorization | |
| trigger_patterns | Yes | Regex patterns that trigger this instinct | |
| confidence | No | Initial confidence 0.0-1.0 (default 0.6) | |
| filename | No | Target YAML file (default "learned.instincts.yaml") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It mentions 'inactive with auto approval' but this is ambiguous and does not clarify side effects, permissions, or behavior on duplicate IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words; the core purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description fails to explain the return value or behavior on conflicts. The auto approval note is confusing and 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?
Schema description coverage is 100%, so the description adds no extra meaning beyond the well-documented parameters. 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 'Store a new instinct candidate' using a specific verb and resource, distinguishing it from siblings like approve_instinct and reject_instinct.
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?
It indicates when to use this tool versus approve_instinct by noting 'use approve_instinct for human approval', providing clear context for selection.
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.
v2.0.0-alpha.7apply_auto_correctionsapprove_instinctbuild_injectionget_syntax_rulesget_tool_contextlist_available_contextslist_instinctsrecord_outcomereject_instinctstore_instinctEach tool targets a distinct aspect of context or instinct management, but 'list_available_contexts' and 'get_tool_context' both involve contexts, and 'apply_auto_corrections' and 'build_injection' both produce text modifications, creating minor potential for confusion.
All tool names use snake_case and follow a consistent verb_noun pattern (e.g., approve_instinct, list_instincts), making them predictable and easy to parse.
With 10 tools covering context retrieval, instinct lifecycle, and corrections, the set is well-scoped for its purpose without unnecessary redundancy.
Core workflows are covered, but there is no tool to update an instinct's details (e.g., change description) beyond recording outcomes and approval, leaving a minor gap.
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 memory for Claude Code and Cursor. Stop re-explaining your project every session.
Stop re-explaining yourself to Agents. Give it the right context, right when needed.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/doobidoo/MCP-Context-Provider'
If you have feedback or need assistance with the MCP directory API, please join our Discord server