mech.app
AI Agents

AI Boost's MCP Pattern Library: How Agents Share Reusable Context Across Sessions Without Re-Prompting

MCP server architecture that indexes, embeds, and auto-injects reusable patterns across agent sessions, solving the cold-start problem.

Source: ai-boost.io
AI Boost's MCP Pattern Library: How Agents Share Reusable Context Across Sessions Without Re-Prompting

Every agent session starts blank. You explain your auth flow again. You point to the Terraform repo again. You copy-paste the same middleware pattern again. AI Boost solves this by turning patterns into retrievable, injectable context that lives outside any single session.

It’s an MCP server that indexes your patterns (text files, GitHub repos) as “boosters,” embeds them for semantic search, and surfaces them automatically when your agent starts a matching task. Works across Cursor, Claude Code, and any MCP-compatible client.

The Cold-Start Problem

Agent memory systems fall into two camps. Ephemeral prompts require manual re-explanation every session. Heavyweight memory stores (vector databases, conversation logs) accumulate noise and lack structure. You get either nothing or everything.

AI Boost sits in the middle. You explicitly save patterns you want reused. The system indexes them with keywords and embeddings, then injects them only when context matches. No session state, no conversation scraping. Just curated, reusable context.

Architecture: MCP Server with Dual Retrieval

The MCP server exposes a single endpoint at https://mcp.ai-boost.io/mcp. Clients connect via the Model Context Protocol, which standardizes how agents request and receive external context.

Booster creation flow:

  1. Agent reads current file or repo
  2. Proposes metadata (name, description, keywords)
  3. User approves or edits
  4. Server stores raw content, generates embeddings, indexes keywords
  5. Booster becomes available for future retrieval

Retrieval uses both keyword and embedding search:

  • Keywords trigger exact matches (e.g., “Terraform AWS VPC”)
  • Embeddings catch semantic overlap (e.g., “network isolation” matches VPC patterns)
  • Combined scoring balances precision and recall

The Show HN post describes “auto-suggest before starting a task” behavior. The exact mechanism is not fully documented in the source material. Based on the MCP protocol and the description provided, the likely flow is that the agent queries the MCP server at task start with a task description. The server returns ranked candidates without classifying tasks itself. The agent then prompts for user approval before injection. This keeps the human in the loop and avoids context pollution.

Account Scoping and Marketplace Boundary

Boosters are private by default. They live in your account and are never indexed, shared, or used for training. The server enforces account-level isolation at the database layer.

The community marketplace introduces a second boundary. When you publish a booster:

  • It becomes publicly discoverable via keyword/embedding search
  • Other users can inject it into their sessions
  • You earn credits per injection (metering happens server-side)
  • The booster remains read-only for others

This creates a two-tier namespace: private boosters (account-scoped) and public boosters (globally readable, author-credited). The MCP server checks account ID on every retrieval to enforce this boundary.

Auto-Suggest Mechanics

The “before starting a task” behavior is not fully documented. Based on the Show HN description and MCP protocol patterns, the inferred flow is:

  1. Agent begins task execution
  2. Agent queries MCP server with task description
  3. Server runs keyword + embedding search across account boosters
  4. Returns ranked list of matching boosters
  5. Agent surfaces matches to user
  6. User approves injection or skips

The agent does not automatically inject. The server does not classify tasks. The agent simply asks “what context matches this description?” and the server returns candidates. The user decides.

This avoids two failure modes: agents injecting irrelevant context (too aggressive) and agents missing useful patterns (too passive). The approval step keeps context injection explicit.

Supported Sources and Ingestion

Current booster sources:

  • Text files: Direct content upload
  • Public GitHub repos: Server clones, indexes, and tracks updates
  • Private GitHub repos: In progress (requires OAuth token storage and refresh logic)

For GitHub sources, the system appears to handle updates by detecting changes to the source repository. When a repo updates, the booster may become stale. The user can refresh manually. Webhook-based automatic refresh is not yet implemented.

Current Limitations and Roadmap Items

Stale boosters: If a GitHub repo updates (for example, if a Terraform module changes), the booster reflects the old version until manually refreshed. No automatic invalidation yet. The agent will inject outdated code that may fail validation or use deprecated resources.

Keyword collisions: Two boosters with similar keywords but different contexts (e.g., “auth” for OAuth vs. JWT) can both surface. If you have saved both a JWT middleware pattern and an OAuth2 flow pattern, both will rank when you mention “auth,” requiring manual disambiguation each time.

Embedding drift: If the underlying embedding model changes, old boosters may rank differently. The server does not re-embed automatically. A booster saved with one model version may become harder to retrieve after a model update, even if the content remains relevant.

No versioning: Updating a booster overwrites the previous version. No rollback or diff view. If you refine a Terraform module and overwrite the booster, you cannot retrieve the previous version if the new one introduces bugs.

No telemetry: The server does not log which boosters get injected, skipped, or ignored. You cannot see injection acceptance rate per booster type or identify which patterns are actually useful versus which ones clutter search results. This makes it difficult to prune low-value boosters or refine keyword strategies.

MCP Protocol Split: Server vs. Client Responsibilities

The MCP server runs as a single endpoint. Clients connect via HTTPS. No local installation required. The server handles:

  • Authentication (account ID from MCP client)
  • Storage (boosters, embeddings, metadata)
  • Retrieval (keyword + embedding search)
  • Metering (credit tracking for marketplace injections)

The client (Cursor, Claude Code, etc.) handles:

  • Task description parsing
  • MCP protocol communication
  • User approval prompts
  • Context injection into agent prompt

This split keeps the server stateless per-request. All state lives in the database. The server does not track active sessions or maintain WebSocket connections.

When to Use This

Use AI Boost when:

  • You need explicit control over what patterns get saved (no automatic discovery)
  • You work across multiple MCP-compatible clients (Cursor, Claude Code)
  • You want cross-project pattern reuse without manual copy-paste
  • You can tolerate manual booster creation and refresh

Avoid AI Boost when:

  • You need automatic pattern discovery from agent behavior
  • You require session-to-session conversational memory
  • You need booster versioning or rollback capability
  • You need telemetry on which boosters improve agent output

The system requires you to explicitly save patterns. It does not learn from behavior or scrape conversations. It replaces copy-paste and manual re-explanation, not memory systems that infer patterns automatically.

Technical Verdict

AI Boost solves a real problem: agents forgetting your conventions between sessions. The MCP server architecture makes it cross-client and avoids vendor lock-in. The dual retrieval (keywords + embeddings) balances precision and recall better than pure semantic search.

The missing pieces are observability (which boosters actually help?), versioning (how do I roll back a bad update?), and automatic staleness detection (when does a GitHub-backed booster need refresh?). Without telemetry, you cannot measure whether a booster improves agent output or just adds noise. Without versioning, a bad booster update becomes permanent until you manually recreate the previous version. Without staleness detection, you risk injecting outdated patterns that fail in production.

Use this if you have a small set of high-value patterns you want available everywhere and you are willing to curate them manually. Avoid it if you need automatic memory, session continuity, or detailed usage analytics. The system prioritizes explicit control over automatic inference.