Skip to main content
Glama
deenesjakoruzh
jem-computer

Capacities MCP Server

by jem-computer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Capacities MCP Plus

一个增强型的 MCP (Model Context Protocol) 服务器，用于 Capacities，提供与您的知识管理系统的无缝集成。

注意： 这是 jemgold/capacities-mcp 的一个分支，包含额外的功能和修复。

与原版的区别

功能

原版

Plus

读取对象内容

不可用

通过对象 ID 检索完整笔记内容

fastmcp 版本

1.27.3

3.25.4 (修复了 MCP SDK 兼容性)

Windows 支持

可能存在问题

已通过 cmd 包装器测试

npm 包

capacities-mcp

capacities-mcp-plus

新工具：capacities_read_object_content

通过 ID 检索任何 Capacities 对象的完整内容：

  • 首先尝试未公开的 API 端点进行直接检索

  • 在无法直接访问时回退到搜索 API 聚合

  • 提供 title 参数以提高搜索准确性

Related MCP server: ClickUp MCP Server

功能

此 MCP 服务器提供对所有当前 Capacities API 端点的访问：

  • 列出空间 - 获取您所有的个人空间

  • 空间信息 - 检索详细的空间结构和集合

  • 搜索内容 - 通过高级过滤在空间中搜索

  • 读取对象内容 - 通过对象 ID 检索完整笔记内容

  • 保存网页链接 - 将 URL 及其元数据保存到您的空间

  • 每日笔记 - 向您的每日笔记添加内容

安装

适用于 Claude Desktop (macOS)

添加到您的 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"
      }
    }
  }
}

适用于 Claude Desktop (Windows)

Windows 需要一个 cmd 包装器。添加到 %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"
      }
    }
  }
}

从您的 Capacities 账户设置 获取您的 Capacities API 密钥。

就是这样！当 Claude Desktop 启动时，服务器将自动下载并运行。

开发

本地设置

对于本地开发，您需要克隆并构建项目：

  1. 克隆此仓库：

git clone https://github.com/Im-Hal-9K/capacities-mcp.git
cd capacities-mcp

  1. 安装依赖：

npm install
# or
bun install

  1. 复制示例环境文件：

cp .env.example .env

  1. 将您的 Capacities API 密钥添加到 .env：

CAPACITIES_API_KEY=your_api_key_here

  1. 构建服务器：

npm run build

运行服务器

以交互模式启动开发服务器：

bun run dev

用于生产环境：

npm run start

检查服务器工具和架构：

bun run inspect

测试

运行测试套件：

bun run test

代码质量

检查 linting 和类型：

bun run lint

格式化代码：

bun run format

API 参考

从您的 Capacities 账户设置 获取您的 Capacities API 密钥。

有关详细的 API 文档，请参阅：

可用工具

capacities_list_spaces

获取您所有个人空间的列表。

capacities_get_space_info

获取有关特定空间的详细信息，包括结构和集合。

  • spaceId: 空间的 UUID

capacities_search

通过可选过滤在您的空间中搜索内容。

  • searchTerm: 要搜索的文本

  • spaceIds: 要搜索的空间 UUID 数组

  • mode (可选): "fullText" 或 "title" 搜索模式

  • filterStructureIds (可选): 按特定结构类型过滤

capacities_read_object_content

通过 ID 检索 Capacities 对象的完整内容。

  • objectId: 要检索的对象的 UUID（可以从 Capacities 中的“复制对象引用”获取）

  • spaceId: 包含该对象的空间的 UUID

  • title (可选): 对象的标题或部分标题 - 强烈建议提供以提高搜索结果

  • 工作原理:

    1. 首先尝试使用未公开的 GET 端点进行直接对象检索

    2. 回退到搜索 API，从高亮和片段中聚合内容

    3. 按对象 ID 过滤搜索结果以找到精确匹配

  • 注意: 使用搜索回退时，内容可能不完整，因为它是从搜索片段中组装的。提供 title 参数可显著改善结果。

capacities_save_weblink

将网页链接保存到空间，并带有可选的元数据。

  • spaceId: 目标空间的 UUID

  • url: 要保存的 URL

  • titleOverwrite (可选): 链接的自定义标题

  • descriptionOverwrite (可选): 描述文本

  • tags (可选): 标签数组。标签必须与您在 Capacities 中的标签名称完全匹配，否则将创建新标签。

  • mdText (可选): 格式化为 markdown 的文本，将添加到笔记部分

capacities_save_to_daily_note

将 markdown 内容添加到空间中今天的每日笔记。

  • spaceId: 目标空间的 UUID

  • mdText: 要添加的 Markdown 内容

  • origin (可选): 内容的来源标签（仅支持 "commandPalette"）

  • noTimestamp (可选): 如果为 true，则不会向笔记添加时间戳

速率限制

Capacities API 具有以下速率限制：

  • /spaces: 每 60 秒 5 次请求

  • /space-info: 每 60 秒 5 次请求

  • /search: 每 60 秒 120 次请求

  • /save-weblink: 每 60 秒 10 次请求

  • /save-to-daily-note: 每 60 秒 5 次请求

示例提示词

以下是配置此 MCP 服务器后，您可以与 Claude 一起使用的一些示例提示词：

入门

"Show me all my Capacities spaces"
"What spaces do I have in Capacities?"

探索您的知识库

"Get detailed information about my main workspace in Capacities"
"What structures and collections are in my [space name] space?"

搜索内容

"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"

阅读内容

"Read the content of object [object-id] from my research space"
"Get the full note content for [title] in my workspace"

保存信息

"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"

每日笔记

"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]"

高级用法

"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"

制作人员

许可证

MIT - 详情请参阅 LICENSE 文件。

Available Tools

5 tools
capacities_get_space_infoA
Read-only

Get detailed information about a specific Capacities space including structures and collections

ParametersJSON Schema
NameRequiredDescriptionDefault
spaceIdYesThe UUID of the space to get information for

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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_spacesB
Read-only

Get a list of all personal spaces in Capacities

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness5/5

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.

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, 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.

Parameters4/5

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.

Purpose4/5

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.

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 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

ParametersJSON Schema
NameRequiredDescriptionDefault
mdTextYesThe markdown text to add to today's daily note
noTimestampNoIf true, no time stamp will be added to the note
originNoOptional origin label for the content (only 'commandPalette' is supported)
spaceIdYesThe UUID of the space to save to the daily note

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

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, 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.

Tool Schema Changelog

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

  1. 5 tool updatesv1.0.0
    • First observedcapacities_get_space_info
    • First observedcapacities_list_spaces
    • First observedcapacities_save_to_daily_note
    • First observedcapacities_save_weblink
    • First observedcapacities_search
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.8/5.0

Scored across 5 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers