Skip to main content
Glama
deenesjakoruzh
jem-computer

Capacities MCP Server

by jem-computer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Capacities MCP Plus

Capacities를 위한 향상된 MCP(Model Context Protocol) 서버로, 지식 관리 시스템과의 원활한 통합을 제공합니다.

참고: 이 프로젝트는 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. .env에 Capacities API 키 추가:

CAPACITIES_API_KEY=your_api_key_here

  1. 서버 빌드:

npm run build

서버 실행

대화형 모드로 개발 서버 시작:

bun run dev

프로덕션 환경 사용 시:

npm run start

서버 도구 및 스키마 검사:

bun run inspect

테스트

테스트 스위트 실행:

bun run test

코드 품질

린팅 및 타입 확인:

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 (선택 사항): 노트 섹션에 추가될 마크다운 형식의 텍스트

capacities_save_to_daily_note

스페이스의 오늘 일일 노트에 마크다운 콘텐츠를 추가합니다.

  • spaceId: 대상 스페이스의 UUID

  • mdText: 추가할 마크다운 콘텐츠

  • 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