Skip to main content
Glama
naveenayalla1-CS50

Naveen Ayalla

by naveenayalla1-CS50
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

🔌 MCP Server Toolkit

| mcp-memory | npx mcp-memory | Persist and recall architecture decisions, patterns, constraints, and project context |

Build plug-and-play MCP servers for any dev workflow — code search, docs, databases, and more.

  • 🧠 Persistent project memory — Remember architecture decisions, patterns, constraints, and project conventions across AI coding sessions. npm version MCP License: MIT TypeScript Works with Claude Code Works with Cursor Works with Windsurf PRs Welcome Stars | mcp-memory | npx mcp-memory | Persist and recall architecture decisions, patterns, constraints, and project context | Give any AI coding agent a direct line into your codebase, docs, or database — in under 60 seconds.

    M8ven Verified

Quick Start · Servers · Build Your Own · Discord · Changelog

Demo: Claude Code querying a codebase via MCP Server Toolkit

Why this exists

When you ask Claude Code "where do we handle Stripe webhooks?" it has two bad options:

  • Option A — Read every file in the repo. Slow, expensive, blows the context window on any real codebase.

  • Option B — Guess based on the first few files it sees. Wrong half the time.

MCP Server Toolkit gives agents a third option: ask the right tool directly. Semantic code search, live database queries, doc lookups, API introspection — all surfaced through the Model Context Protocol standard, so any MCP-compatible client can use them without any changes to your existing code.

Related MCP server: TypeScript Tools MCP

✨ Features

  • 🔍 Semantic code search — Find the right function, file, or pattern across your entire repo in milliseconds. Powered by vector embeddings, no Elasticsearch required.

  • 📚 Docs server — Give your agent instant access to any documentation site, local Markdown files, or Notion workspace.

  • 🗄️ Database server — Natural language → SQL for PostgreSQL, MySQL, and SQLite. Read-only by default, writable with an explicit flag.

  • 🌐 API introspection server — Load any OpenAPI/Swagger spec and let your agent browse and call endpoints with type safety.

  • ⚡ One-command setup — Every server ships as a standalone CLI. npx and pip install paths included.

  • 🔒 Zero-config secrets — Reads from your existing .env file or environment variables. Nothing new to learn.

  • 🧩 Works everywhere — Claude Code, Cursor, Windsurf, Cline, VS Code Copilot, Codex CLI, Gemini CLI, and every other MCP-compatible client.

  • 🛠️ Extensible — The createServer() helper reduces a new tool to ~15 lines of TypeScript. Scaffold a custom server in 30 seconds.

🚀 Quick Start

Requirements: Node.js 18+ or Python 3.10+

Option A — npx (no install)

npx mcp-server-toolkit@latest init

This runs the interactive setup wizard. Pick your servers, paste your credentials, and get a ready-to-paste config block for Claude Code / Cursor.

Option B — npm global install

npm install -g mcp-server-toolkit
mcp init

Option C — pip (Python environments)

pip install mcp-server-toolkit
mcp init

Add to Claude Code

After mcp init, copy the generated block into your .claude/mcp.json:

{
  "servers": {
    "code-search": {
      "command": "mcp-code-search",
      "args": ["--root", "."],
      "env": { "OPENAI_API_KEY": "${OPENAI_API_KEY}" }
    },
    "database": {
      "command": "mcp-database",
      "args": ["--read-only"],
      "env": { "DATABASE_URL": "${DATABASE_URL}" }
    },
    "docs": {
      "command": "mcp-docs",
      "args": ["--source", "./docs"]
    }
  }
}

That's it. Restart Claude Code and your agent now has full access to all three.

📦 Included Servers

Server

Install

What it does

mcp-code-search

npx mcp-code-search

Semantic + keyword search across your codebase

mcp-database

npx mcp-database

Natural language queries for Postgres, MySQL, SQLite

mcp-docs

npx mcp-docs

Index and query local Markdown, Notion, or any URL

mcp-openapi

npx mcp-openapi

Browse and call endpoints from any OpenAPI spec

mcp-git

npx mcp-git

Query commits, diffs, blame, and branches

mcp-shell

npx mcp-shell

Sandboxed shell execution with allowlist controls

All servers are independently installable — use one or all of them.

🛠️ Usage Example

Once installed, your AI agent can use natural language to interact with your entire dev environment:

You:  "Find all places where we validate user input before inserting into the DB"

Agent uses mcp-code-search →
  Found 7 matches in: auth/validators.ts, api/users.ts, api/orders.ts...

You:  "How many users signed up in the last 7 days?"

Agent uses mcp-database →
  SELECT count(*) FROM users WHERE created_at > now() - interval '7 days';
  → 1,432 new users

You:  "What does our docs say about rate limiting?"

Agent uses mcp-docs →
  Found in docs/api/rate-limits.md: "All endpoints are limited to 100 req/min per API key..."

No copy-pasting. No context switching. The agent just knows.

🔧 Build Your Own Server

Scaffold a new server in 30 seconds:

mcp new my-server --template typescript

This generates:

my-server/
├── src/
│   ├── index.ts        # Entry point — register your tools here
│   └── tools/
│       └── example.ts  # Your first tool
├── package.json
└── README.md

A minimal tool looks like this:

import { createServer, tool, z } from 'mcp-server-toolkit';

const server = createServer({ name: 'my-server', version: '1.0.0' });

server.addTool(
  tool({
    name: 'get_weather',
    description: 'Get current weather for a city',
    input: z.object({ city: z.string() }),
    run: async ({ city }) => {
      const data = await fetchWeather(city);
      return { content: `${city}: ${data.temp}°C, ${data.condition}` };
    },
  })
);

server.start();

That's the whole thing. Ship it.

📁 Project Structure

mcp-server-toolkit/
├── packages/
│   ├── core/           # createServer(), tool(), z helpers
│   ├── code-search/    # Semantic codebase search server
│   ├── database/       # Natural language DB query server
│   ├── docs/           # Documentation indexing server
│   ├── openapi/        # OpenAPI spec introspection server
│   ├── git/            # Git history and diff server
│   └── shell/          # Sandboxed shell server
├── examples/
│   ├── claude-code/    # Drop-in config for Claude Code
│   ├── cursor/         # Drop-in config for Cursor
│   └── custom-server/  # Starter template for custom tools
├── docs/               # Full documentation
└── CONTRIBUTING.md

🗺️ Roadmap

  • Code search (semantic + keyword)

  • PostgreSQL / MySQL / SQLite server

  • Docs server (Markdown + URL crawl)

  • OpenAPI introspection server

  • Notion server

  • Linear / Jira server

  • Supabase + PlanetScale managed DB support

  • Web UI for browsing registered tools

  • Auto-generated tool descriptions from schema

Want something on this list prioritised? Open an issue and add a 👍.

🤝 Contributing

Contributions are what make this project worth starring. Here's how to get involved:

First time?

  1. Look for issues labelled good first issue — these are scoped small on purpose.

  2. Comment on the issue to claim it before starting.

  3. Fork the repo, make your changes, open a PR.

Adding a new server

The fastest path to a merged PR:

# Clone and install deps
git clone https://github.com/naveenayalla1-CS50/mcp-server-toolkit
cd mcp-server-toolkit
npm install

# Scaffold your server
npm run new-server -- --name my-awesome-server

# Run tests
npm test

# Submit your PR

Each new server needs:

  • A README.md explaining what it does and the one-line install command

  • At least one test in __tests__/

  • An example config block for Claude Code / Cursor

Guidelines

  • Keep each tool focused on doing one thing well — resist scope creep.

  • Never store credentials in code — always read from env vars.

  • Add your server to the table in the main README and to the packages/ list.

Code of Conduct

Be excellent to each other. See CODE_OF_CONDUCT.md.

🔐 Security

  • All servers are read-only by default. Write access requires an explicit --writable flag.

  • Credentials are read from environment variables only — never hardcoded or logged.

  • The shell server uses an allowlist (mcp-shell.config.json) — no arbitrary command execution.

  • Found a vulnerability? Please email security@naveenayalla1-CS50.dev instead of opening a public issue.

📄 License

MIT © 2026 naveenayalla1-CS50

You're free to use this in personal projects, commercial products, and anything in between. Attribution appreciated but not required.

Share on Twitter · Open an issue

Built with ❤️ for the agent era.

MCP server usage

This repository contains a TypeScript/Node.js toolkit of MCP servers.

Install

npm install
npm run build
npm run build --workspace=@mcp-toolkit/core
npm run build --workspace=@mcp-toolkit/code-search
node packages/code-search/dist/index.js



## MCP server usage

This repository contains a TypeScript/Node.js toolkit of MCP servers.

### Install

```bash
npm install
npm run build

Available Tools

3 tools
list_filesB

List files in the codebase matching a glob pattern.

ParametersJSON Schema
NameRequiredDescriptionDefault
patternNoGlob pattern, e.g. "src/**/*.ts"

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It discloses the basic behavior (listing files matching a glob), but does not mention details like recursion, return format, or limits. Adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single sentence with no unnecessary words. Front-loaded and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (one optional parameter, no annotations, no output schema), the description is minimally complete but lacks details about return values or behavior. It does not fully equip the agent for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline 3 is appropriate; the description offers no additional parameter context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists files matching a glob pattern. It is specific about the action and resource, but does not differentiate from sibling tools like search_code or read_file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description lacks context about appropriate use cases or exclusions, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_fileC

Read the full contents of a file.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoFile path relative to repo root

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits like file size limits, encoding, or side effects, but it only states the basic action. However, it is a read operation, so risk is low.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no unnecessary words. It communicates the core functionality efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one parameter, no output schema), the description minimally covers the purpose but omits details like return format, encoding, or limitations that would help an agent use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description 'File path relative to repo root' is adequate. The tool description adds no further meaning beyond the schema, so baseline score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads the full contents of a file, using a specific verb and resource. It implicitly distinguishes from siblings like list_files (listing) and search_code (searching), though not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_files or search_code. The description does not mention prerequisites, context, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_codeA

Search for a keyword or pattern across the codebase. Returns file path, line number, and surrounding context.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoKeyword, function name, or pattern to search for
filePatternNoGlob pattern to limit search, e.g. "**/*.ts"
maxResultsNoMax results to return (default 20)

TDQS

A3.7/5.0
Behavior3/5

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 basic behavior (search, return results), but lacks details such as case sensitivity, regex support, or permission requirements. The description is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences with no wasted words. It front-loads the purpose and immediately states the return format. Slight improvement could be made by integrating usage guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, the description appropriately states what is returned. The parameters are fully described in the schema. The sibling tools provide context. Completeness is high for a search tool with moderate complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is already described. The tool description adds minimal extra meaning beyond 'keyword or pattern'. Baseline 3 is appropriate as no additional context is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search for a keyword or pattern'), the resource ('codebase'), and what is returned ('file path, line number, and surrounding context'). It is distinct from sibling tools list_files and read_file, which focus on listing and reading files, not searching content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The context implies it is for finding code occurrences, but there is no mention of when not to use it or alternative strategies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedlist_files
    • First observedread_file
    • First observedsearch_code
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: listing files, reading contents, and searching code. No overlap or confusion possible.

Naming Consistency5/5

All tools use consistent verb_noun naming: list_files, read_file, search_code. The pattern is uniform and predictable.

Tool Count4/5

Three tools is minimal but well-scoped for a basic codebase exploration server. It covers the essential operations without being overly sparse.

Completeness3/5

The set covers listing, reading, and searching files, but lacks directory listing or file metadata tools, which would be expected for full codebase navigation.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers