Skip to main content
Glama
Extiri

codemenu-mcp

by Extiri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

codemenu-mcp

MCP server for CodeMenu snippet manager.

Overview

This is a Model Context Protocol (MCP) server that provides integration with the CodeMenu local HTTP API, allowing AI assistants to access and search through code snippets stored in CodeMenu.

Related MCP server: mcp-code-snippets

Features

The server exposes the following tools for interacting with CodeMenu:

  • list_snippets - List snippets without full code content (to reduce token usage). Returns id, title, description, language, abbreviation, tags, and group info. Supports filtering by query, language, tag, or group.

  • get_snippet - Retrieve the full details of a specific snippet by ID, including complete code content

  • list_tags - List all available tags in CodeMenu

  • list_groups - List all available groups in CodeMenu

Prerequisites

  • CodeMenu must be running on your Mac (Learn more)

  • API must be enabled in CodeMenu settings (CodeMenu → Settings → API)

  • Node.js >= 18.0.0

CodeMenu API Setup

  1. Open CodeMenu

  2. Go to Settings → API

  3. Enable the API server

  4. Note the port (default: 1300)

  5. Optionally, set an API key for authentication

The CodeMenu API runs locally at http://127.0.0.1:1300/v1 by default.

Installation

From npm (when published)

npm install -g git+https://github.com/Extiri/codemenu-mcp.git

From source

git clone https://github.com/Extiri/codemenu-mcp.git
cd codemenu-mcp
npm install
npm link

Configuration

The server connects to the local CodeMenu API and supports the following environment variables:

Environment Variables

  • CODEMENU_API_URL - The base URL for the CodeMenu API (default: http://127.0.0.1:1300/v1)

  • CODEMENU_API_KEY - Your CodeMenu API key

Example Configuration for Claude Desktop

Add this to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "codemenu": {
      "command": "node",
      "args": ["/path/to/codemenu-mcp/index.js"],
      "env": {
        "CODEMENU_API_URL": "http://127.0.0.1:1300/v1",
        "CODEMENU_API_KEY": "your-api-key"
      }
    }
  }
}

Or if installed globally via npm:

{
  "mcpServers": {
    "codemenu": {
      "command": "codemenu-mcp",
      "env": {
        "CODEMENU_API_KEY": "your-api-key"
      }
    }
  }
}

Note: If you didn't enable API key protection in CodeMenu settings, you can omit the CODEMENU_API_KEY environment variable.

Usage

Once configured, the server will be automatically started by your MCP client (e.g., Claude Desktop). The AI assistant will have access to your CodeMenu snippets and can:

  • Browse and search through your code snippets

  • Find snippets by language, tags, or groups

  • Retrieve specific snippets with full code content when needed

  • List available tags and groups for better organization

Example Interactions

Searching snippets:

"Search my CodeMenu snippets for sorting algorithms"

Listing snippets by language:

"Show me all my JavaScript snippets from CodeMenu"

Getting a specific snippet:

"Show me the full code for snippet ID ABC123"

Listing tags:

"What tags do I have in CodeMenu?"

Development

Running the Server

npm start

The server communicates over stdio, which is the standard transport for MCP servers.

Testing

npm test

This validates that the server correctly implements the MCP protocol. To test actual API calls, make sure CodeMenu is running with the API enabled.

Project Structure

  • index.js - Main server implementation

  • package.json - Project metadata and dependencies

  • test.js - MCP protocol test suite

  • README.md - This file

  • LICENSE - MIT license

  • .gitignore - Files to exclude from git

API Reference

The server implements the Model Context Protocol and exposes tools that correspond to CodeMenu API endpoints:

  • GET /snippets - List snippets with optional filters (query, language, tag, group)

  • GET /tags - List all tags

  • GET /groups - List all groups

For detailed information about the CodeMenu API, refer to the CodeMenu API documentation.

Requirements

  • Node.js >= 18.0.0

  • CodeMenu application with API enabled

  • MCP client (e.g., Claude Desktop)

License

MIT

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Support

For issues related to:

Troubleshooting

Server can't connect to CodeMenu:

  • Ensure CodeMenu application is running

  • Check that API is enabled in CodeMenu settings

  • Verify the port matches your configuration (default: 1300)

  • If you enabled API key protection, ensure CODEMENU_API_KEY is set correctly

No snippets returned:

  • Verify you have snippets in CodeMenu

  • Check that your search filters aren't too restrictive

  • Try listing without filters first

Authentication errors:

  • Check if the CODEMENU_API_KEY environment variable is set properly

Available Tools

4 tools
get_snippetA

Get full details of a specific snippet by ID, including the complete code content

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe unique identifier of the snippet (UUID format)

TDQS

A3.6/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 usefully discloses that the response includes the complete code content (a real behavioral detail distinguishing it from a listing call), but says nothing about permissions, not-found behavior, or whether the content is truncated for large snippets.

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?

One sentence, front-loaded with the action and lookup key, with the payload characteristic appended. No filler and nothing wasted.

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?

For a single-parameter read tool with no output schema and full parameter documentation, the description covers what it fetches and roughly what comes back. It stops short of describing the response shape or error cases, but nothing essential to correct invocation is missing.

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% and the single id parameter already specifies UUID format. The description only restates that lookup is by ID, adding no format or constraint detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (Get) and resource (a specific snippet) plus the retrieval key (by ID) and the depth of data returned (full details, complete code content). This implicitly separates it from list_snippets, which returns collections, though no sibling is named explicitly.

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?

Usage is implied: fetch this when you already have a snippet ID. There is no explicit when-to-use statement, no mention of what to do when you only have a name or tag, and no routing to list_snippets for discovery.

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

list_groupsB

List all groups available in CodeMenu

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden. 'List all' hints there is no filtering or pagination, but it says nothing about permissions, ordering, or result shape for a tool with zero structured coverage.

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?

A single short sentence with the verb and resource front-loaded and no wasted words. Nothing needs trimming.

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?

For a zero-parameter, no-output-schema listing tool the description is minimally adequate, but it omits any distinction from list_tags or note on what a returned group contains, leaving the agent to infer the boundary between 'groups' and 'tags'.

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

Parameters4/5

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

The tool takes no parameters, so the baseline for this dimension is 4. There is no parameter semantics to add beyond what the empty schema already conveys.

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 states a specific verb (list) and resource (groups) scoped to CodeMenu, so an agent can tell what it returns. It is clear but does no explicit sibling differentiation against list_tags or list_snippets, which are structurally similar list operations.

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?

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer this over the sibling list_tags or get_snippet. Usage is only implied by the verb.

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

list_snippetsA

List code snippets from CodeMenu without full code content (to reduce token usage). Returns id, title, description, language, abbreviation, tags, and group info.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagNoFilter by tag ID - returns snippets with this tag
groupNoFilter by group ID - returns snippets in this group
queryNoSearch query - returns snippets whose code, title, or description contain this text
languageNoFilter by programming language (e.g., javascript, python, swift)

TDQS

A3.5/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 burden, and it does disclose one meaningful trait: code content is deliberately omitted. However it says nothing about pagination, result limits, ordering, default behavior when no filters are supplied, or permissions.

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?

Two tight sentences, with the key behavioral fact (no code content) front-loaded and the return shape following. Every clause carries information, though the return-field list is slightly enumerative.

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?

With no output schema, the description usefully enumerates the returned fields, which is exactly what an agent needs to know before choosing this over get_snippet. The remaining gap is pagination/limit behavior for an unfiltered list call, which is not addressed.

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% with all four filters (tag, group, query, language) fully documented in the schema. The description adds no parameter-level semantics, so the baseline 3 applies.

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?

States a specific verb+resource ('List code snippets from CodeMenu') plus a clear scope qualifier ('without full code content, to reduce token usage'). This implicitly distinguishes it from get_snippet, but no sibling is named explicitly, so it falls short of a 5.

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?

The 'to reduce token usage' note hints that this is the lightweight browse path versus get_snippet for full code, but the when-to-use choice is never stated. No explicit conditions, exclusions, or alternatives are given.

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

list_tagsB

List all tags available in CodeMenu

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.3/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 disclosure burden. It reveals no return format, ordering, pagination, or scoping behavior, but as a zero-parameter enumeration it is inherently low-risk, which limits how much disclosure is required.

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?

A single short sentence with no filler, and the key scope phrase is front-loaded after the verb. It is efficient, though it is arguably too terse to earn a top score.

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?

No output schema exists, so the description could reasonably say what the returned tags represent (workspace-scoped, global, sorted). For a trivial zero-param listing it is adequate but leaves the agent guessing about the shape and scope of results.

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

Parameters4/5

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

The tool takes no parameters, so there is no parameter semantics to document; the baseline of 4 applies. Nothing in the description misrepresents or omits an input.

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?

Specific verb 'List' plus resource 'tags', with the scope qualifier 'all tags available in CodeMenu'. This distinguishes it from the sibling list_snippets and list_groups by resource type, though the description does not explicitly note that distinction.

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?

The description gives no indication of when to call this tool versus list_groups or list_snippets, nor any prerequisites or context for needing the tag vocabulary. Usage must be inferred entirely from the name.

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. 4 tool updatesv2.0.0
    • First observedget_snippet
    • First observedlist_groups
    • First observedlist_snippets
    • First observedlist_tags
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.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a unique resource or action: get_snippet retrieves full content by ID, list_snippets returns metadata only, list_tags enumerates tags, and list_groups enumerates groups. There is no overlap in purpose, so an agent can easily select the right tool.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern with clear prefixes: get_ for single-item retrieval and list_ for collection enumeration. The naming is predictable and uniform across the set.

Tool Count4/5

Four tools is a compact set that covers reading and browsing snippets, tags, and groups. It is slightly under-scoped for a snippet manager because it omits search/filter or mutation tools, but each existing tool earns its place.

Completeness3/5

The read surface is partially complete: list_snippets and get_snippet cover snippet retrieval, and list_tags/list_groups expose metadata. However, there is no create, update, or delete for snippets, and no way to search or filter snippets by tag or group, which are notable gaps for a snippet management domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-code-snippets by qdrant

    mcp-code-snippetsofficial

    qdrant
    A
    license
    Not graded
    quality
    D
    maintenance
    Allows agents to lookup code snippets in your project. Uses a remote MCP server with a collection of code snippets, with support for automatic project language detection.
    12
    Apache 2.0

  • smart-coding-mcp

    amalikn
    A
    license
    A
    quality
    D
    maintenance
    Enables AI assistants to perform intelligent semantic code search across codebases using local AI embeddings for meaning-based retrieval.
    6
    5 npm
    MIT