Skip to main content
Glama
enesjakozh
truaxki

MCP Notes Server

by truaxki
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Servidor de notas MCP

insignia de herrería

Una implementación de servidor de Protocolo de Contexto de Modelo (MCP) para administrar notas con almacenamiento persistente.

Características

  • Crear, leer, actualizar y eliminar notas

  • Almacenamiento persistente mediante JSON

  • Seguimiento de marcas de tiempo para creación y modificaciones

  • Resumen de notas mediante indicaciones

  • Acceso basado en recursos mediante el esquema URI note://

Related MCP server: Beeper MCP Note Server

Instalación

Instalación mediante herrería

Para instalar notas para Claude Desktop automáticamente a través de Smithery :

npx -y @smithery/cli install notes --client claude

Instalación manual

  1. Asegúrese de tener instalado Python 3.10 o posterior

  2. Crear un entorno virtual:

    python -m venv .venv

# On Unix/MacOS:
source .venv/bin/activate

# On Windows:
.venv\Scripts\activate

  3. Requisitos de instalación:

    pip install MCP

Estructura del proyecto

notes/
├── __init__.py          # Package initialization
├── server.py           # Main server implementation
├── storage.py          # Note persistence layer
├── resources.py        # Resource handling (note:// URIs)
├── prompts.py         # LLM prompt generation
└── tools/             # Server tools
    ├── __init__.py    # Tools package initialization
    ├── list_tools.py  # Tool listing functionality
    └── handle_tools.py # Tool handling implementation

Herramientas disponibles

  • add-note : Crea una nueva nota

  • list-all-notes : Muestra todas las notas almacenadas

  • update-note : Modificar una nota existente

  • delete-note : Eliminar una nota

Uso

  1. Iniciar el servidor:

    mcp install src/notes
mcp start Notes

  2. Operaciones de ejemplo:

    # Create a note
await client.call_tool("add-note", {
    "name": "example",
    "content": "This is a test note"
})

# List all notes
await client.call_tool("list-all-notes")

# Update a note
await client.call_tool("update-note", {
    "name": "example",
    "content": "Updated content"
})

# Delete a note
await client.call_tool("delete-note", {
    "name": "example"
})

Almacenamiento

Las notas se almacenan en notes_storage.json con la siguiente estructura:

{
    "note_name": {
        "content": "Note content",
        "created_at": "2025-01-12T11:28:16.721704",
        "modified_at": "2025-01-12T11:28:16.721704"
    }
}

Acceso a recursos

Se puede acceder a las notas como recursos utilizando el esquema URI note:// :

  • Lista de recursos: devuelve todas las notas disponibles como recursos

  • Leer recurso: Acceder a una nota específica usando note://internal/note_name

Generación de indicaciones

El servidor incluye una función de generación de indicaciones para resumir notas:

  • Admite resúmenes breves y detallados

  • Notas de formato para la entrada del modelo de lenguaje

  • Disponible a través del mensaje "resumir notas"

Desarrollo

Para modificar o ampliar el servidor:

  1. Clonar el repositorio

  2. Instalar dependencias de desarrollo

  3. Realizar cambios en el módulo apropiado

  4. Pruebe exhaustivamente antes de implementar

Pruebas

Las pruebas deben cubrir:

  • Operaciones CRUD básicas

  • Manejo de múltiples notas

  • Casos de error

  • Acceso a recursos

  • Generación de mensajes rápidos

Licencia

[Agregue su licencia aquí]

Available Tools

4 tools
add-noteC

Create a new note

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes
nameYes

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new note' implies a write operation but doesn't specify permissions needed, whether it's idempotent, error handling, or what happens on success (e.g., returns a note ID). This leaves significant gaps for a mutation tool.

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, efficient sentence with zero wasted words. It's front-loaded and appropriately sized for a basic tool, though this conciseness comes at the cost of detail.

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?

For a mutation tool with 2 required parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or parameter semantics, leaving the agent poorly equipped to use it correctly.

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

Parameters2/5

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

Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds no information about the 'content' and 'name' parameters—their meaning, format, constraints, or examples. This fails to compensate for the schema's lack of descriptions.

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 'Create a new note' clearly states the action (create) and resource (note), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update-note' or 'delete-note' beyond the basic verb, which prevents a perfect score.

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 provides no guidance on when to use this tool versus alternatives like 'update-note' or 'list-all-notes'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.

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

delete-noteC

Delete an existing note

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a note, implying a destructive mutation, but fails to address critical aspects like permissions needed, whether deletion is permanent or reversible, error handling, or confirmation requirements. This is a significant gap for a mutation tool.

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, efficient sentence with no wasted words, making it easy to parse. It is appropriately sized for a simple tool, though this conciseness comes at the cost of detail in other dimensions.

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?

For a destructive mutation tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It lacks essential context such as behavioral traits, parameter details, and output expectations, making it incomplete for safe and effective use by an agent.

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

Parameters2/5

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

The schema description coverage is 0%, and the description provides no information about the 'name' parameter beyond what the schema indicates (a required string). It doesn't explain what 'name' refers to (e.g., note title, ID, filename) or its format, leaving the parameter's meaning unclear.

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 verb ('Delete') and resource ('an existing note'), making the tool's function unambiguous. However, it doesn't distinguish this tool from its sibling 'update-note' in terms of destructive vs. non-destructive operations, which would require explicit differentiation for a perfect score.

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 provides no guidance on when to use this tool versus alternatives like 'update-note' or prerequisites such as note existence. It lacks explicit context about usage scenarios or exclusions, leaving the agent to infer based on tool names alone.

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

list-all-notesB

Read all stored notes

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 full burden for behavioral disclosure. It states 'Read all stored notes,' which implies a safe, read-only operation, but fails to add context like whether it returns all notes at once, uses pagination, requires authentication, or has rate limits. This leaves significant gaps in understanding the tool's behavior.

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 'Read all stored notes' is a single, efficient sentence that front-loads the core purpose with zero waste. It is appropriately sized for a simple tool, making it easy for an agent to parse and understand quickly.

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 tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states the basic action but lacks details on behavior (e.g., return format, pagination) that would be helpful for a read operation, especially without annotations to cover safety or performance aspects.

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 has 0 parameters, with schema description coverage at 100%, so no parameter documentation is needed. The description appropriately doesn't mention parameters, aligning with the schema, and thus meets the baseline for a parameterless tool without adding unnecessary details.

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 'Read all stored notes' clearly states the verb ('Read') and resource ('all stored notes'), making the tool's purpose immediately understandable. It distinguishes from siblings like 'add-note' or 'delete-note' by specifying a read-only operation, though it doesn't explicitly contrast with potential filtering alternatives beyond the scope of siblings.

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 provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, timing, or comparisons to other tools (e.g., if there are filtering options not listed as siblings), leaving the agent with minimal usage direction beyond the basic purpose.

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

update-noteC

Update an existing note

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes
nameYes

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'update' implies a mutation, but it doesn't disclose any behavioral traits such as required permissions, whether the update is reversible, error handling, or rate limits. This is a significant gap for a mutation tool with zero annotation coverage, making it minimally transparent.

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, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration. This exemplifies conciseness, though it may be overly brief given the lack of other information.

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 complexity of a mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't cover parameter meanings, behavioral aspects, usage context, or return values. This inadequacy makes it insufficient for effective agent use, as it leaves critical gaps in understanding.

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

Parameters2/5

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

Schema description coverage is 0%, so the schema provides no parameter details. The description adds no meaning beyond the tool name; it doesn't explain what 'content' and 'name' parameters represent, their formats, or how they interact. This fails to compensate for the lack of schema documentation, leaving parameters largely undocumented.

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

Purpose3/5

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

The description 'Update an existing note' clearly states the verb ('update') and resource ('note'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add-note' or 'delete-note' beyond the basic action, and it lacks specificity about what aspects of the note are updated. This makes it vague but adequate for minimum viability.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a note must exist to update it), contrast with 'add-note' for creation or 'delete-note' for removal, or specify any context for usage. This absence of guidance leaves the agent without direction on tool selection.

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 updatesv1.0.0
    • First observedadd-note
    • First observeddelete-note
    • First observedlist-all-notes
    • First observedupdate-note
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

B3.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific CRUD operations on notes: add-note for creation, delete-note for deletion, list-all-notes for reading all, and update-note for updates. There is no overlap in functionality, making tool selection unambiguous.

Naming Consistency4/5

The tools follow a mostly consistent verb-noun pattern (add-note, delete-note, update-note), but list-all-notes deviates slightly by including 'all'. This minor inconsistency does not significantly hinder readability or predictability.

Tool Count5/5

With 4 tools, the server is well-scoped for a notes management system, covering the essential CRUD operations. Each tool earns its place without being overly sparse or bloated, fitting the typical 3-15 tool range appropriately.

Completeness5/5

The tool set provides complete CRUD coverage for the notes domain: create (add-note), read (list-all-notes), update (update-note), and delete (delete-note). There are no obvious gaps, allowing agents to handle full note lifecycles without dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches