Capacities MCP Server
Capacities MCP Plus
Un servidor MCP (Model Context Protocol) mejorado para Capacities, que proporciona una integración perfecta con tu sistema de gestión de conocimiento.
Nota: Este es un fork de jemgold/capacities-mcp con características y correcciones adicionales.
Diferencias con el original
Característica | Original | Plus |
Leer contenido del objeto | No disponible | Recuperar el contenido completo de la nota por ID de objeto |
Versión de fastmcp | 1.27.3 | 3.25.4 (corrige la compatibilidad con el SDK de MCP) |
Soporte para Windows | Puede tener problemas | Probado con wrapper cmd |
Paquete npm |
|
|
Nueva herramienta: capacities_read_object_content
Recupera el contenido completo de cualquier objeto de Capacities mediante su ID:
Prueba primero los endpoints de API no documentados para una recuperación directa
Recurre a la agregación de la API de búsqueda cuando el acceso directo no está disponible
Proporciona un parámetro de título para mejorar la precisión de la búsqueda
Related MCP server: ClickUp MCP Server
Características
Este servidor MCP proporciona acceso a todos los endpoints actuales de la API de Capacities:
Listar espacios - Obtén todos tus espacios personales
Información del espacio - Recupera estructuras y colecciones detalladas de los espacios
Buscar contenido - Busca en todos los espacios con filtrado avanzado
Leer contenido del objeto - Recupera el contenido completo de la nota por ID de objeto
Guardar enlaces web - Guarda URLs en tus espacios con metadatos
Notas diarias - Añade contenido a tus notas diarias
Instalación
Para Claude Desktop (macOS)
Añádelo a tu configuración de Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"capacities": {
"command": "npx",
"args": ["-y", "capacities-mcp-plus"],
"env": {
"CAPACITIES_API_KEY": "your_capacities_api_key_here"
}
}
}
}Para Claude Desktop (Windows)
Windows requiere un wrapper cmd. Añádelo a %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"capacities": {
"command": "cmd",
"args": ["/c", "npx", "-y", "capacities-mcp-plus"],
"env": {
"CAPACITIES_API_KEY": "your_capacities_api_key_here"
}
}
}
}Obtén tu clave de API de Capacities desde la configuración de tu cuenta de Capacities.
¡Eso es todo! El servidor se descargará y ejecutará automáticamente cuando inicies Claude Desktop.
Desarrollo
Configuración local
Para el desarrollo local, necesitarás clonar y compilar el proyecto:
Clona este repositorio:
git clone https://github.com/Im-Hal-9K/capacities-mcp.git
cd capacities-mcpInstala las dependencias:
npm install
# or
bun installCopia el archivo de entorno de ejemplo:
cp .env.example .envAñade tu clave de API de Capacities a
.env:
CAPACITIES_API_KEY=your_api_key_hereCompila el servidor:
npm run buildEjecución del servidor
Inicia el servidor de desarrollo en modo interactivo:
bun run devPara uso en producción:
npm run startPara inspeccionar las herramientas y el esquema del servidor:
bun run inspectPruebas
Ejecuta la suite de pruebas:
bun run testCalidad del código
Comprueba el linting y los tipos:
bun run lintFormatea el código:
bun run formatReferencia de la API
Obtén tu clave de API de Capacities desde la configuración de tu cuenta de Capacities.
Para obtener documentación detallada de la API, consulta:
Herramientas disponibles
capacities_list_spaces
Obtén una lista de todos tus espacios personales.
capacities_get_space_info
Obtén información detallada sobre un espacio específico, incluyendo estructuras y colecciones.
spaceId: UUID del espacio
capacities_search
Busca contenido en tus espacios con filtrado opcional.
searchTerm: Texto a buscar
spaceIds: Matriz de UUIDs de espacios en los que buscar
mode (opcional): Modo de búsqueda "fullText" o "title"
filterStructureIds (opcional): Filtrar por tipos de estructura específicos
capacities_read_object_content
Recupera el contenido completo de un objeto de Capacities por su ID.
objectId: UUID del objeto a recuperar (se puede obtener desde 'Copiar referencia del objeto' en Capacities)
spaceId: UUID del espacio que contiene el objeto
title (opcional): El título o título parcial del objeto - se recomienda encarecidamente para mejorar los resultados de búsqueda
Cómo funciona:
Primero intenta usar endpoints GET no documentados para la recuperación directa del objeto
Recurre a la API de búsqueda, agregando contenido de destacados y fragmentos
Filtra los resultados de búsqueda por ID de objeto para encontrar la coincidencia exacta
Nota: Al usar el recurso de búsqueda, el contenido puede estar incompleto ya que se ensambla a partir de fragmentos de búsqueda. Proporcionar el parámetro de título mejora significativamente los resultados.
capacities_save_weblink
Guarda un enlace web en un espacio con metadatos opcionales.
spaceId: UUID del espacio de destino
url: La URL a guardar
titleOverwrite (opcional): Título personalizado para el enlace
descriptionOverwrite (opcional): Texto de descripción
tags (opcional): Matriz de etiquetas. Las etiquetas deben coincidir exactamente con los nombres de tus etiquetas en Capacities, de lo contrario se crearán.
mdText (opcional): Texto formateado como markdown que se añadirá a la sección de notas
capacities_save_to_daily_note
Añade contenido markdown a la nota diaria de hoy en un espacio.
spaceId: UUID del espacio de destino
mdText: Contenido markdown a añadir
origin (opcional): Etiqueta de origen para el contenido (solo se admite "commandPalette")
noTimestamp (opcional): Si es true, no se añadirá ninguna marca de tiempo a la nota
Límites de tasa
La API de Capacities tiene los siguientes límites de tasa:
/spaces: 5 solicitudes por 60 segundos/space-info: 5 solicitudes por 60 segundos/search: 120 solicitudes por 60 segundos/save-weblink: 10 solicitudes por 60 segundos/save-to-daily-note: 5 solicitudes por 60 segundos
Ejemplos de prompts
Aquí tienes algunos ejemplos de prompts que puedes usar con Claude cuando este servidor MCP esté configurado:
Empezando
"Show me all my Capacities spaces"
"What spaces do I have in Capacities?"Explorando tu base de conocimientos
"Get detailed information about my main workspace in Capacities"
"What structures and collections are in my [space name] space?"Buscando contenido
"Search for 'project management' across all my Capacities spaces"
"Find all notes mentioning 'machine learning' in my research space"
"Search for 'meeting notes' but only check titles, not full content"Leyendo contenido
"Read the content of object [object-id] from my research space"
"Get the full note content for [title] in my workspace"Guardando información
"Save this article to my research space: https://example.com/article"
"Bookmark this GitHub repo in my coding space with tags 'javascript' and 'tools'"
"Save this link with a custom title and description to my resources space"Notas diarias
"Add a summary of today's key insights to my daily note"
"Save these meeting notes to today's daily note in my work space"
"Add this quote to my daily note: [your quote here]"Uso avanzado
"Search for 'productivity' in my work and personal spaces, but filter to only show task-related structures"
"Save this research paper to my academic space and add it to today's daily note as well"
"Find all my notes about 'AI tools' and then save the best ones as bookmarks"Créditos
Licencia
MIT - consulta el archivo LICENSE para más detalles.
Available Tools
5 toolscapacities_get_space_infoARead-only
Get detailed information about a specific Capacities space including structures and collections
| Name | Required | Description | Default |
|---|---|---|---|
| spaceId | Yes | The UUID of the space to get information for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation that may return varying data. The description adds value by specifying what information is included ('structures and collections'), which provides useful context beyond the annotations. However, it doesn't mention rate limits, authentication needs, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes relevant scope details ('including structures and collections'). There's no wasted language, and every element serves to clarify the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and good annotations, the description is reasonably complete. It specifies what information is returned, which compensates for the lack of an output schema. However, it could be more complete by mentioning the response format or any limitations, though annotations cover the safety profile adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'spaceId' fully documented as 'The UUID of the space to get information for'. The description doesn't add any additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating with extra details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('a specific Capacities space'), including scope ('including structures and collections'). It distinguishes from 'capacities_list_spaces' by focusing on a single space rather than listing multiple spaces, but doesn't explicitly differentiate from other siblings like 'capacities_search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'a specific Capacities space' and the required spaceId parameter, suggesting this tool is for retrieving details about a known space. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'capacities_search' or mention any prerequisites beyond having a space ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capacities_list_spacesBRead-only
Get a list of all personal spaces in Capacities
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation that may return incomplete data. The description adds minimal behavioral context beyond this—it specifies 'all personal spaces' but doesn't mention pagination, rate limits, or what 'personal spaces' entails. With annotations covering safety, a 3 is appropriate as the description adds some value but not rich behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, read-only operation), the description is adequate but has gaps. Annotations cover safety, but there's no output schema, so the description doesn't explain return values (e.g., format of the list). For a list operation, more context on output structure would be helpful, but the description meets minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description correctly doesn't mention any parameters, which is appropriate. Baseline for 0 parameters is 4, as no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a list') and resource ('all personal spaces in Capacities'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'capacities_get_space_info' (which presumably gets details for a specific space), but the scope is clear. The description avoids tautology by not just repeating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling tools like 'capacities_search' (which might search within spaces) or 'capacities_get_space_info' (which gets details for a specific space), nor does it specify any prerequisites or contexts for use. The agent must infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capacities_save_to_daily_noteB
Add markdown text to today's daily note in a Capacities space
| Name | Required | Description | Default |
|---|---|---|---|
| mdText | Yes | The markdown text to add to today's daily note | |
| noTimestamp | No | If true, no time stamp will be added to the note | |
| origin | No | Optional origin label for the content (only 'commandPalette' is supported) | |
| spaceId | Yes | The UUID of the space to save to the daily note |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (implying a write operation) and openWorldHint=true (suggesting flexible use), which the description aligns with by describing an 'Add' action. However, it doesn't add significant behavioral context beyond annotations, such as whether the text is appended or overwritten, or any rate limits or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource without unnecessary details. It's appropriately sized for the tool's complexity, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral nuances, or output expectations, leaving gaps that could hinder an AI agent's effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents all parameters, including mdText, noTimestamp, origin, and spaceId. The description mentions 'markdown text' and 'today's daily note', which loosely maps to mdText and implies a date context, but adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add markdown text') and target resource ('today's daily note in a Capacities space'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like capacities_save_weblink, which might also involve saving content but to different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as capacities_save_weblink for saving links or capacities_search for finding notes. It lacks context on prerequisites (e.g., needing a valid spaceId) or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capacities_save_weblinkA
Save a web link to a Capacities space with optional title and tags
| Name | Required | Description | Default |
|---|---|---|---|
| descriptionOverwrite | No | Optional description for the weblink | |
| mdText | No | Text formatted as markdown that will be added to the notes section | |
| spaceId | Yes | The UUID of the space to save the weblink to | |
| tags | No | Optional Tags to add to the weblink. Tags need to exactly match your tag names in Capacities, otherwise they will be created. | |
| titleOverwrite | No | Optional custom title for the weblink | |
| url | Yes | The URL to save |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation) and openWorldHint=true (supports flexible inputs), which the description aligns with by describing a save operation. It adds context about tag creation if names don't match, but doesn't disclose other behavioral traits like error handling, rate limits, or authentication needs beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and lists optional features. Every word contributes to understanding without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and rich annotations, the description adequately covers the basic operation but lacks details on return values, error conditions, or integration with sibling tools. It's minimally viable given the context but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description mentions optional title and tags, which map to titleOverwrite and tags parameters, but adds no additional meaning beyond what the schema already provides (e.g., no usage examples or edge cases).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save a web link') and target resource ('to a Capacities space'), specifying optional features (title and tags). It distinguishes from siblings like capacities_get_space_info (read-only info) and capacities_save_to_daily_note (different target), but doesn't explicitly differentiate from capacities_search (search vs. save).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for saving web links with metadata to a space, but provides no explicit guidance on when to use this tool versus alternatives like capacities_save_to_daily_note (for daily notes) or capacities_search (for finding content). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capacities_searchARead-only
Search for content across Capacities spaces with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| filterStructureIds | No | Optional array of structure IDs to filter results | |
| mode | No | Search mode: fullText or title only | title |
| searchTerm | Yes | The search term to look for | |
| spaceIds | Yes | Array of space UUIDs to search in |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, exploratory operation. The description adds minimal behavioral context beyond this, such as mentioning 'optional filtering' but not detailing result formats, pagination, or error handling. It doesn't contradict annotations, so it earns a baseline score for adding some value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Search for content') and includes key details ('across Capacities spaces with optional filtering'). There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema) and rich annotations, the description is adequate but lacks details on output format or error scenarios. It covers the basic purpose but doesn't fully compensate for the absence of an output schema, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description mentions 'optional filtering' but doesn't add specific meaning beyond what the schema provides, such as explaining how filtering interacts with search modes. This aligns with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('content across Capacities spaces'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'capacities_list_spaces' or 'capacities_save_to_daily_note', which reduces it from 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'optional filtering' but doesn't specify when to use this tool versus alternatives like 'capacities_list_spaces' for listing spaces or 'capacities_save_to_daily_note' for saving content. It provides some context but lacks explicit guidance on exclusions or comparisons.
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.
5 tool updates
v1.0.0- First observed
capacities_get_space_info - First observed
capacities_list_spaces - First observed
capacities_save_to_daily_note - First observed
capacities_save_weblink - First observed
capacities_search
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: get_space_info retrieves metadata about a specific space, list_spaces enumerates all spaces, save_to_daily_note adds content to a daily note, save_weblink stores web links, and search performs content searches. There is no overlap or ambiguity in their functions, making it easy for an agent to select the right tool.
All tool names follow a consistent 'capacities_verb_noun' pattern, using snake_case throughout. This predictability aids in understanding and usage, with no deviations in naming conventions across the set.
With 5 tools, the server is well-scoped for its purpose of interacting with Capacities spaces. Each tool serves a specific and necessary function, such as listing spaces, retrieving info, saving content, and searching, without being overly sparse or bloated.
The tool set covers key operations for managing Capacities spaces, including listing, retrieving info, saving notes and links, and searching. A minor gap exists in lacking update or delete operations for saved content, but agents can work around this for most workflows.
Maintenance
Related MCP Connectors
Connect an AI assistant to a Capacities space (objects, daily notes, search).
- platform7nOAuthtech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Create projects, nodes, and tasks in UluP Spaces by conversation with Claude.
- TaprootOAuthcom.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables querying and retrieving content from Confluence through CQL searches and page content fetching, allowing Claude to seamlessly access information stored in Confluence workspaces.314MIT
- AlicenseAqualityDmaintenanceEnables natural language management of ClickUp workspaces, including task CRUD operations, task listing, and user profile retrieval via Claude Desktop.61MIT
- AlicenseAqualityDmaintenanceEnables Claude Code and other MCP clients to manage bookmarks, collections, and tags in Raindrop.io accounts via natural language.152MIT
- AlicenseNot gradedqualityDmaintenanceEnables Claude and Claude Code to interact with Atlassian Cloud (Confluence and Jira) through natural language, supporting full CRUD operations, search, comments, and attachments.MIT