Here’s the number that nags me: every skill you ship into an agent’s context costs ~50 tokens of pure metadata — just to keep the description resident so the agent knows it exists. That’s tolerable at 100 skills (~5k tokens). It’s annoying at 1,000 (~50k). At 10,000 it’s 500k+ tokens — which blows past most context windows entirely.

We’ve been shipping skills as files. Local files don’t sync across machines, teams, or agents. They go stale, they get duplicated, they’re unversioned, and — most worrying — you have no idea who wrote them or whether they’re safe to follow.

So I built skill-vault: a self-hostable, semantic skill registry that an agent talks to over one MCP endpoint.

The Idea: Registry + Retrieval, Not Another File Format

The mistake most skill systems make is treating skills as files to inline. Skill Vault treats them as records to query:

• Skills live in a centralized, versioned, content-addressed store.
• The agent wires in exactly one MCP endpoint.
• search_skills("postgres schema migration") returns light cards — name + one-liner + trust tier + cosine score. Cheap.
• get_skill(id) returns the full SKILL.md body only for the skill the agent actually wants.
• A personal vault lets each agent push its own hard-won capabilities and pull them back anywhere, alongside a curated global library.

The payoff in numbers: an agent with access to 10,000 skills carries only ~50 tokens of registry description in context, and retrieves the one it needs at the moment it needs it.

Semantic Search That Doesn’t Bloat the Index

Under the hood it embeds skill metadata, not full bodies — name, description, tags, and triggers — with local all-MiniLM-L6-v2 embeddings (384-dimensional), ranked by cosine similarity.

search_skills("postgres schema migration")
  → [card] sql-migrations   (score 0.87, tier public)
  → [card] db-schema-sync   (score 0.81, tier user)
  → [card] postgres-optimize (score 0.74, tier verified)

Embedding the metadata instead of the whole instructions keeps the index small while the retrieval stays sharp — the ranked cards are enough to decide, and the full body only loads when the agent commits.

Trust: The Part I Refused to Skip

A skill registry that pulls arbitrary instructions from anywhere is a prompt-injection vector waiting to happen. So the supply chain is first-class:

• sha256 content hashing — every skill is content-addressed and integrity-pinned; clients can verify bytes haven’t drifted.
• Optional ed25519 signatures — a skill can be signed, proving who vouched for it.
• Three trust tiers — verified (curator-signed), user (owner’s own), public (community).

The point isn’t to lock everything down — it’s that verified means a curator vouched for the content, not just that someone uploaded it. That distinction makes the difference between a registry and a liability.

Per-Agent Identity and Private Vaults

Every agent gets its own API key (stored as sha256 at rest, shown once at onboarding) with global / personal / owner-only scope enforcement at the tool layer. So the same deployment serves different agents and teams, and cross-agent private access is always denied — your agent’s hard-won skills are yours.

Self-Hosted, Transport-Flexible

No managed service, no third party sees your skills, no per-query cost. SQLite + sqlite-vec for local deployments, pgvector as a drop-in for scale-out. stdio for local agents, streamable-HTTP/SSE for remote ones. Docker images for both the MCP server (:8000) and web dashboard (:8080).

The web dashboard covers agent management, onboarding, per-agent skill browser, key rotation/revocation, and a ready-to-copy /configure guide for pointing your agent at the endpoint.

Shipped, Tested, Verified

• 17 curated seed skills (including one verified sample) so the registry is useful out of the box.
• 111 tests at 88% coverage, green GitHub Actions CI on the released commit.
• Apache-2.0, fully self-hostable.

Point your agent at one endpoint, let it pull skills when it needs them, and know what you’re pulling is intact and credited.

pip install skill-vault
skill-vault serve

GitHub → github.com/vikasudasi/skill-vault · Release v0.1.0

A week ago I shipped mcp-app-suite, the browser-side toolchain for MCP Apps — the spec that finally lets MCP servers return interactive UI (charts, dashboards, forms) instead of plain text. The whole ecosystem assumes you’ll render those payloads inside an AI client’s embedded iframe.

But here’s the thing I kept running into: what do you do on a headless server, in CI, or over SSH? Every payload was pure JSON sitting in a text blob nobody could see. So I built the other half of the story — mcp-apps-render, which renders that same payload format straight into your terminal.

Why This Matters

MCP Apps dropped my return-to-text floor. A tool call can now hand back a chart, a status dashboard, a deploy summary. The catch: that UI is a JSON tree of components, and without a client that renders it, it’s just bytes.

mcp-apps-render treats the terminal as a first-class render target. Not a fallback — a real one.

# Inspect a payload's schema
mcp-apps-render inspect payload.json

# Render it locally
mcp-apps-render render payload.json

# Connect to a live MCP server and render a real tool result
mcp-apps-render serve http://localhost:8003/mcp --tool get_app

Here’s a real render from the sample payload’s system monitor — nested panels, stats, an ASCII progress bar, and a bar chart, all from a JSON tree:

╭────────────────────────────── system-monitor (v1.0) ───────────────────────────╮
│ ╭─────────────────────────────── CPU ────────────────────────────────╮          │
│ │ 42                                                                 │          │
│ ╰────────────────────────────────────────────────────────────────────╯          │
│ ╭────────────────────────────── Load ────────────────────────────────╮          │
│ │ [==============------] 72%                                         │          │
│ ╰────────────────────────────────────────────────────────────────────╯          │
│ r1[========------------] 120   r2[====================] 300                    │

(abridged — the real output renders the full nested tree)

What Makes It Terminal-Safe

The tricky part isn’t drawing boxes — it’s doing so without corrupting your session. Three things hold up in practice:

• Every component maps to one of four render kinds — layout (panels), form (fields), data (tables/charts/stats), or unknown. Unknown types aren’t rejected; they degrade to a silent placeholder.
• Terminal-safe escaping — no stray control bytes, no broken wrapping, degrades cleanly when not a TTY.
• The schema parser is tolerant — unknown component types and extra fields are preserved (extra="allow"), so the tool won’t break the day the MCP Apps spec adds a new component.

A system monitor, a serve against a live server, a config dashboard — it handles the whole family.

The Numbers

Playing Nicely With the Suite

mcp-app-suite is the authoring end — playground, scaffolder, demo server. mcp-apps-render is the consumption end — same payload format, opposite pipeline. Together they cover the cycle: build an app, preview it in a browser, then consume its payloads headlessly. It’s the same MCP Apps story, told from the terminal side.

Links

• GitHub: github.com/vikasudasi/mcp-apps-render
• Install: pip install mcp-apps-render[client]
• Companion: mcp-app-suite

Your AI agent has no memory between sessions. Not really.

Transcript logs help with auditing — you can scroll back through “what was said” — but they’re flat text. There’s no entity-level recall, no relationship-aware retrieval, no way to ask “what decisions did we make about Redis last week?” and get a structured answer.

Most agent memory systems solve this by shipping your data to a cloud vector database. That works, but it means your conversations, tool outputs, and internal decisions live on someone else’s infrastructure.

I wanted something different: local-first, graph-native, queryable by natural language — and running entirely on my own machine.

Here’s what I built.

What It Is

agent-knowledge-graph is a CLI + Python library that ingests AI agent sessions into a Neo4j-backed property graph, augments nodes with local embeddings for semantic recall, and exposes natural-language query flows.

Session → LLM extraction → typed nodes + relationships + vector embeddings → Neo4j

It’s designed as a four-phase pipeline: extract raw data from a source, resolve it into typed entities via LLM, embed each entity as a vector locally, then write everything to Neo4j. The same architecture supports any data source — not just chat sessions.

What Goes Into the Graph

Every session is parsed by an LLM that extracts structured knowledge following a strict schema:

Relationships connect sessions to entities via typed edges: mentions, produces, uses, decides, references, blocks, resolves, assigns.

The Architecture

The core has four layers:

Pipeline Framework (pipelines/) — Each data source is a KnowledgePipeline subclass with three phases: extract() yields raw records, resolve() converts them into Resource nodes with LLM enrichment, and get_relationships() generates typed edges. The base class handles checkpointing, embedding, and writing automatically.

Query Engine (core/query.py) — Four query modes: semantic (embed + vector search), traversal (hop-based neighborhood exploration), hybrid (vector + Cypher filter), and NL→Cypher (LLM translates a question to Cypher and executes it).

Graph Client (core/graph.py) — Wraps Neo4j connection pooling, manages schema constraints and the vector index, and exposes upsert operations for batch writes.

Agent Adapters (adapters/) — The graph is accessible through a Hermes plugin (4 MCP tools: kg_query, kg_semantic_search, kg_traverse, kg_stats), an MCP server for generic MCP clients, or LangChain tools. The system is agent-agnostic — the core doesn’t know what agent system is talking to it.

Why Local Embeddings

The default embedding provider uses sentence-transformers/all-MiniLM-L6-v2 — a 384-dimension model that runs entirely on your machine. No API calls, no vector database credits, no data leaving your network. On my workstation with a modest setup, it takes about 8 seconds for the first query (model loading) and sub-second after that (LRU-cached).

This is important because embeddings are the most frequently called operation in a memory system — every ingested node gets one, and every query needs one. Paying per-embedding for a system that runs daily adds up fast.

What You Can Ask

The NL→Cypher query engine lets you ask natural questions:

kg query ask "What decisions mention Neo4j?"
kg query semantic "retry policy and reliability"
kg query traverse entity:redis --hops 2

The LLM generates Cypher from your question, executes it against Neo4j, and returns structured results. The schema is injected into the prompt so the LLM knows what labels and properties are available.

Vector Search with Neo4j 2026 SEARCH Clause

Running on Neo4j 2026.06, the vector search uses the new native SEARCH Cypher clause — replacing the deprecated db.index.vector.queryNodes procedure:

MATCH (n:Resource)
SEARCH n IN ( VECTOR INDEX resource_embedding FOR $query_embedding LIMIT 10 )
SCORE AS score
WHERE n.type = $type_filter
RETURN n, score ORDER BY score DESC

This is faster (native in-index filtering instead of post-filter) and doesn’t trigger deprecation warnings.

What’s Next

The system is up and running — a daily cron ingests new sessions, and I query it via Hermes MCP tools. Things I’m planning next:

• File/repo ingestion pipeline — Index codebases as nodes linked to the sessions that touched them
• Cross-session entity resolution — Merge entities extracted in different sessions into canonical nodes
• GitHub issue/PR pipeline — Sync open issues as :task nodes with status tracking
• Graph visualization — Web UI to explore the Neo4j graph interactively

Try It

git clone https://github.com/vikasudasi/agent-knowledge-graph.git
cd agent-knowledge-graph
uv sync
docker compose up -d      # starts Neo4j
uv run kg init            # creates schema + vector index
uv run kg build run all   # run all pipelines
uv run kg query ask "What do I know?"

The only hard dependency is Neo4j (Docker compose provided). Everything else — embeddings, LLM integration, CLI — runs locally. The codebase has 147 tests at 86% coverage.

github.com/vikasudasi/agent-knowledge-graph

The Context Collapse AI worm made headlines this summer — and for good reason. Researchers demonstrated malicious instructions hidden inside Word documents that could alter financial data via Microsoft Copilot, exfiltrate sensitive information, and even self-propagate to new documents. It worked through two mitigation patches. EchoLeak CVE-2025-32711 (CVSS 9.3) proved it’s not just a lab curiosity — zero-click prompt injection via hidden text is being actively exploited.

The problem is clear: your AI agent pipeline has a gap. You scan for vulnerabilities in dependencies (Snyk, Dependabot), you scan for secrets in code (GitGuardian), you even scan for slop in your codebase (no-slop). But nobody scans the documents you feed into your AI agents.

I built doc-inject-guard to close that gap.

What It Does

doc-inject-guard is a CLI that scans input documents for prompt injection payloads — hidden instructions designed to alter AI agent behaviour. It supports four document formats and runs five detection modules:

pip install doc-inject-guard
doc-inject-guard scan ./incoming-docs/

Supported Formats

Five Detection Modules

CLI Reference

 Usage: doc-inject-guard [OPTIONS] COMMAND [ARGS]...

╭─ Commands ───────────────────────────────────────╮
│ scan      Scan a file or directory
│ analyze   Deep-analyze with optional LLM         │
│ watch     Watch a directory in real-time         │
│ version   Show version                           │
╰──────────────────────────────────────────────────╯

doc-inject-guard scan ./docs/ --recursive --format json --ci

doc-inject-guard analyze suspicious.docx

doc-inject-guard watch ./hotfolder/

The Risk Score

Each scan produces a 0-100 risk score with severity categorization. Findings are weighted and compounded:

• Critical (85+): Active injection payloads detected
• High (65+): Strong injection indicators with multiple patterns
• Medium (40+): Suspicious elements that warrant investigation
• Low (20+): Minor anomalies
• Info (<20): Informational findings

Output formats: rich terminal (default), JSON (for CI pipelines), SARIF (GitHub Security tab).

Why This Matters for Organisations

The EU AI Act Article 50 takes effect August 2, 2026. If your organisation deploys AI that consumes documents (and nearly every enterprise does — Copilot, custom agents, support bots, document processors), you have a compliance obligation to label AI-generated content and ensure your AI pipeline isn’t being manipulated by injected instructions.

Most security teams can tell you their CVE backlog. Very few can tell you whether their AI agent pipeline is ingesting documents with hidden prompt injections. That’s the gap doc-inject-guard fills.

Architecture

The design is intentionally modular:

Document → Parser → text + structure → Detectors → Risk Engine → Reporter

Each document format has its own parser that preserves position metadata. Detectors run independently against the parsed output. The risk engine aggregates findings into a weighted score. The reporter renders in rich terminal, JSON, or SARIF.

Four parsers, five detectors, one risk engine — all disposable and replaceable. Want to add a PowerPoint parser? Write a parser class. Want to detect a new injection pattern? Write a detector class.

Try It

pip install doc-inject-guard
doc-inject-guard scan --help

Or clone the repo and run locally: github.com/vikasudasi/doc-inject-guard

The test suite includes 112 tests covering 85% of the codebase, with real injection-containing fixtures across all four formats.

On August 2, 2026 — three days from today — the EU AI Act’s Article 50 transparency requirements take full effect. Any AI-generated or deepfake content distributed in the EU must carry C2PA provenance manifests, metadata declarations, and disclosure statements. Non-compliance can cost up to 3% of global annual turnover or €15 million.

Most teams I’ve talked to have no tooling for this. They know about the requirements but can’t actually check their content. So I built one.

Why This Act Exists

The EU AI Act was first proposed in April 2021, but its transparency provisions were dramatically expanded after ChatGPT launched in late 2022. The sudden ability for anyone to generate text, images, audio, and video — indistinguishable from human-created content — at near-zero cost changed the risk landscape overnight.

Article 50 sits at the heart of the Act’s response. Its stated objectives:

• Reduce risks of impersonation, deception, and manipulation at scale
• Safeguard democratic processes and public trust by making synthetic content detectable
• Give individuals the ability to distinguish AI-generated content from human-created content

The official guidelines describe this as protecting the “integrity of the information ecosystem” — a direct response to deepfake election interference campaigns, AI-generated misinformation, and the collapse of trust in online content.

Who It Applies To

Article 50 is the broadest provision in the entire AI Act. It does not require “high-risk” classification — it applies automatically to four situations:

Two groups are caught:

1. Providers — companies that build AI systems (OpenAI, Google, Adobe, Meta)
2. Deployers — any person, company, organisation, or public authority that uses AI systems to generate content and makes it available

The guidelines explicitly state this covers existing AI systems already on the market — no grandfather clause. Even open-source AI systems are not exempt.

Why This Matters for Large Organisations

A company can have zero high-risk AI and still be fully on the hook:

• Marketing team uses ChatGPT for ad copy → Article 50(2) applies
• Customer service runs a chatbot → Article 50(1) applies
• Editorial team publishes AI-assisted reports → Article 50(4) applies
• Media team modifies product images with AI → Article 50(4) applies
• Engineering uses AI coding assistants → Article 50(1) applies to the provider, but deployer obligations may also be triggered depending on use

According to the EU AI Act Compliance Checker data, transparency obligations under Article 50 are the second most common compliance trigger across all responding organisations — affecting ~33% of them.

Penalties

Article 50 carries fines up to €7.5 million or 1.5% of global annual turnover, whichever is higher. (Separate from the Act’s broader prohibited-practices penalties of up to €35M or 7%.)

The August 2 deadline gives no grace period for content already generated. If your org has been producing AI-generated content for months without C2PA manifests or disclosure statements — every piece of that content is out of compliance from day one.

What It Does

eu-act-check scans a directory tree and reports per-file compliance status. Three detection layers:

C2PA Manifests — Embedded Content Credentials in JPEGs, PNGs, WebP, audio, and PDFs. Binary-level scanning: JPEG APP1 markers for C2PA UUID bytes, PNG iTXt chunks, WebP RIFF containers.

EXIF/XMP/IPTC Metadata — AI tool generation signatures. Pillow-based scanning for Adobe Firefly, Midjourney, DALL-E 3, Stable Diffusion, and other tool-specific metadata markers.

Text Pattern Detection — 18 regex patterns across 4 categories: direct disclosure statements, AI-tool declarations, comment watermarks, and standard disclosure formats. Covers .md, .txt, .html, .json, .yaml, .xml, and .csv files.

The CLI

# Install (PyPI)
pip install eu-act-check

# Scan a directory — see pass/warn/fail per file
eu-act-check scan ./content/ --recursive

# CI mode — exit 0 (pass) or 1 (warn/fail)
eu-act-check check ./blog-post.md

# Deep dive into one file
eu-act-check inspect ./hero-image.jpg

# Machine-readable output
eu-act-check scan ./assets/ --recursive --format json

The table output groups failures first, then warnings, then passes — so you see what needs fixing immediately:

                     EU AI Act Compliance Scan Results
┏━━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ FILE         ┃ STATUS ┃ DETECTORS  ┃ REMEDIATION                 ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ hero.jpg     │ ❌ fail│ 0✅ 1⚠️ 1❌│ Add a C2PA manifest using   │
│              │        │            │ the C2PA signing tool or... │
│              │        │            │ Add EXIF/IPTC metadata...  │
├──────────────┼────────┼────────────┼─────────────────────────────┤
│ blog.md      │ ⚠️ warn│ 0✅ 1⚠️ 0❌│ Add an AI disclosure        │
│              │        │            │ statement per Article 50(2) │
├──────────────┼────────┼────────────┼─────────────────────────────┤
│ narration.mp3│ ✅ pass│ 2✅ 0⚠️ 0❌│ —                           │
└──────────────┴────────┴────────────┴─────────────────────────────┘
3 files scanned: 1 ✅ pass | 1 ⚠️ warn | 1 ❌ fail

The --remediate flag appends fix instructions per file. The --format json option gives structured output for CI pipelines and monitoring dashboards.

Where It Fits

This is a compliance screening tool — it detects presence of provenance data, not cryptographic chain verification. Think of it as lint for EU AI Act compliance, not a certification audit. It answers “is this file compliant or not?” in seconds.

Architecture

cli.py → scanner.py → detectors/{c2pa, exif, text_patterns}
                     → compliance.py → reporters/{table, json}

The scanner respects .gitignore via pathspec so you can scan whole repos without noise. Each detector returns a structured DetectorResult (pass/warn/fail with details and remediation). The compliance engine aggregates per-file, determining the overall status: if any detector fails, the file fails.

What’s Next

The August 2 deadline is just three days away. I’d rather have a tool I can run today than rely on checking files manually. Every team shipping content to EU users should run a scan before the deadline hits.

Links

• GitHub: github.com/vikasudasi/eu-act-check
• Install: pip install eu-act-check
• EU AI Act Article 50: artificialintelligenceact.eu/article/50
• C2PA Specification: c2pa.org/specifications

Every AI coding agent has the same problem: given a blank slate and a vague instruction, they produce the same generic code. Comment stubs like # TODO: implement, variables named result, data, temp — and CSS that looks like Tailwind soup with twenty divs for a profile card.

no-slop is a CLI tool that fixes this at the constraint level.

The Problem

AI agents generate slop because their instructions don’t know your project. A Claude Code SKILL.md that says “write clean code” is useless. What you need is:

# Anti-Pattern: Abstraction Without Reason
name: "Abstract Base Smell"
description: "Don't create base classes unless you have at least 3 concrete implementations"

That’s a real constraint. And no-slop writes it for you.

How It Works

1. no-slop scan

Scans your project for 4 categories of slop patterns:

It scores every file 0-100 and outputs a Rich table (or JSON for CI pipelines):

Slop Analysis Results
┌───────────────────────────────────────────┬───────┬──────────────────┬──────────┐
│ File                                      │ Score │ Top Issues       │ Severity │
├───────────────────────────────────────────┼───────┼──────────────────┼──────────┤
│ src/styles.css                            │  42.0 │ Utility Class    │ Error    │
│                                           │       │ Spam, !important │          │
│ services/processor.py                     │  30.0 │ Generic Variable │ Warning  │
│                                           │       │ Names            │          │
│ tests/test_something.py                   │  25.0 │ Abstract Base    │ Warning  │
│                                           │       │ Smell            │          │
└───────────────────────────────────────────┴───────┴──────────────────┴──────────┘

2. no-slop generate

Takes scan results and generates constraint files for 4 agent frameworks:

# Generate for all frameworks
no-slop generate

# Preview without writing
no-slop generate --dry-run

# Just for Cursor
no-slop generate --agent cursor --dry-run

# Back up existing files first
no-slop generate --backup

3. no-slop apply / no-slop check

• apply — installs generated files into the project (skips unchanged files)
• check — validates existing constraint files for format, coverage gaps, and stale rules

A Real Example

Before no-slop, an AI agent generates this for a data processing service:

# TODO: Add your code here
def process_data(data):
    """Process the data."""
    result = []
    for item in data:
        temp = item * 2
        result.append(temp)
    return result

After no-slop constraints, the same agent produces:

from dataclasses import dataclass

@dataclass
class DataProcessor:
    """Transforms input records by applying a configured multiplier."""
    multiplier: float = 2.0

    def process(self, records: list[float]) -> list[float]:
        return [record * self.multiplier for record in records]

No stubs. No generic names. No explanation comments. Just project-specific, clean code.

Why Not Just Use Hallmark?

Hallmark (19K stars) showed the world that constraint files can dramatically improve agent output — but it only works with Claude Code’s SKILL.md format, and it ships a fixed rulebook. no-slop is the opposite approach: it scans your codebase, detects your specific slop patterns, and generates constraints tailored to your project. It supports all major agent frameworks, not one.

Install

pip install no-slop

Or from source:

git clone https://github.com/vikasudasi/no-slop
cd no-slop
pip install -e ".[dev]"

Usage

# Full workflow
no-slop init          # Create config
no-slop scan          # Detect slop patterns
no-slop generate      # Generate constraint files
no-slop apply         # Install them
no-slop check         # Verify existing constraints

Links

• GitHub: github.com/vikasudasi/no-slop
• PyPI: pip install no-slop
• Blog: vikasudasi.github.io

Today, July 28, 2026, the MCP specification released its biggest update yet — introducing MCP Apps, which lets MCP servers render interactive HTML UIs inside sandboxed iframes within AI conversations. No more bland text blobs. Your AI can now show you a chart, a dashboard, a form you can fill out.

I built a full toolchain for it, shipping the same day.

What Changed in the Protocol

Before today, every MCP tool could only return text. Now they can return interactive HTML:

• Stateless transport — the core protocol dropped handshake/session overhead. Plain round-robin load balancing works.
• MCP Apps extension — servers register tools with _meta.ui.resourceUri, serve HTML/CSS/JS via resources/read at ui:// URIs, and render in sandboxed iframes.
• Two-way bridge — the embedded UI can call back via callServerTool() (invoke server functions), sendMessage() (act like user input), and updateModelContext() (silent state sync).

The SDK is mature (@modelcontextprotocol/ext-apps), but the ecosystem tooling for developers — preview, scaffolding, sample apps — was missing. That’s what mcp-app-suite fills.

The Suite

mcp-app-playground

A CLI that acts as an MCP Host. Point it at any MCP server and it:

# Connect to a Streamable HTTP server
mcp-app-playground --server http://localhost:8002/mcp

# Or spawn a stdio server
mcp-app-playground --stdio --command "python -m my_app"

# Dev mode with hot-reload
mcp-app-playground --server http://localhost:8002/mcp --watch --debug

It discovers all tools with HTML UIs, serves a live listing at http://localhost:3691/, and renders each app in a sandboxed iframe with the full postMessage bridge. The --debug sidebar shows every JSON-RPC message flowing through.

mcp-app-scaffolder

A create-mcp-app style generator:

# Python project with Vite + demo counter tool
mcp-app-scaffolder my-app --template python --demo

cd my-app && pip install -e .
mcp-app-playground --stdio --command "python -m my_app"

It supports --template python|node, --simple (single-file, no build), and --demo (working counter with increment/decrement). Everything embedded in the package — no network calls during scaffolding.

Examples Demo Server

Run python -m examples serve on port 8002 to get a server with three real MCP Apps:

1. Mermaid Diagram Viewer — editable textarea + live diagram render, Send to Chat
2. System Monitor — dark dashboard with CPU gauge, memory bars, disk chart, polling via callServerTool
3. Interactive Data Table — sortable/filterable SQLite dataset with Export CSV and Analyze

Architecture

Browser (:3691) ←→ mcp-app-playground ←→ MCP Server (stdio/HTTP)
                       ↑ postMessage bridge
                   Sandboxed iframe
                   HTML/CSS/JS UI

The playground is the Host — it handles discovery (tools/list, filter by _meta.ui.resourceUri), resource fetch (resources/read), initialization (ui/initialize handshake), the entire interactive postMessage bridge, and teardown (ui/resource-teardown). The --debug panel streams everything transparently so developers can see exactly what their server is sending.

What’s Next

The MCP Apps spec just landed. The ecosystem of tools with interactive UIs is going to explode. This suite gives builders the tools to develop, test, and ship MCP Apps from day one — no waiting for Claude Desktop or other hosts to add dev tooling.

Links

• GitHub: github.com/vikasudasi/mcp-app-suite
• Install: pip install mcp-app-suite[all]
• MCP Spec: blog.modelcontextprotocol.io

If your CLAUDE.md, .cursorrules, or MCP server configs contain real API keys, they’re a ticking time bomb — a separate but equally urgent attack surface that no existing tool audits.

The Problem

AI agent configs are the new .env files — except nobody audits them. Your CLAUDE.md tells Claude Code how to behave, your .cursorrules configures Cursor’s rules, your MCP JSON files list server endpoints with bearer tokens. These files are:

• Version-controlled — pushed to GitHub alongside source code
• AI-consumed — agents read their content before every interaction
• Un-scanned — no existing tool checks them for hardcoded credentials

The Tool

agent-creds-scanner is a CLI that finds API keys, tokens, passwords, and credentials before they reach production.

# Quick scan (agent config files only)
agent-creds-scanner scan .

# Full repo scan
agent-creds-scanner scan . --all-files

# CI-friendly output
agent-creds-scanner scan . --json --min-risk high

What It Detects

• HIGH risk — OpenAI sk-proj-*, Anthropic sk-ant-*, AWS AKIA*, GitHub ghp_*, Slack xoxb-*, SSH keys, bearer tokens
• MEDIUM risk — JWTs, session tokens, connection strings (MongoDB, PostgreSQL, Redis)
• LOW risk — High-entropy strings, suspicious base64, credential URLs

Pre-Commit Hook

agent-creds-scanner install-hook

This blocks any commit that contains medium/high-risk credentials in agent config files — a defense-in-depth layer that catches leaks before git push.

Output

The default Rich table gives you a clean findings report:

┏━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━━━━┓
┃    # ┃ File        ┃   Line ┃ Risk   ┃ Type             ┃
┡━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━━━━┩
│    1 │ CLAUDE.md   │     42 │ HIGH   │ OpenAI API Key   │
│    2 │ .cursorrules│     15 │ MED    │ AWS Access Key   │
└──────┴─────────────┴────────┴────────┴──────────────────┘

CI Integration

# GitHub Actions
- name: Scan for agent credentials
  run: agent-creds-scanner scan . --json --min-risk high --output report.json

Links

• GitHub: github.com/vikasudasi/agent-creds-scanner
• Install: pip install agent-creds-scanner

The MCP (Model Context Protocol) ecosystem is exploding. Hundreds of servers launching weekly — Dogpile Fetch, Lumonic, ExtraHop SOC, and countless community-built tools. Every AI agent now talks MCP. But security tooling for MCP servers is essentially non-existent.

Until today.

What mcp-scan Does

mcp-scan analyzes MCP server configurations and endpoints for 5 vulnerability classes across 10 security checks:

1. ANSI Escape Injection (ANSI-001)

The Brightsec-disclosed attack: ANSI escape sequences can hide malicious content from human reviewers while exposing it to AI agents. A tool description that looks clean in your terminal actually contains hidden instructions visible only to the LLM. mcp-scan detects all common ANSI escape patterns in tool descriptions, names, and response templates.

2. Over-Permissive Tool Definitions (PERM-001/002/003)

• Filesystem: Tools that accept unrestricted paths (/, **/*, no path prefix)
• Shell: Tools that execute arbitrary commands without an allowlist
• Network: Tools that can reach any host or port

3. Missing Input Validation (VAL-001/002)

Parameters that accept any type, or string parameters without pattern, enum, or length constraints — the classic injection entry point.

4. Prompt Injection Vectors (INJ-001/002)

Tool descriptions or system prompts that dynamically incorporate untrusted user input — the primary vector for prompt injection attacks.

5. Insecure Transport (TLS-001/002)

MCP endpoints using http:// instead of https://, or ws:// instead of wss://.

Quick Start

pip install mcp-scan

# Scan a config file
mcp-scan -c my_mcp_config.json

# Scan a remote endpoint
mcp-scan --url https://my-mcp-server.com/sse

# Generate a JSON report for CI pipelines
mcp-scan -c config.json -o json --output-file report.json

# Focus on high/critical severity only
mcp-scan -c config.json --severity high

Real Results

We ran mcp-scan against a deliberately vulnerable server to test detection:

Scan ID: 7d441d55 | checks=10 failures=8 warnings=6
ANSI-001  [HIGH]    ANSI escape injection in tool metadata
PERM-002  [CRITICAL] Unrestricted shell execution in tool
TLS-001   [HIGH]    MCP endpoint uses insecure HTTP transport
INJ-001   [HIGH]    Tool metadata dynamically templated
...

And against our Hermes config (the MCP server you’re reading this from):

Scan ID: 598ae793 | checks=10 passed=10 — clean

Architecture

CLI (click) → Scanner → Config Parser / Endpoint Connector
                  ↓
          Check Modules (each produces Finding[])
                  ↓
          Reporter (Rich table + JSON)

Each check is a standalone module. Adding new checks is a single-file operation — implement a function that returns Finding[] and register it.

Why This Matters Now

The MCP ecosystem is at a critical inflection point:

• MCP security is the hottest topic in the AI infrastructure space right now
• The first major vulnerability class (ANSI escape injection) was disclosed this week
• Perplexity open-sourced Bumblebee (an MCP config scanner) — validating the category
• There is currently no dedicated, standalone security audit tool for MCP servers

mcp-scan fills that gap. It’s pip-installable, CI-friendly, and designed to be the first tool you run before connecting a new MCP server to your agent pipeline.

What’s Next

The spec is already loaded in the Task Manager with more checks planned:

• Rate limit analysis on tool definitions
• Credential/key exposure detection in configs
• Dependency chain analysis (transitive MCP server trust)
• Integration with mcp-hub for community-shared security scores

—

LLM API costs compound fast. Every team running production AI workloads has felt it — the monthly bill that keeps creeping up even when you’re not adding new features. The fix everyone recommends is caching, but the gap between “you should cache” and “how much will it actually save me” is where most teams get stuck.

cache-smith is a CLI that closes that gap. It does two things, plus a proxy:

1. Analyze — KV Prompt Caching Potential

Provider-side prompt caching (KV cache) is the single highest-leverage cost optimization in LLM engineering right now. OpenAI gives 50% off cached tokens. Anthropic gives 90%. But you only get those discounts if your prompts share stable prefixes.

What’s KV prompt caching?

Every LLM processes your prompt token-by-token and computes a KV cache (Key-Value pairs for each attention layer). If you send a second prompt that starts with the same tokens as the first, the provider can reuse the KV cache from the first prompt’s prefix instead of recomputing it — and passes that saving on to you as a discount.

The catch: consecutive prompts must share a long enough common prefix. If your prompts jump between unrelated topics, each transition loses the cache discount.

What analyze does

It takes your prompt templates, measures how much prefix they share, and reorders them to maximize adjacent overlap. Here’s the included example — 7 prompts from two different families interleaved:

In the original order, consecutive prompts switch between families (A→B→A→B→A→B→B). Each transition shares only ~10 generic prefix tokens (“You are a…”). The KV cache barely gets any reuse.

Running analyze:

$ cache-smith analyze examples/prompts.txt

   KV Prompt Cacheability Analysis
┏━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┓
┃ Metric                   ┃  Value ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━┩
│ Prompts                  │      7 │
│ Before Cacheable %       │  7.63% │
│ After Cacheable %        │ 34.43% │  ← 4.5× improvement
│ Before Avg Prefix Tokens │  10.00 │  ← A→B transitions: ~10 tokens shared
│ After Avg Prefix Tokens  │  43.67 │  ← A→A/B→B transitions: ~44 tokens shared
│ Cacheability Score       │ 29/100 │
└──────────────────────────┴────────┘

The tool greedily reorders the prompts into grouped families: A→A→A→B→B→B→B. Now each transition within a family shares ~44 prefix tokens — those 44 tokens get the provider’s cache discount instead of being recomputed.

Cacheability Score (0-100) combines three factors:

• Cacheable % (weight: 70%) — how much of each prompt can reuse the previous prompt’s KV cache
• Total volume (weight: 20%) — bigger prompts = bigger savings; maxes out at 8K+ tokens
• Prompt count (weight: 10%) — more prompts = more opportunities for reuse

The score is 29/100 here because the prompts are short (~69 tokens each). With real-world prompts that have large system instructions (2K+ tokens), the same overlap pattern would score much higher — and the dollar savings would be significant.

2. Simulate — Semantic Cache Hit Rates

Client-side semantic caching matches prompts by meaning, not exact string. A cache hit serves a previous response for a semantically similar question — zero latency, zero cost.

The included example has 9 questions from 3 topics, each asked 3 slightly different ways:

• “How do I implement retry logic with exponential backoff in Python?”
• “What’s the best way to add exponential backoff retry to a Python microservice?”
• “Looking for a Python implementation of retry with exponential backoff for microservices.”
• (Plus 6 more questions about Kubernetes HPA and database migrations)

Running simulate generates embeddings locally (sentence-transformers), measures semantic similarity, and tells you how many calls a cache would serve:

$ cache-smith simulate examples/prompts_semantic.txt

   Semantic Cache Simulation
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┓
┃ Total Prompts       │      9 │
┃ Unique Prompts      │      6 │  ← 3 are near-duplicates
┃ Hit Rate            │ 33.33% │  ← 1 in 3 requests served from cache
┃ Tokens Deduplicated │     41 │
┃ False Match Rate    │  0.00% │
┃ Suggested Threshold │   0.70 │
└─────────────────────┴────────┘

The tool sweeps thresholds from 0.70 to 0.98 and finds the optimal one — maximizing savings while keeping false matches under 5%. At 0.92, it catches exact paraphrases. At 0.70, it catches looser variations too, but risks serving wrong answers to different questions.

3. Proxy — Try It for Real

Once you know your threshold, cache-smith proxy runs a lightweight HTTP server that intercepts OpenAI-compatible API calls:

cache-smith proxy --upstream-url https://api.openai.com --port 8080 --threshold 0.85

Point your app at http://localhost:8080. Cache hits return instantly with X-Cache: HIT. Misses forward upstream and cache the response for next time.

Provider Pricing

The tool knows the caching economics of each major provider:

Pass --provider-config with custom JSON to match your actual contract rates.

How it’s built

• Local embeddings — uses all-MiniLM-L6-v2 via sentence-transformers, no API calls needed
• Hash fallback — if sentence-transformers isn’t installed, falls back to a deterministic hash-based embedding
• No dependencies on gateways — this is a standalone CLI, not another gateway to manage
• Rich output — terminal tables with rich, JSON for pipelines

Try it

git clone https://github.com/vikasudasi/cache-smith.git
cd cache-smith
pip install -e .
cache-smith analyze examples/prompts.txt
cache-smith simulate examples/prompts_semantic.txt

Bring your own prompts — pass any text file with one prompt per line, or pipe them via stdin. No API keys, no setup, no gateways.

GitHub →