Help Center

Troubleshooting Guide

Solutions to common Stompy issues. Search by symptom, error message, or topic.

37 results

|

Symptoms

  • Claude says "Stompy tools not available"
  • SSE connection fails
  • No Stompy tools appear in Claude Desktop

Why this happens

The claude_desktop_config.json file has incorrect syntax, is in the wrong location, or your bearer token is invalid.

Solution

1. Verify your config file location: - **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json` - **Windows**: `%APPDATA%\Claude\claude_desktop_config.json` 2. Ensure your bearer token is correct (get it from your Stompy dashboard) 3. Check your JSON syntax (no trailing commas, proper quotes) 4. **Completely restart Claude Desktop** (quit and reopen, not just close window) 5. Check Claude Desktop logs for errors

Example

{
"mcpServers": {
"stompy": {
"url": "https://mcp.stompy.ai/sse",
"transport": "sse",
"headers": {
"Authorization": "Bearer YOUR_TOKEN_HERE"
}
}
}
}

Symptoms

  • Claude Desktop shows config error on startup
  • MCP servers fail to load
  • JSON parse error in logs

Why this happens

The claude_desktop_config.json file contains invalid JSON syntax such as trailing commas, missing quotes, or mismatched brackets.

Solution

1. Open your config file in a JSON validator (like jsonlint.com) 2. Common issues to check: - No trailing comma after the last item in objects/arrays - All keys must be in double quotes - No comments allowed in JSON 3. Use a code editor with JSON syntax highlighting 4. After fixing, restart Claude Desktop completely

Example

// WRONG - has trailing comma
{
"mcpServers": {
"stompy": {
"url": "https://mcp.stompy.ai/sse",
"transport": "sse",
"headers": {
"Authorization": "Bearer token", // <- Remove this comma!
}
}
}
}
// CORRECT
{
"mcpServers": {
"stompy": {
"url": "https://mcp.stompy.ai/sse",
"transport": "sse",
"headers": {
"Authorization": "Bearer YOUR_TOKEN_HERE"
}
}
}
}

Symptoms

  • Connection to Stompy server failed
  • SSE endpoint unreachable
  • Network error when connecting

Why this happens

The SSE connection to Stompy servers cannot be established. This may be due to network issues, firewall restrictions, or server maintenance.

Solution

1. Verify the SSE URL is correct in your config: `https://mcp.stompy.ai/sse` 2. Check your internet connection 3. Try accessing https://mcp.stompy.ai in your browser 4. If behind a corporate firewall, ensure SSE connections are allowed 5. Check Stompy status page for any service outages 6. Verify your bearer token is valid and not expired

Example

{
"mcpServers": {
"stompy": {
"url": "https://mcp.stompy.ai/sse",
"transport": "sse",
"headers": {
"Authorization": "Bearer YOUR_TOKEN_HERE"
}
}
}
}

Symptoms

  • Unauthorized error when using Stompy tools
  • Token expired or invalid
  • Authentication failed
  • 401 or 403 errors

Why this happens

Your Stompy bearer token is missing, expired, or incorrectly configured in the Authorization header.

Solution

1. Get your token from the Stompy dashboard (https://www.stompy.ai/dashboard) 2. Add your token to the config with the "Bearer " prefix: ```json { "mcpServers": { "stompy": { "url": "https://mcp.stompy.ai/sse", "transport": "sse", "headers": { "Authorization": "Bearer YOUR_TOKEN_HERE" } } } } ``` 3. Ensure "Bearer " prefix is included (with a space after Bearer) 4. Check if your token has expired in the dashboard 5. Restart Claude Desktop after updating the token

Symptoms

  • New user, tools not working
  • Unsure if setup is correct
  • Want to verify installation

Why this happens

First-time setup requires several steps to be completed in the correct order.

Solution

**Complete Setup Checklist:** 1. ✅ Stompy account created at stompy.ai 2. ✅ Bearer token obtained from dashboard 3. ✅ claude_desktop_config.json created in correct location: - macOS: ~/Library/Application Support/Claude/ - Windows: %APPDATA%\Claude\ 4. ✅ SSE config with correct URL and token 5. ✅ Config JSON syntax is valid (no trailing commas) 6. ✅ Claude Desktop completely restarted 7. ✅ Test with: "Use project_list to show my Stompy projects" **Quick test command to ask Claude:** "Can you run project_list() to verify Stompy is connected?"

Example

{
"mcpServers": {
"stompy": {
"url": "https://mcp.stompy.ai/sse",
"transport": "sse",
"headers": {
"Authorization": "Bearer YOUR_TOKEN_HERE"
}
}
}
}
Related tools:project_list

Symptoms

  • One MCP server works but not others
  • Tools from different servers mixed up
  • Intermittent connection issues

Why this happens

When running multiple MCP servers, they may have conflicting tool names or resource contention.

Solution

1. Check each server is using a unique name in config: ```json { "mcpServers": { "stompy": { ... }, "other-server": { ... } } } ``` 2. Ensure servers don't have overlapping tool names 3. If issues persist, temporarily disable other servers to isolate the problem 4. Check Claude Desktop logs for specific error messages 5. Each MCP server runs as a separate process - verify all are starting

Symptoms

  • Unsure where to add bearer token
  • Token not being recognized
  • Need to configure authentication

Why this happens

Stompy uses bearer token authentication in the HTTP headers of the SSE connection.

Solution

Your bearer token goes directly in the config file's headers section: 1. Get your token from https://www.stompy.ai/dashboard 2. Add it to your claude_desktop_config.json with the "Bearer " prefix: ```json { "mcpServers": { "stompy": { "url": "https://mcp.stompy.ai/sse", "transport": "sse", "headers": { "Authorization": "Bearer YOUR_TOKEN_HERE" } } } } ``` 3. Replace YOUR_TOKEN_HERE with your actual token 4. Restart Claude Desktop completely **Important:** The token goes in the config file, not in environment variables.

Symptoms

  • Features not working as documented
  • Unexpected tool behavior
  • New parameters or options available

Why this happens

Stompy is a hosted service that receives regular updates. New features or changes may affect tool behavior.

Solution

1. Check the Stompy changelog at stompy.ai/dashboard for recent updates 2. Stompy is a hosted service - updates happen automatically server-side 3. Restart Claude Desktop to refresh the tool list 4. If a tool has new parameters, check the updated documentation 5. Report unexpected behavior via bug_report: ``` bug_report( title="Tool behavior changed", description="Describe what changed", severity="medium" ) ```
Related tools:bug_report

Symptoms

  • recall_context returns "not found"
  • Context exists but cannot be retrieved
  • Topic name not recognized

Why this happens

The topic name does not exist, has a typo, or you are looking in the wrong project.

Solution

1. List all contexts to find the exact topic name: ``` context_explore() ``` 2. Check you're in the correct project: ``` project_list() project_switch("correct-project") ``` 3. Use search to find similar topics: ``` context_search("partial topic name") ``` 4. Topic names are case-sensitive - verify exact spelling 5. Check if context was archived/deleted with db_query

Example

// Find all contexts in current project
context_explore()
// Search for contexts about authentication
context_search("authentication")
// Recall with exact topic name
recall_context("auth-api-rules")
Related tools:recall_contextcontext_explorecontext_search

Symptoms

  • lock_context fails with "novelty" error
  • Content rejected as redundant
  • "Delta evaluation: <10% novelty" message

Why this happens

Stompy prevents storing duplicate content. If your new context is more than 90% similar to existing contexts, it will be rejected to prevent clutter.

Solution

1. First, search for existing similar contexts: ``` context_search("your topic keywords") ``` 2. If the content already exists, use recall_context instead 3. If you need to update existing content, it creates a new version automatically 4. To force store despite similarity (use sparingly): ``` lock_context( content="...", topic="my-topic", force_store=True ) ``` 5. Consider if you really need separate contexts or should update existing one

Example

// Check what similar content exists
context_search("API authentication rules")
// If updating, just lock with same topic (creates new version)
lock_context(
content="Updated auth rules...",
topic="auth-rules" // Same topic = new version
)
// Force store if intentionally similar
lock_context(
content="Similar but distinct content...",
topic="auth-rules-v2",
force_store=True
)
Related tools:lock_contextcontext_searchrecall_context

Symptoms

  • Need older version of context
  • Want to see version history
  • Accidentally overwrote content

Why this happens

Contexts are versioned (1.0, 1.1, etc.) and you may need to access a specific version rather than the latest.

Solution

1. Get the latest version (default): ``` recall_context("my-topic") ``` 2. Get a specific version: ``` recall_context("my-topic", version="1.0") ``` 3. See version history with db_query: ``` db_query( "SELECT version, created_at FROM context_locks WHERE label = %s ORDER BY version", params=["my-topic"] ) ``` 4. All versions are preserved - originals are never deleted when you update

Example

// Get latest version
recall_context("api-spec")
// Get original version
recall_context("api-spec", version="1.0")
// Get specific version
recall_context("api-spec", version="1.2")
Related tools:recall_contextdb_query

Symptoms

  • Unsure which priority to use
  • Context not appearing in searches
  • Critical rules being missed

Why this happens

Stompy has three priority levels that affect how contexts are retrieved and displayed.

Solution

**Priority Levels:** 1. **always_check** - Critical rules, must never be forgotten - Use for: MUST/NEVER rules, security requirements, critical configs - These surface first in searches - Require `force=True` to delete 2. **important** - Frequently needed information - Use for: API specs, architecture decisions, common patterns - Default for most documentation 3. **reference** - Occasionally useful (default) - Use for: Examples, historical context, nice-to-know info - Lower priority in search results **Tip:** Start with "reference" and upgrade to "important" or "always_check" as needed.

Example

// Critical security rule
lock_context(
content="NEVER store passwords in plain text",
topic="security-rules",
priority="always_check"
)
// Important API documentation
lock_context(
content="API uses JWT with 15min expiry...",
topic="api-auth",
priority="important"
)
// Reference material (default)
lock_context(
content="Historical context about v1 API...",
topic="api-v1-history"
// priority defaults to "reference"
)
Related tools:lock_contextcontext_search

Symptoms

  • context_search returns empty
  • Know content exists but search fails
  • Semantic search not finding matches

Why this happens

The search query may not semantically match your content, or you may be searching in the wrong project.

Solution

1. Verify you're in the correct project: ``` project_list() ``` 2. Try broader search terms: ``` context_search("auth") // Instead of "JWT authentication tokens" ``` 3. List all contexts to see what exists: ``` context_explore() ``` 4. Search by tags if you used them: ``` context_search("", tags="api,security") ``` 5. Disable semantic search for exact keyword matching: ``` context_search("exact phrase", use_semantic=False) ```

Example

// Broad semantic search
context_search("authentication")
// Search with tag filter
context_search("api", tags="security")
// Keyword-only search (no semantic)
context_search("JWT token", use_semantic=False)
// Search with priority filter
context_search("rules", priority="always_check")
Related tools:context_searchcontext_explore

Symptoms

  • Search finds unexpected results
  • Exact phrase not matching
  • Want literal string matching

Why this happens

By default, context_search uses semantic search (meaning-based) not keyword matching. This finds conceptually related content but may miss exact phrases.

Solution

**Semantic Search (default):** - Finds content by meaning, not exact words - "auth" finds "authentication", "login", "JWT" - Better for discovery **Keyword Search:** - Exact text matching - Use when you know the exact term - Enable with `use_semantic=False` **Hybrid Approach:** Stompy tries semantic first, falls back to keyword if no results.

Example

// Semantic: finds related concepts
context_search("how users log in")
// Might find: "authentication", "JWT tokens", "session management"
// Keyword: exact matching
context_search("JWT", use_semantic=False)
// Only finds contexts containing "JWT"
// Combine with filters for precision
context_search("authentication", priority="important", tags="api")
Related tools:context_search

Symptoms

  • unlock_context fails for critical context
  • "Requires force=True" error
  • Cannot remove always_check priority context

Why this happens

Contexts with priority="always_check" are protected from accidental deletion. This is a safety feature for critical rules.

Solution

1. Verify you really want to delete this critical context 2. Use force=True to override protection: ``` unlock_context("critical-topic", force=True) ``` 3. By default, contexts are archived before deletion (recoverable) 4. To skip archiving (permanent delete): ``` unlock_context("topic", force=True, archive=False) ``` **Tip:** Consider changing priority to "reference" instead of deleting if you might need it later.

Example

// Protected by default - this fails:
unlock_context("security-rules")
// Error: Critical context requires force=True
// Override protection:
unlock_context("security-rules", force=True)
// Archived and deleted
// Alternative: downgrade priority
// (Update the context with lower priority instead)
Related tools:unlock_contextlock_context

Symptoms

  • Confused about versions
  • Want to understand update behavior
  • Need to manage context history

Why this happens

Understanding how Stompy versions contexts helps you manage knowledge effectively.

Solution

**How Versioning Works:** 1. First lock_context with a topic → creates v1.0 2. Lock again with same topic → creates v1.1 (v1.0 preserved) 3. Each version is immutable once created 4. recall_context gets latest by default **Version Numbers:** - Major.Minor format (1.0, 1.1, 1.2...) - Minor increments on updates - All versions retained forever **Best Practices:** - Use consistent topic names for related content - Let versioning handle updates (don't create "topic-v2") - Use db_query to see full version history

Example

// Create initial version (v1.0)
lock_context(content="Initial API spec", topic="api-spec")
// Update creates v1.1 (v1.0 still exists)
lock_context(content="Updated API spec", topic="api-spec")
// Recall latest
recall_context("api-spec") // Gets v1.1
// Recall original
recall_context("api-spec", version="1.0") // Gets v1.0
// See all versions
db_query("SELECT version, created_at FROM context_locks WHERE label = 'api-spec'")
Related tools:lock_contextrecall_contextdb_query

Symptoms

  • "File exceeds 10MB limit" error
  • Large file upload fails
  • Cannot ingest PDF/image

Why this happens

Stompy has a 10MB file size limit for document ingestion to ensure reasonable processing times and storage costs.

Solution

1. Check file size before uploading 2. For large PDFs: - Split into smaller documents - Extract only relevant sections - Use PDF compression tools 3. For large images: - Compress before uploading - Reduce resolution (max needed: 1920x1080) - Use lossy compression (JPEG) 4. Consider if you need the full document or just key excerpts **Tip:** Store summaries/excerpts with lock_context for very large docs.
Related tools:ingest_document

Symptoms

  • "Unsupported file type" error
  • File format not recognized
  • Extension not supported

Why this happens

Stompy supports specific file types for ingestion. Unsupported formats cannot be processed.

Solution

**Supported File Types:** **Documents:** - PDF (.pdf) - Word (.docx) - Excel (.xlsx) - PowerPoint (.pptx) **Text/Code:** - Plain text (.txt) - Markdown (.md) - Code files (.py, .js, .ts, .json, .yaml, etc.) - HTML, XML, CSV **Images (AI-analyzed):** - JPEG (.jpg, .jpeg) - PNG (.png) - GIF (.gif) - WebP (.webp) **Not Supported:** - Video files - Audio files - Encrypted/password-protected files - .doc (old Word format) **Workaround:** Convert unsupported formats to PDF or text.
Related tools:ingest_document

Symptoms

  • Image uploaded but no description generated
  • Vision API errors
  • Image content not searchable

Why this happens

Image analysis requires the OpenRouter Vision API. If not configured or unavailable, images are stored but not analyzed.

Solution

1. Image storage still works - the image is saved to S3 2. AI description requires OpenRouter Vision API: - This is a premium feature - Graceful fallback if unavailable 3. Check if the feature is enabled for your account 4. For manual workaround, add description via lock_context: ``` lock_context( content="Architecture diagram showing: [your description]", topic="architecture-diagram", tags="diagram,architecture" ) ``` 5. Images are still retrievable via list_ingested_documents
Related tools:ingest_documentlist_ingested_documents

Symptoms

  • "S3 upload failed" error
  • Document not stored
  • Storage service unavailable

Why this happens

The S3/DigitalOcean Spaces storage service is temporarily unavailable or there are credential issues.

Solution

1. This is usually a temporary service issue - retry in a few minutes 2. Check Stompy status page for outages 3. Verify file is valid and not corrupted 4. Try a smaller test file to isolate the issue 5. If persistent, report via bug_report tool: ``` bug_report( title="S3 upload failing", description="Document upload fails with S3 error", severity="high" ) ``` **Note:** Context storage (lock_context) works independently of S3.
Related tools:ingest_documentbug_report

Symptoms

  • "Embedding generation failed" error
  • Document stored but not searchable
  • VoyageAI errors

Why this happens

Text embeddings are generated by VoyageAI. If the service is unavailable, documents may be stored without embeddings.

Solution

1. Document is still stored - just not semantically searchable yet 2. Embeddings can be generated later (lazy loading) 3. Use keyword search as fallback: ``` context_search("document title", use_semantic=False) ``` 4. For new contexts, use lazy=True to defer embedding: ``` lock_context(content="...", topic="...", lazy=True) ``` Embedding will generate on first search. 5. If persistent, service may need time to recover
Related tools:ingest_documentlock_contextcontext_search

Symptoms

  • db_query rejects INSERT/UPDATE/DELETE
  • "Write operation not allowed" error
  • Need to modify data directly

Why this happens

db_query is read-only by design. For write operations, use db_execute with proper safety confirmations.

Solution

**db_query** = Read-only (SELECT only) - Safe for exploration - Auto-adds LIMIT 100 - No confirmation needed **db_execute** = Write operations - INSERT, UPDATE, DELETE - Requires confirm=True - Has dry_run mode (default) ``` // Reading data db_query("SELECT * FROM context_locks WHERE priority = 'important'") // Writing data (two-step for safety) db_execute( "UPDATE context_locks SET priority = 'reference' WHERE label = 'old-doc'", dry_run=True // Preview first ) db_execute( "UPDATE context_locks SET priority = 'reference' WHERE label = 'old-doc'", dry_run=False, confirm=True // Then execute ) ```

Example

// Read operation - use db_query
db_query("SELECT label, priority FROM context_locks")
// Write operation - use db_execute
db_execute(
sql="UPDATE context_locks SET priority = %s WHERE label = %s",
params=["reference", "old-topic"],
confirm=True
)
Related tools:db_querydb_execute

Symptoms

  • db_execute shows changes but nothing happens
  • Dry run works but actual update fails
  • "Unconfirmed operation" message

Why this happens

db_execute has safety controls: dry_run=True (default) only previews changes, and confirm=True is required to execute.

Solution

**Two-step safety process:** 1. **Preview** (dry_run=True, default): ``` db_execute("UPDATE ...", dry_run=True) ``` Shows what WOULD happen, makes no changes. 2. **Execute** (dry_run=False, confirm=True): ``` db_execute("UPDATE ...", dry_run=False, confirm=True) ``` Actually performs the operation. **Both flags required for execution:** - dry_run=False (disable preview mode) - confirm=True (explicit confirmation)

Example

// Step 1: Preview changes (safe)
db_execute(
sql="DELETE FROM workspace_temp WHERE created_at < '2024-01-01'",
dry_run=True // Default - just shows what would happen
)
// Output: "Would affect 15 rows"
// Step 2: Execute for real
db_execute(
sql="DELETE FROM workspace_temp WHERE created_at < '2024-01-01'",
dry_run=False,
confirm=True
)
// Output: "Deleted 15 rows"
Related tools:db_execute

Symptoms

  • db_schema shows no tables
  • Cannot see database structure
  • Schema appears empty

Why this happens

You may be looking at the wrong project schema, or the project has not been initialized with any data yet.

Solution

1. Verify you're in the correct project: ``` project_list() project_switch("your-project") ``` 2. View schema for current project: ``` db_schema() ``` 3. View specific table: ``` db_schema(table="context_locks") ``` 4. If new project, create some content first: ``` lock_context(content="test", topic="test") ``` 5. Standard tables: context_locks, sessions, documents, conflicts

Example

// List all tables in current project
db_schema()
// Get details for specific table
db_schema(table="context_locks")
// Query table structure directly
db_query("SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'context_locks'")
Related tools:db_schemadb_queryproject_switch

Symptoms

  • Cannot create workspace table
  • Workspace table not found
  • Permission denied for table operations

Why this happens

Workspace tables are temporary tables for complex queries. They have specific naming conventions and lifecycle.

Solution

**Workspace Tables:** - Prefixed automatically with 'workspace_' - Created with db_workspace tool - Cannot modify core Stompy tables **Create a workspace table:** ``` db_workspace( operation="create", table_name="my_results", // Becomes workspace_my_results schema="id INTEGER, value TEXT", confirm=True ) ``` **List workspace tables:** ``` db_workspace(operation="list", table_name="") ``` **Drop when done:** ``` db_workspace(operation="drop", table_name="my_results", confirm=True) ```

Example

// Create temp table for analysis
db_workspace(
operation="create",
table_name="search_results",
schema="context_id INTEGER, score REAL, label TEXT",
confirm=True
)
// Use in queries
db_execute(
"INSERT INTO workspace_search_results SELECT id, 0.95, label FROM context_locks",
confirm=True
)
// Clean up
db_workspace(operation="drop", table_name="search_results", confirm=True)
Related tools:db_workspacedb_querydb_execute

Symptoms

  • Query takes too long
  • Operation timed out
  • Large result set issues

Why this happens

Complex queries or large result sets can exceed timeout limits. db_query auto-adds LIMIT 100 for safety.

Solution

1. db_query automatically adds LIMIT 100 - for more results use pagination: ``` // First 100 db_query("SELECT * FROM context_locks") // Next 100 db_query("SELECT * FROM context_locks OFFSET 100 LIMIT 100") ``` 2. Add WHERE clauses to filter results: ``` db_query("SELECT * FROM context_locks WHERE priority = 'important'") ``` 3. Select only needed columns: ``` db_query("SELECT label, version FROM context_locks") // Faster than SELECT * ``` 4. Use get_query_page for paginated results from tools that support it

Example

// Efficient: select specific columns with filter
db_query(
"SELECT label, priority, version FROM context_locks WHERE priority = %s",
params=["important"]
)
// Paginate large results
db_query("SELECT * FROM context_locks LIMIT 50")
db_query("SELECT * FROM context_locks LIMIT 50 OFFSET 50")
Related tools:db_queryget_query_page

Symptoms

  • Contexts from wrong project appearing
  • Confused about project boundaries
  • Want to understand data separation

Why this happens

Each Stompy project is a completely isolated PostgreSQL schema. Understanding this helps manage multiple projects effectively.

Solution

**How Project Isolation Works:** 1. Each project = separate PostgreSQL schema 2. Zero data bleed between projects 3. Contexts, documents, sessions are all project-specific 4. Must explicitly switch to access different project **Best Practices:** - Use project_list() to see all projects - project_switch() before working on specific project - Name projects clearly (client-name, project-type) **When to use separate projects:** - Different clients - Unrelated codebases - Separate knowledge domains - Personal vs work

Example

// See all projects
project_list()
// Switch to specific project
project_switch("client-acme")
// All operations now scoped to client-acme
lock_context(content="Acme API spec", topic="api")
// This context only exists in client-acme project
// Switch to different project
project_switch("personal-blog")
// Cannot see client-acme contexts here
Related tools:project_listproject_switchproject_create

Symptoms

  • project_switch seems to fail
  • Still seeing old project data
  • Handover not loading

Why this happens

Project switching should be instant, but there may be caching or the project name may be incorrect.

Solution

1. Verify project exists: ``` project_list() ``` 2. Use exact project name (case-sensitive): ``` project_switch("My-Project") // Exact match required ``` 3. Skip handover loading if causing issues: ``` project_switch("project-name", load_handover=False) ``` 4. Verify switch worked: ``` project_info("project-name") ``` 5. If project doesn't exist, create it: ``` project_create("new-project") ```

Example

// List available projects
project_list()
// Switch with handover (default)
project_switch("my-project")
// Switch without loading previous session
project_switch("my-project", load_handover=False)
// Create if doesn't exist
project_create("new-project")
project_switch("new-project")
Related tools:project_switchproject_listproject_create

Symptoms

  • Previous session context missing
  • Handover shows empty
  • "No handover available" message

Why this happens

Handover summaries are created at session end. If no previous session exists or it was empty, there may be no handover to load.

Solution

1. Handover requires a previous session with activity 2. Check if handover exists: ``` project_info("your-project") ``` 3. Handover is optional - project works without it 4. Skip handover if not needed: ``` project_switch("project", load_handover=False) ``` 5. View recent sessions manually: ``` db_query("SELECT * FROM sessions ORDER BY created_at DESC LIMIT 5") ``` **Note:** First session in a new project won't have handover.
Related tools:project_switchproject_info

Symptoms

  • project_delete fails
  • "Requires confirmation" error
  • Project deletion blocked

Why this happens

Project deletion is destructive and requires explicit confirmation to prevent accidental data loss.

Solution

**Project deletion is permanent!** 1. Deletion requires confirm=True: ``` project_delete("old-project", confirm=True) ``` 2. Before deleting, consider exporting: ``` export_project(output_path="/path/backup.json.gz") ``` 3. Verify project name is correct: ``` project_list() project_info("old-project") // Review what will be deleted ``` 4. All data in project will be lost: - Contexts - Documents - Sessions - Workspace tables

Example

// First, review what will be deleted
project_info("old-project")
// Optional: backup first
export_project(output_path="/tmp/old-project-backup.json.gz")
// Delete with explicit confirmation
project_delete("old-project", confirm=True)
// Verify deletion
project_list()
Related tools:project_deleteproject_infoexport_project

Symptoms

  • Embedding generation fails
  • Semantic search not working
  • VoyageAI API errors

Why this happens

VoyageAI provides embeddings for semantic search. Service outages or rate limits can cause temporary failures.

Solution

1. Stompy uses VoyageAI voyage-3 for text embeddings 2. During outages: - lock_context still works (embedding deferred) - Use lazy=True to defer embedding - Keyword search still works 3. Fallback to keyword search: ``` context_search("query", use_semantic=False) ``` 4. Deferred embeddings generate on first search: ``` lock_context(content="...", topic="...", lazy=True) ``` 5. Check Stompy status page for service updates
Related tools:lock_contextcontext_search

Symptoms

  • Image analysis fails
  • No description generated for images
  • Vision API timeout

Why this happens

OpenRouter provides AI vision for image analysis. This is optional - images work without it.

Solution

1. Image storage works independently of vision API 2. Vision API provides: - AI-generated image descriptions - Searchable content from images - Uses Qwen 2.5 VL model 3. If vision fails: - Image still stored in S3 - Manually add description: ``` lock_context( content="Description of image: [your text]", topic="image-description", tags="image" ) ``` 4. Check image size (max 1920x1080 processed) 5. Retry later for temporary issues
Related tools:ingest_documentlock_context

Symptoms

  • context_summarize fails
  • "Ollama not available" error
  • AI summary not generating

Why this happens

context_summarize uses a local Ollama LLM for privacy-preserving summaries. Ollama must be running locally.

Solution

**context_summarize requires local Ollama:** 1. Install Ollama: https://ollama.ai 2. Pull recommended model: ```bash ollama pull qwen2.5-coder:1.5b ``` 3. Start Ollama (runs in background): ```bash ollama serve ``` 4. Verify it's running: ```bash ollama list ``` 5. context_summarize should now work: ``` context_summarize("my-topic") ``` **Alternative:** Use recall_context with preview_only=True for basic summary without Ollama.

Example

// Requires Ollama running locally
context_summarize("api-specification")
// Alternative without Ollama:
recall_context("api-specification", preview_only=True)
// Returns 500-char preview instead of AI summary
Related tools:context_summarizerecall_context

Symptoms

  • Document upload fails
  • S3 authentication error
  • Cannot store files

Why this happens

Document storage requires S3/DigitalOcean Spaces credentials. This is typically configured server-side.

Solution

1. Document storage is a hosted feature - credentials are managed by Stompy 2. If you're seeing storage errors: - This may be a temporary service issue - Retry in a few minutes - Check Stompy status page 3. Context storage (lock_context) doesn't require S3: ``` lock_context(content="Your content as text", topic="my-topic") ``` 4. For self-hosted Stompy (advanced): - Configure DO_SPACES_* environment variables - Or AWS S3 credentials 5. Report persistent issues via bug_report
Related tools:ingest_documentbug_report

Symptoms

  • lock_context times out
  • Large content fails to store
  • Operation exceeds time limit

Why this happens

Very large contexts take longer to process (embedding generation, storage). Consider chunking or using lazy embedding.

Solution

**For large content:** 1. Use lazy embedding (defers processing): ``` lock_context( content="very long content...", topic="large-doc", lazy=True ) ``` 2. Consider splitting into multiple contexts: - "project-overview" - high-level summary - "project-api-details" - API specifics - "project-database" - DB schema 3. For documents, use ingest_document: ``` ingest_document("large-file.pdf") ``` It handles chunking automatically. 4. Store summary + reference to full doc: ``` lock_context( content="Summary of large doc. Full version at: [location]", topic="doc-summary" ) ```

Example

// Defer embedding for large content
lock_context(
content="Very long technical specification...",
topic="full-spec",
lazy=True // Embedding generated on first search
)
// Better: split into logical chunks
lock_context(content="Overview...", topic="spec-overview")
lock_context(content="API details...", topic="spec-api")
lock_context(content="Data models...", topic="spec-models")
Related tools:lock_contextingest_document

Symptoms

  • sync_project_memory fails
  • Background sync not completing
  • Project analysis incomplete

Why this happens

Project sync analyzes your entire codebase which can be resource-intensive. Large projects may need multiple runs.

Solution

**sync_project_memory troubleshooting:** 1. Start with dry_run to preview: ``` sync_project_memory(dry_run=True) ``` 2. Sync specific priorities only: ``` sync_project_memory( priorities=["always_check"], // Critical only confirm=True ) ``` 3. Force sync if skipped: ``` sync_project_memory(force=True, confirm=True) ``` 4. For very large projects: - Run in stages (different priorities) - Exclude generated/vendor directories - Focus on source code directories 5. Check project path is correct: ``` sync_project_memory(path="/correct/path") ```

Example

// Preview changes first
sync_project_memory(dry_run=True)
// Sync critical items only
sync_project_memory(
priorities=["always_check", "important"],
confirm=True
)
// Force re-sync
sync_project_memory(force=True, confirm=True)
// Manual trigger for all projects
trigger_background_sync(active_hours=24)
Related tools:sync_project_memorytrigger_background_sync

Still need help?

If you can't find the solution here, you can report a bug directly from Claude.

bug_report(
title="Describe the issue",
description="What happened and what you expected",
severity="medium"
)