Claude Projects Alternative: When You Need More Than Projects

June 2026 · 7 min read

Claude Projects is a solid feature. You create a project, attach some documents, write a system prompt, and Claude has that context for every conversation within the project. It removes the "start fresh and re-explain everything" friction.

But after using it for a while, most people run into the same walls. This post is about what those walls are and what to do when you hit them.

What Claude Projects does well

Before the alternatives: Projects is genuinely useful for its specific job.

Fixed document context — attach a spec, a codebase, a style guide. Claude reads it at the start of every conversation in that project.
Standing instructions — project-level system prompt that applies to all conversations. "Always respond in formal English" or "You are reviewing code for security issues."
Organised conversations — grouping related conversations in one place is a genuine QoL improvement.

If your use case is "I want Claude to always know about this specific spec/codebase/document," Projects covers it well.

The limitations that people hit

1. Static files only — you can't update context mid-project.

You upload a document at project setup. When the document changes, you re-upload it. There's no way for Claude to say "add this new decision to my context" and have it persist. The context is frozen at upload time.

2. No querying — it's all or nothing.

If you upload a 100-page spec, Claude loads all 100 pages (or as much as fits in context) at the start of every conversation. You can't say "load only the section about authentication." The whole thing is context, not a queryable store.

3. Context doesn't cross projects.

You're a consultant who works across five clients. Each has a Claude project. Your own profile — who you are, your working style, your personal contact list — has to be duplicated in every project's system prompt. There's no global layer.

4. The token cost scales with document size.

Every conversation in a project pre-loads the attached documents. A 50KB document at the start of every conversation adds up. If you're on the API, this is a real cost. Even on Claude.ai, it slows things down.

5. You're limited to Projects' own storage.

You can't build a growing list of contacts, track tasks, or maintain a searchable record store. Projects is document-first, not data-first.

What an alternative needs to do

The core gap is: Projects gives Claude a static briefing. You need Claude to have a dynamic, queryable memory.

The difference:

Claude Projects	Queryable external store (MCP)
Upload a document once	Add records incrementally, anytime
Claude loads the whole document	Claude fetches only what's needed
Context is per-project	Context is per-account (crosses projects)
No search — whole document or nothing	Full-text search, filtered queries
Static after upload	Live — Claude can add/update/remove

The MCP approach

MCP (Model Context Protocol) is how Claude connects to external tools. Add an MCP connector and Claude gets tools it can call during conversations — remember(), recall(), context(), and so on.

The practical pattern replaces the "static document upload" with a "dynamic store that Claude queries when it needs something":

Without MCP (Projects approach):
  Every conversation starts with: [loads 40KB spec] "Now, what's your question?"

With MCP:
  You: "What should I prioritise this week?"
  Claude: [calls context() — returns 300 tokens of relevant standing context]
  Claude: "Based on your current sprint and the auth refactor deadline…"

Claude loads nothing it doesn't need. The store grows over time and doesn't slow down.

How to use both together

Projects and MCP aren't mutually exclusive. The combination is often better than either alone:

Projects → fixed reference documents (a spec, a style guide, a codebase snapshot) that you want Claude to always have
MCP store → your evolving context (who you are, active decisions, contact notes, running lists)

A setup that uses both might look like:

Claude Project: "API development" — attached: openapi.yaml, architecture-notes.md
Stash connector: standing context with your role, tech stack preferences, current sprint decisions, and the last 5 architecture choices with their reasoning

Claude gets the static spec from the project, the live decision log from Stash. Neither has to carry the weight of the other.

Setting up an MCP store with Stash

Stash is a hosted MCP server that provides persistent, searchable storage for Claude. Free tier, no credit card required.

Setup takes about 5 minutes:

Sign up at stashlite.com with your Google account
Copy your connector URL from the dashboard
In Claude, go to Settings → Connectors → Add connector → paste the URL
Tell Claude: "Set up my standing context in Stash with my role and current work."

After that, you have a store Claude can read from and write to in any conversation, in any project.

When Projects is the right tool

To be clear: this isn't about replacing Projects. There are cases where Projects is exactly right:

You're working with a large fixed document (a codebase, a book manuscript) that Claude needs for reference
You want a specific persona or instruction set for a contained project
The context is static and you don't need to update it dynamically

Use Projects for what Claude should always know about this specific context. Use an MCP store for what Claude should know about you and your evolving work.

Add Stash as your persistent Claude memory layer

Works alongside Claude Projects. Sign up at stashlite.com, get your connector URL, add it to Claude's connector settings.

Connector: https://app.stashlite.com/mcp

Stash is a new service. Free tier: 2,500 records / 50 queries per month. Pricing may change; cancel anytime.