Skip to main content
Glama
Im-Hal-9K

Capacities-MCP-Plus

by Im-Hal-9K
OverviewSchemaRelated ServersScoreDiscussions
JavaScript

Capacities MCP Plus

An enhanced MCP (Model Context Protocol) server for Capacities, providing seamless integration with your knowledge management system.

Note: This is a fork of jemgold/capacities-mcp with additional features and fixes.

What's Different from the Original

Feature

Original

Plus

Read Object Content

Not available

Retrieve full note content by object ID

fastmcp Version

1.27.3

3.25.4 (fixes MCP SDK compatibility)

Windows Support

May have issues

Tested with cmd wrapper

npm Package

capacities-mcp

capacities-mcp-plus

New Tool: capacities_read_object_content

Retrieve the full content of any Capacities object by its ID:

  • Tries undocumented API endpoints first for direct retrieval

  • Falls back to search API aggregation when direct access unavailable

  • Provides title parameter to improve search accuracy

Related MCP server: NOUZ MCP Server

Features

This MCP server provides access to all current Capacities API endpoints:

  • List Spaces - Get all your personal spaces

  • Space Information - Retrieve detailed space structures and collections

  • Search Content - Search across spaces with advanced filtering

  • Read Object Content - Retrieve full note content by object ID

  • Save Weblinks - Save URLs to your spaces with metadata

  • Daily Notes - Add content to your daily notes

Installation

For Claude Desktop (macOS)

Add to your Claude Desktop configuration (~/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"
      }
    }
  }
}

For Claude Desktop (Windows)

Windows requires a cmd wrapper. Add to %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"
      }
    }
  }
}

Get your Capacities API key from your Capacities account settings.

That's it! The server will be automatically downloaded and run when Claude Desktop starts.

Development

Local Setup

For local development, you'll need to clone and build the project:

  1. Clone this repository:

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

  1. Install dependencies:

npm install
# or
bun install

  1. Copy the example environment file:

cp .env.example .env

  1. Add your Capacities API key to .env:

CAPACITIES_API_KEY=your_api_key_here

  1. Build the server:

npm run build

Running the Server

Start the development server with interactive mode:

bun run dev

For production use:

npm run start

To inspect the server tools and schema:

bun run inspect

Testing

Run the test suite:

bun run test

Code Quality

Check linting and types:

bun run lint

Format code:

bun run format

API Reference

Get your Capacities API key from your Capacities account settings.

For detailed API documentation, see:

Available Tools

capacities_list_spaces

Get a list of all your personal spaces.

capacities_get_space_info

Get detailed information about a specific space, including structures and collections.

  • spaceId: UUID of the space

capacities_search

Search for content across your spaces with optional filtering.

  • searchTerm: Text to search for

  • spaceIds: Array of space UUIDs to search in

  • mode (optional): "fullText" or "title" search mode

  • filterStructureIds (optional): Filter by specific structure types

capacities_read_object_content

Retrieve the full content of a Capacities object by its ID.

  • objectId: UUID of the object to retrieve (can be obtained from 'Copy object reference' in Capacities)

  • spaceId: UUID of the space containing the object

  • title (optional): The title or partial title of the object - strongly recommended to improve search results

  • How it works:

    1. First attempts to use undocumented GET endpoints for direct object retrieval

    2. Falls back to search API, aggregating content from highlights and snippets

    3. Filters search results by object ID to find exact match

  • Note: When using search fallback, content may be incomplete as it's assembled from search snippets. Providing the title parameter significantly improves results.

capacities_save_weblink

Save a web link to a space with optional metadata.

  • spaceId: UUID of the target space

  • url: The URL to save

  • titleOverwrite (optional): Custom title for the link

  • descriptionOverwrite (optional): Description text

  • tags (optional): Array of tags. Tags need to exactly match your tag names in Capacities, otherwise they will be created.

  • mdText (optional): Text formatted as markdown that will be added to the notes section

capacities_save_to_daily_note

Add markdown content to today's daily note in a space.

  • spaceId: UUID of the target space

  • mdText: Markdown content to add

  • origin (optional): Origin label for the content (only "commandPalette" is supported)

  • noTimestamp (optional): If true, no timestamp will be added to the note

Rate Limits

The Capacities API has the following rate limits:

  • /spaces: 5 requests per 60 seconds

  • /space-info: 5 requests per 60 seconds

  • /search: 120 requests per 60 seconds

  • /save-weblink: 10 requests per 60 seconds

  • /save-to-daily-note: 5 requests per 60 seconds

Example Prompts

Here are some example prompts you can use with Claude when this MCP server is configured:

Getting Started

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

Exploring Your Knowledge Base

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

Searching Content

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

Reading Content

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

Saving Information

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

Daily Notes

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

Advanced Usage

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

Credits

License

MIT - see LICENSE file for details.

Available Tools

6 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

A4/5.0
Behavior4/5

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

Annotations provide readOnlyHint=true and openWorldHint=true, indicating it's a safe read operation that may return partial data. The description adds value by specifying the type of information returned ('detailed information... including structures and collections'), which goes beyond annotations. It doesn't contradict annotations, but lacks details on rate limits, auth needs, or error handling.

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, well-structured sentence that efficiently conveys the tool's purpose and scope. It's front-loaded with the main action and resource, with no redundant or unnecessary information, making it easy to parse quickly.

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?

Given the tool's low complexity (1 parameter, no output schema), the description is reasonably complete. It covers what the tool does and what information it returns. However, without an output schema, it could benefit from more detail on the return format (e.g., structure of the response), but the annotations and context mitigate this gap.

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?

The input schema has 100% description coverage, with the spaceId parameter fully documented as a UUID. The description doesn't add any parameter-specific details beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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

Purpose5/5

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

The description clearly states the specific action ('Get detailed information') and resource ('about a specific Capacities space'), including what information is retrieved ('including structures and collections'). It distinguishes from sibling tools like capacities_list_spaces (which lists spaces) and capacities_read_object_content (which reads content of objects).

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 by specifying 'a specific Capacities space', suggesting it's for retrieving details of a known space rather than listing or searching. However, it doesn't explicitly state when to use this tool versus alternatives like capacities_search or capacities_list_spaces, nor does it mention prerequisites or exclusions.

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 declare readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with potentially dynamic data. The description adds minimal behavioral context beyond this, only specifying 'all personal spaces' without detailing format, pagination, or error handling. No contradiction with annotations exists.

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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Get a list'), making it easy to parse 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, read-only operation) and lack of output schema, the description is adequate but minimal. It covers the basic purpose but doesn't provide details on return format, error cases, or usage context, which could help an agent better understand how to integrate 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?

With 0 parameters and 100% schema description coverage, the schema fully documents the input structure (none required). The description adds no parameter-specific information, which is acceptable here as there are no parameters to explain, maintaining clarity without redundancy.

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 ('Get') and resource ('all personal spaces in Capacities'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'capacities_get_space_info' which might retrieve details about a specific space versus listing all spaces.

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' for filtered searches or 'capacities_get_space_info' for detailed information about specific spaces, leaving the agent without context for tool selection.

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

capacities_read_object_contentA
Read-only

Retrieve the full content of a Capacities object by its ID. Optionally provide a title or search term to improve results. This tries undocumented endpoints first, then falls back to search API aggregation.

ParametersJSON Schema
NameRequiredDescriptionDefault
objectIdYesThe UUID of the object to retrieve. You can get this from 'Copy object reference' in Capacities.
spaceIdYesThe UUID of the space containing the object
titleNoOptional: The title or partial title of the object to search for. This improves search results.

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potential for unknown endpoints. The description adds valuable context beyond this: it discloses the fallback behavior to search API aggregation and mentions undocumented endpoints, which helps the agent understand reliability and performance implications. No contradiction with annotations.

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?

The description is front-loaded with the core purpose and includes two additional sentences that add context without unnecessary detail. It's appropriately sized, though the second sentence could be slightly more concise.

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 read operation with annotations covering safety and open-world hints, and no output schema, the description provides adequate context on behavior (fallback mechanism) but lacks details on return values or error handling. It's complete enough for basic use but has gaps in output expectations.

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%, so the schema fully documents all parameters. The description adds minimal semantics by noting that the title parameter 'improves search results,' but this is redundant with the schema's description. Baseline 3 is appropriate as the schema carries the burden.

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 ('Retrieve') and resource ('full content of a Capacities object by its ID'), making the purpose specific. However, it doesn't explicitly distinguish this tool from sibling tools like 'capacities_search', which might also retrieve content, though the focus on a specific object ID provides some implicit differentiation.

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 by mentioning that it 'tries undocumented endpoints first, then falls back to search API aggregation,' which suggests a fallback mechanism but doesn't explicitly state when to use this tool versus alternatives like 'capacities_search'. No clear exclusions or prerequisites are provided.

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
spaceIdYesThe UUID of the space to save to the daily note
mdTextYesThe markdown text to add to today's daily note
originNoOptional origin label for the content (only 'commandPalette' is supported)
noTimestampNoIf true, no time stamp will be added to the note

TDQS

B3.3/5.0
Behavior3/5

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

Annotations provide readOnlyHint=false (indicating mutation) and openWorldHint=true (suggesting flexible use), but the description adds minimal behavioral context. It mentions adding text to a daily note but doesn't disclose whether this appends or overwrites, how content is formatted, or any rate limits. With annotations covering basic safety, the description adds some value but lacks operational 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 directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse 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?

For a mutation tool with 4 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It clarifies the target is a daily note, but lacks details on behavior (e.g., append vs. overwrite), error handling, or integration with sibling tools. The annotations help, but more context would improve completeness.

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%, so all parameters are documented in the schema. The description doesn't add any meaning beyond what the schema provides—it mentions 'markdown text' and 'today's daily note' but these are already covered by mdText and implied by the tool name. Baseline 3 is appropriate as 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?

The description clearly states the action ('Add markdown text') and target resource ('today's daily note in a Capacities space'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like capacities_save_weblink, which would require mentioning this is specifically for daily notes rather than general saving 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?

The description provides no guidance on when to use this tool versus alternatives like capacities_save_weblink or capacities_search. It mentions the target is 'today's daily note' but doesn't explain when daily notes are appropriate versus other content types, nor does it mention prerequisites or constraints beyond what's in the schema.

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. Dates show when Glama detected each change.

  1. 6 tool updates
    • First observedcapacities_get_space_info
    • First observedcapacities_list_spaces
    • First observedcapacities_read_object_content
    • First observedcapacities_save_to_daily_note
    • First observedcapacities_save_weblink
    • First observedcapacities_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have clearly distinct purposes: get_space_info, list_spaces, read_object_content, save_to_daily_note, save_weblink, and search. However, read_object_content and search could potentially overlap in some retrieval scenarios, though their descriptions help differentiate them (one retrieves specific object content, the other searches across spaces).

Naming Consistency5/5

All tools follow a consistent naming pattern: 'capacities_' prefix followed by a descriptive verb_noun combination (e.g., get_space_info, list_spaces, read_object_content). This makes the tool set predictable and easy to understand at a glance.

Tool Count5/5

With 6 tools, this server is well-scoped for its purpose of interacting with Capacities spaces. Each tool serves a distinct function (info retrieval, listing, content reading, saving notes/links, and searching), and none feel redundant or unnecessary for the domain.

Completeness4/5

The tool set covers core operations for the Capacities domain: reading (get_space_info, list_spaces, read_object_content, search) and writing (save_to_daily_note, save_weblink). A minor gap is the lack of update or delete operations for objects, but agents can likely work around this given the focus on retrieval and basic saving.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Im-Hal-9K/capacities-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server