The MCP Creator Growth server is a learning companion and debugging assistant for AI coding tools that helps developers understand AI-generated code while providing persistent, project-specific debugging memory.
Interactive Learning Sessions: Create quizzes based on recent code changes to test understanding of logic, security, performance, architecture, or syntax. The server blocks AI execution until the developer completes the quiz via WebUI, ensuring active learning with structured 5-Why analysis reasoning.
Smart Debugging Memory: Automatically search past debugging solutions when errors occur using silent RAG (Retrieval-Augmented Generation). After fixes, the server automatically records debugging experiences—including error type, context, root cause, and solution—building a project-specific knowledge base that prevents redundant problem-solving.
Programming Term Reference: Fetch definitions for programming terms from various domains (basics, algorithms, data structures, web dev, etc.) while tracking shown terms to avoid repetition.
Project-Specific Memory: Maintains persistent knowledge bases in each project's .mcp-sidecar/ directory, enabling cross-session learning with separate databases per project.
Privacy & Local Control: All data is stored locally with no external telemetry. Users have full control—simply delete .mcp-sidecar/ to reset. Works with Claude Code, Cursor, Windsurf, and other MCP-compatible IDEs.
Automatic Tool Triggers: Debug tools (debug_search and debug_record) work silently in the background, while learning sessions require explicit user requests.
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 Creator Growth Quiz me on the changes you just made to ensure I understand the logic."
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.
A context-aware Model Context Protocol (MCP) server that acts as a learning sidecar for AI coding assistants. It helps developers learn from AI-generated code changes through interactive quizzes and provides agents with a persistent project-specific debugging memory.
Resource | Description |
Official MCP server listing with installation guides | |
AI-generated deep analysis of the codebase | |
Source code, issues, and contributions |
Related MCP server: claude-engram
For | Benefit |
Developers | Don't just accept AI code—understand it. Request a quiz to verify your grasp of the logic, security, or performance implications. |
AI Agents | Stop solving the same bug twice. The server quietly records debugging solutions and retrieves them automatically when similar errors occur. |
The MCP server in this repo is free and open-source (MIT) — run it locally, no account required.
The optional hosted learning ledger is free too: sign in with
GitHub, then run COVATE_SYNC_URL=https://covate.org COVATE_SYNC_TOKEN=<your token> python -m covate.platform_sync from a project to push your local sessions up and review them in a browser:
☁️ Sync your learning sessions from any machine
📖 Every synced session, newest first, with its score
📊 Totals — sessions, questions, correct answers, running accuracy
🎯 The topics you answer worst, ranked
🔑 Your sync token — reveal or rotate it whenever you want
Not built yet, so not promised: progress-over-time charts, spaced-repetition study plans, team accounts. There is no paid tier and nothing to buy — the MCP works fully without the ledger, and the ledger costs nothing.
Tool | Type | Description |
| 🎓 Interactive | Opens a WebUI quiz based on recent code changes. Blocks until user completes learning. |
| 🔍 Silent RAG | Searches project debug history for relevant past solutions. Auto-triggered on errors. |
| 📝 Silent | Records debugging experiences to project knowledge base. Auto-triggered after fixes. |
| 📚 Reference | Fetches programming terms/concepts. Tracks shown terms to avoid repetition. |
Trigger: User explicitly requests (e.g., "Quiz me", "Test my understanding")
Parameters:
Parameter | Type | Default | Description |
| string |
| Project directory path |
| string | — | Structured summary of Agent's actions |
| object | null | 5-Why reasoning (goal, trigger, mechanism, alternatives, risks) |
| array | auto-generated | 3 quiz questions with options, answer, explanation |
| array |
| Focus areas: logic, security, performance, architecture, syntax |
| int | 600 | Timeout in seconds (60-7200) |
Returns: {"status": "completed", "action": "HALT_GENERATION"}
Trigger: Auto-called when encountering errors (silent, no UI)
Parameters:
Parameter | Type | Default | Description |
| string | — | Error message or description to search |
| string |
| Project directory path |
| string | null | Filter by error type (e.g., ImportError) |
| array | null | Filter by tags |
| int | 5 | Maximum results (1-20) |
Returns: {"results": [...], "count": N}
Trigger: Auto-called after fixing bugs (silent, background)
Parameters:
Parameter | Type | Default | Description |
| object | — | Error context: |
| string | — | Root cause analysis |
| string | — | Solution that worked |
| string |
| Project directory path |
| array | null | Tags for categorization |
Returns: {"ok": true, "id": "..."}
Available Domains: programming_basics, data_structures, algorithms, software_design, web_development, version_control, testing, security, databases, devops
Parameters:
Parameter | Type | Default | Description |
| string |
| Project directory path |
| int | 3 | Number of terms (1-5) |
| string | null | Filter by domain |
Returns: {"terms": [...], "count": N, "remaining": N}
curl -fsSL https://raw.githubusercontent.com/SunflowersLwtech/covate/main/scripts/install.sh | bashirm https://raw.githubusercontent.com/SunflowersLwtech/covate/main/scripts/install.ps1 | iexThe installer will:
Auto-detect your Python environment (uv → conda → venv)
Clone the repository to ~/covate
Create virtual environment and install dependencies
Print the exact command to configure your IDE
Prerequisites: Python 3.11+ or uv
# 1. Clone the repository
git clone https://github.com/SunflowersLwtech/covate.git
cd covate
# 2. Create virtual environment and install
# Using uv (recommended)
uv venv --python 3.11 covate
source covate/bin/activate # macOS/Linux
# covate\Scripts\activate # Windows
uv pip install -e '.[dev]'
# Or using standard venv
python -m venv covate
source covate/bin/activate # macOS/Linux
# covate\Scripts\activate # Windows
pip install -e '.[dev]'Prerequisites: Docker installed on your system
# 1. Pull from Docker Hub
docker pull sunflowerslwtech/covate:latest
# Or build locally
git clone https://github.com/SunflowersLwtech/covate.git
cd covate
docker build -t covate .
# 2. Run with Docker
docker run -i covate
# 3. Or use Docker Compose
docker-compose up -dFor detailed Docker usage, persistent storage, and Claude Desktop integration, see DOCKER.md.
After installation, configure your AI coding IDE to use this MCP server.
Option 1: CLI (Recommended)
# macOS / Linux
claude mcp add covate -- ~/covate/covate/bin/covate
# Windows
claude mcp add covate -- %USERPROFILE%\covate\covate\Scripts\covate.exeOption 2: Config File
Add to ~/.claude.json:
{
"mcpServers": {
"covate": {
"command": "~/covate/covate/bin/covate"
}
}
}For Windows:
{
"mcpServers": {
"covate": {
"command": "C:\\Users\\YourName\\covate\\covate\\Scripts\\covate.exe"
}
}
}Example paths:
Unix (uv): ~/covate/covate/bin/covate
Windows (uv): C:\\Users\\YourName\\covate\\covate\\Scripts\\covate.exe
Windows (conda): C:\\Users\\YourName\\anaconda3\\envs\\covate\\Scripts\\covate.exe
Path breakdown (Unix example):
~/covate → repository directory
covate → virtual environment directory created by uv/venv
bin/covate → executable
Add to Cursor MCP settings (Settings → MCP → Add Server):
{
"covate": {
"command": "~/covate/covate/bin/covate"
}
}For Windows:
{
"covate": {
"command": "C:\\Users\\YourName\\covate\\covate\\Scripts\\covate.exe"
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"covate": {
"command": "~/covate/covate/bin/covate"
}
}
}To use Docker with any MCP-compatible IDE:
{
"mcpServers": {
"covate": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-v",
"/path/to/your/project:/workspace",
"-w",
"/workspace",
"covate"
]
}
}
}See DOCKER.md for detailed Docker configuration examples for Claude Desktop, Cursor, and other IDEs.
For any MCP-compatible IDE, use these settings:
Command: <install-path>/covate/bin/covate (or covate\Scripts\covate.exe on Windows)
Transport: stdio
After configuration, restart your IDE.
Tool | Trigger | For | Returns |
| User explicit request | User |
|
| Automatic (on error) | Agent | Compact summaries |
| Automatic (after fix) | Agent |
|
Say to your AI assistant:
"Quiz me on this change"
"Test my understanding"
"Help me learn about what you did"
The agent will create an interactive learning card and wait until you complete it.
Note: Quiz scores are saved locally for your self-tracking but are NOT returned to the agent - this keeps the context clean.
The debug tools work silently in the background:
Search first: When encountering errors, agent searches past solutions
Record after: When fixing errors, agent records the solution
Progressive disclosure: Returns compact summaries, not full records
Fast lookups: Uses inverted index for keyword-based searches
The remote update script automatically detects your installation and works with any path format (including Chinese/non-ASCII paths):
curl -fsSL https://raw.githubusercontent.com/SunflowersLwtech/covate/main/scripts/update.sh | bashirm https://raw.githubusercontent.com/SunflowersLwtech/covate/main/scripts/update.ps1 | iexThe update script will:
Auto-detect your installation location (supports multiple installations)
Pull the latest changes from the repository
Force-reinstall dependencies to ensure version synchronization
Verify installation integrity and report any issues
Detect if MCP server is in use and provide clear instructions
Why remote update?
✅ Works with Chinese/non-ASCII paths without
cdnavigation✅ Always uses the latest update logic from the repository
✅ Auto-detects installation location even if you forgot where it is
✅ Handles multiple installations gracefully
macOS / Linux:
~/covate/scripts/update.shWindows (PowerShell):
~\covate\scripts\update.ps1# Navigate to installation directory
cd ~/covate # or your custom installation path
# Pull latest changes
git pull origin main
# Update dependencies
# Using uv
source covate/bin/activate # macOS/Linux
# covate\Scripts\activate # Windows
uv pip install -e '.[dev]' --upgrade
# Or using standard venv
source covate/bin/activate # macOS/Linux
# covate\Scripts\activate # Windows
pip install -e '.[dev]' --upgrade
Aspect | Details |
Local First | All data stored in |
No Telemetry | Zero data sent to external servers |
Full Control | Delete |
We're building toward a Personalized Learning Center that grows with you. Here's what's coming:
Feature | Description |
SQLite FTS5 | Full-text search with Chinese support, prefix matching, and boolean queries |
BM25 Ranking | Industry-standard relevance scoring for better search results |
Semantic Search | Vector embeddings for meaning-based matching (e.g., "权限错误" finds "permission denied") |
Cross-project Search | Search debug experiences across all your projects |
Feature | Description |
Learning History Sync | Access your quiz history and learning progress on mobile |
Spaced Repetition | Smart review scheduling based on forgetting curves |
Offline Mode | Learn anywhere, sync when connected |
Push Notifications | Gentle reminders to review concepts you're forgetting |
Feature | Description |
Knowledge Graph | Visual map of concepts you've learned and their connections |
Weakness Analysis | AI identifies areas where you struggle and suggests focused practice |
Learning Streaks | Gamification to keep you motivated |
Team Insights | (Optional) Share anonymized learning patterns with your team |
Feature | Description |
Adaptive Quizzes | Questions adjust difficulty based on your performance |
Code Pattern Recognition | Learn from patterns in your own codebase |
Multi-language Support | Explanations in your preferred language |
Voice Interface | "Hey Claude, quiz me on what we did yesterday" |
Want to influence the roadmap? Open an issue or join the discussion!
Variable | Default | Description |
|
| Enable debug logging ( |
|
| MCP server startup timeout in ms |
|
| Maximum tokens for MCP output |
We welcome contributions! Please follow these steps:
Fork the repository
Create a feature branch: git checkout -b feature/amazing-feature
Install dev dependencies: uv pip install -e '.[dev]'
Make changes and run tests: pytest
Submit a Pull Request
See CONTRIBUTING.md for detailed guidelines.
Channel | Address |
GitHub Issues |
This project is licensed under the MIT License.
Record debug solution. AUTO-call silently after fixing errors.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | ||
| cause | Yes | ||
| solution | Yes | ||
| project_directory | No | . | |
| tags | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It mentions the tool operates 'silently' (implying no user notification) and is 'AUTO-call' (suggesting automated invocation), but doesn't describe what 'record' means operationally, whether data is persisted, what format is used, or any side effects. For a tool with 5 parameters and complex input schema, this is insufficient behavioral 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 concise with two brief sentences that are front-loaded with the core purpose. However, the second sentence about 'AUTO-call' could be more clearly integrated with the first, and the overall brevity comes at the cost of completeness for such a parameter-rich 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 tool has 5 parameters with 0% schema coverage, nested objects in the input schema, and an output schema exists, the description is inadequate. It doesn't explain the purpose of the complex 'context' object, the meaning of parameters, or what the tool actually does beyond 'record'. The existence of an output schema helps, but the description should provide more operational context for proper tool selection.
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?
With 0% schema description coverage and 5 parameters (3 required), the description provides no information about any parameters. It doesn't explain what 'context', 'cause', 'solution', 'project_directory', or 'tags' represent or how they should be used. The description fails to compensate for the complete lack of schema documentation.
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 as 'Record debug solution' which indicates it logs debugging information, but it's vague about what exactly gets recorded and how. The phrase 'AUTO-call silently after fixing errors' adds context about usage timing but doesn't clearly distinguish this from sibling tools like debug_search or learning_session.
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 implied usage guidance with 'AUTO-call silently after fixing errors' which suggests this should be invoked automatically after error resolution, but it doesn't explicitly state when to use this versus alternatives like debug_search or when NOT to use it. No prerequisites or comparison to siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search debug history for past solutions. AUTO-call silently on errors.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| project_directory | No | . | |
| error_type | No | ||
| tags | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output 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. It discloses the 'AUTO-call silently' behavior, which is a key trait not in the schema. However, it lacks details on permissions, rate limits, or what 'debug history' entails, leaving gaps in behavioral understanding for a search tool with multiple parameters.
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 highly concise and front-loaded, with two sentences that directly state the purpose and usage. Every word earns its place, making it efficient and easy to understand without unnecessary 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?
Given the tool's complexity (5 parameters, no annotations, but has an output schema), the description is incomplete. It covers purpose and auto-call behavior but misses parameter details and behavioral traits. The output schema might help with return values, but the description doesn't provide enough context for effective use, scoring it as minimally adequate.
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 0%, so the description must compensate for all 5 parameters. It only implies 'query' through 'Search' and 'error_type' through 'on errors,' but doesn't explain 'project_directory,' 'tags,' or 'limit.' This insufficient coverage results in a low score, as most parameters remain undocumented.
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: 'Search debug history for past solutions.' It specifies the resource (debug history) and the action (search for solutions). However, it doesn't explicitly differentiate from sibling tools like 'debug_record' or 'learning_session', which might have overlapping functionality, so it doesn't reach the highest score.
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 usage context with 'AUTO-call silently on errors,' indicating it should be invoked automatically when errors occur. This gives explicit guidance on when to use it, though it doesn't mention when not to use it or name alternatives among sibling tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interactive quiz card. Call ONLY when user says 'quiz me' or 'test me'. Blocks until done.
| Name | Required | Description | Default |
|---|---|---|---|
| project_directory | No | . | |
| summary | No | I have completed the requested task. | |
| reasoning | No | ||
| quizzes | No | ||
| focus_areas | No | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output 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 adds valuable context: 'Blocks until done' indicates this is a synchronous, blocking operation that may take time, which is crucial for an agent to understand execution flow. However, it doesn't disclose other behavioral traits like error handling, authentication needs, or rate limits, leaving some 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 extremely concise and front-loaded: it's a single sentence with three key pieces of information (what it is, when to use it, behavioral trait). Every word earns its place with zero waste, 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 the tool has 6 parameters with 0% schema coverage and no annotations, the description is incomplete. It covers usage and blocking behavior but ignores all parameters and doesn't explain the interactive quiz functionality in detail. The presence of an output schema helps, but the description should provide more context about inputs and quiz mechanics to be fully 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?
Schema description coverage is 0%, meaning none of the 6 parameters are documented in the schema. The description provides no information about any parameters—it doesn't mention project_directory, summary, reasoning, quizzes, focus_areas, or timeout. This fails to compensate for the lack of schema documentation, leaving parameters entirely unexplained.
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 is an 'Interactive quiz card' which gives a general purpose, but it's vague about what specific action it performs. It mentions 'Call ONLY when user says 'quiz me' or 'test me'' which adds context but doesn't clearly specify the verb+resource combination (e.g., 'initiates a quiz session' or 'presents quiz questions'). It distinguishes from siblings by its interactive nature, but the purpose remains somewhat ambiguous.
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 usage guidelines: 'Call ONLY when user says 'quiz me' or 'test me''. This clearly states when to use the tool (in response to specific user prompts) and implies when not to use it (for other purposes). It doesn't name alternatives, but given the sibling tools (debug_record, debug_search, term_get) are unrelated to quizzes, this is sufficient for strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get unshown programming terms. Domains: programming_basics, algorithms, web_development, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| project_directory | No | . | |
| count | No | ||
| domain | No |
| Name | Required | Description |
|---|---|---|
No output 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 mentions 'Get unshown programming terms' but lacks details on permissions, rate limits, side effects, or return format. The agent must infer behavior from the name and limited description, which is insufficient for a mutation or data retrieval 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 concise with two sentences that efficiently state the purpose and domains. It's front-loaded with the core function, though it could be slightly more structured (e.g., by listing parameters).
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 has an output schema (which covers return values), the description's gaps in parameter semantics and behavioral transparency are partially mitigated. However, with no annotations and 0% schema coverage, it still lacks completeness for a tool with three parameters and unclear behavioral traits.
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 description coverage is 0%, so the description must compensate. It only hints at the 'domain' parameter with examples but doesn't explain 'project_directory' or 'count'. This leaves two parameters undocumented, failing to add sufficient meaning beyond the bare 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 with a specific verb ('Get') and resource ('unshown programming terms'), and it provides domain examples like 'programming_basics, algorithms, web_development, etc.' However, it doesn't explicitly differentiate from sibling tools (e.g., debug_record, debug_search, learning_session), which prevents a perfect score.
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 the sibling tools. It mentions domains but doesn't specify contexts or exclusions for usage, leaving the agent with minimal direction.
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.
debug_recorddebug_searchlearning_sessionterm_getThe tools have mostly distinct purposes: debug_record and debug_search are both for debugging but focus on recording vs. searching, learning_session is for interactive quizzes, and term_get is for retrieving programming terms. There is some overlap between debug_record and debug_search in the debugging domain, but their descriptions clarify the difference, preventing significant confusion.
The naming is mixed: debug_record and debug_search follow a verb_noun pattern, but learning_session uses a noun-based name, and term_get uses a noun_verb pattern. This inconsistency makes the set less predictable, though the names are still readable and descriptive overall.
With 4 tools, the count is borderline for a 'Creator Growth' server, which suggests a broader scope. It feels slightly thin, as it covers debugging, learning, and terminology but lacks depth in areas like code creation or feedback tools that might be expected for growth-oriented purposes.
For a 'Creator Growth' domain, there are significant gaps: no tools for creating or editing code, providing feedback, tracking progress, or managing projects. The tools focus narrowly on debugging, quizzes, and terminology, leaving core growth workflows like iterative development or skill assessment uncovered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared debugging memory for AI coding agents
AI colleagues that keep your standards, your project and their reasoning between sessions
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SunflowersLwtech/covate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
