Skip to main content
Glama
fajarmf

slite-mcp

by fajarmf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

⚠️ DEPRECATED — Use the Official Slite MCP Instead

This project is no longer maintained.

Slite now provides an official MCP server with native support for all block types including mermaid diagrams, tables, callouts, and more.

To migrate, update your MCP config:

{
  "mcpServers": {
    "slite-official": {
      "type": "http",
      "url": "https://api.slite.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_SLITE_API_KEY"
      }
    }
  }
}

Key improvements in the official MCP over this repo:

  • ✅ Mermaid/diagram blocks work correctly

  • ✅ Block-level editing via modify-block (no more full-document rewrites)

  • ✅ Callouts, tables, collapsibles, and all native Slite blocks

  • ✅ Maintained by Slite directly

Slite MCP Server (Deprecated)

A Model Context Protocol (MCP) server that integrates with Slite's API to search, retrieve, create, and edit notes.

Features

  • 🔍 Search Notes: Search through your Slite workspace

  • 📄 Get Note Content: Retrieve specific notes by ID in markdown or HTML format

  • 🌳 Browse Hierarchy: Get child notes of any parent note

  • 🤖 Ask Questions: Natural language question answering across your workspace

  • ✏️ Edit Notes: Search-and-replace editing with validation and dry-run support

  • 📝 Create Notes: Create new notes with markdown content

  • 🔄 Update Notes: Full content replacement for major rewrites

Related MCP server: joplin-mcp

Installation

# Clone the repository
git clone https://github.com/fajarmf/slite-mcp.git
cd slite-mcp

# Install dependencies
npm install

# Build the project
npm run build

Configuration

Getting your Slite API Key

  1. Log in to your Slite workspace

  2. Go to Settings → API

  3. Generate a new API key

Setting up the MCP Server

Add the server to your MCP configuration file (~/.mcp.json):

{
  "mcpServers": {
    "slite": {
      "command": "node",
      "args": ["/path/to/slite-mcp/build/index.js"],
      "env": {
        "SLITE_API_KEY": "your-api-key-here"
      }
    }
  }
}

Usage

Once configured, the following tools are available:

slite_search

Search for notes in your Slite workspace.

Parameters:

  • query (required): Search query string

  • hitsPerPage (optional): Results per page (default: 10)

Example:

{
  "tool": "slite_search",
  "arguments": {
    "query": "project documentation",
    "hitsPerPage": 5
  }
}

slite_get_note

Retrieve a specific note by its ID.

Parameters:

  • noteId (required): The ID of the note to retrieve

  • format (optional): Format to return - "md" or "html" (default: "md")

Example:

{
  "tool": "slite_get_note",
  "arguments": {
    "noteId": "BoptqNi4pm0lcV",
    "format": "md"
  }
}

slite_get_note_children

Get all child notes of a parent note.

Parameters:

  • noteId (required): The ID of the parent note

  • cursor (optional): Pagination cursor for next page

Example:

{
  "tool": "slite_get_note_children",
  "arguments": {
    "noteId": "5i6k33yrVu7eMy"
  }
}

slite_ask

Ask natural language questions and get AI-powered answers from your Slite workspace.

Parameters:

  • question (required): The question to ask

  • parentNoteId (optional): Limit search to notes under this parent

Example:

{
  "tool": "slite_ask",
  "arguments": {
    "question": "What is our deployment process?"
  }
}

slite_create_note

Create a new note in your Slite workspace.

Parameters:

  • title (required): Note title

  • markdown (optional): Note content in markdown format

  • parentNoteId (optional): Parent note ID (creates in personal channel if not specified)

Example:

{
  "tool": "slite_create_note",
  "arguments": {
    "title": "Meeting Notes",
    "markdown": "# Meeting Notes\n\n- Discussed project timeline\n- Assigned tasks",
    "parentNoteId": "5i6k33yrVu7eMy"
  }
}

slite_edit_note

Edit a note using search-and-replace. Preferred for targeted edits - faster and safer than full rewrite.

Parameters:

  • noteId (required): The ID of the note to edit

  • edits (required): Array of search-and-replace operations

    • oldText: Exact text to find (must be unique in document)

    • newText: Text to replace it with

  • dryRun (optional): If true, validate edits without applying them

Example:

{
  "tool": "slite_edit_note",
  "arguments": {
    "noteId": "BoptqNi4pm0lcV",
    "edits": [
      { "oldText": "Draft", "newText": "Final" },
      { "oldText": "TODO: add details", "newText": "Implementation complete" }
    ],
    "dryRun": false
  }
}

slite_update_note

Replace entire note content. Use slite_edit_note for small changes.

Parameters:

  • noteId (required): The ID of the note to update

  • markdown (required): New markdown content (replaces entire note)

  • title (optional): New title (keeps existing if not provided)

Example:

{
  "tool": "slite_update_note",
  "arguments": {
    "noteId": "BoptqNi4pm0lcV",
    "markdown": "# New Content\n\nThis replaces everything.",
    "title": "Updated Title"
  }
}

Testing

Quick Start

# Copy environment config and add your API key
cp .env.example .env
# Edit .env with your SLITE_API_KEY

# Setup test data (creates test documents in Slite)
npm run test:setup

# Run all tests
npm test

Test Setup

The test:setup command creates test documents in your Slite workspace:

  • A parent note with 55 child notes (for cursor pagination testing)

  • A "Test Data for MCP Server" child with searchable keywords

The script is idempotent - it won't create duplicates if test data already exists.

# Setup with a new parent note
npm run test:setup

# Or use an existing note as parent
npm run test:setup -- --parent=<note-id>

# Force recreation even if data exists
npm run test:setup -- --force

Test Suite

The test suite includes:

  • API Tests: Search, get note, get children, ask endpoint

  • Error Handling: Invalid IDs, unauthorized access

  • Pagination: hitsPerPage for search, cursor for children (requires 55+ children)

  • Content Formats: Markdown and HTML output

  • MCP Server Integration: All tools via stdio transport

  • Write Operations: Create, edit, update - with content verification after each operation

Development

Project Structure

slite-mcp/
├── src/
│   └── index.ts           # Main MCP server (7 tools: 4 read, 3 write)
├── build/                 # Compiled JavaScript files
├── tests/
│   ├── index.test.js      # Consolidated test suite
│   └── setup-test-data.js # Idempotent test data setup
├── examples/              # Example configurations
├── package.json
├── tsconfig.json
└── README.md

Building

npm run build

Requirements

  • Node.js 16+

  • TypeScript 5.0+

  • A valid Slite API key

API Response Formats

The Slite API returns data in specific formats:

Search Results

  • Results are in the hits array

  • Each hit contains: id, title, highlight, updatedAt, type, parentNotes

Note Content

  • Full markdown or HTML content

  • Includes metadata: id, title, url, updatedAt, parentNoteId

Child Notes

  • Results in the notes array

  • Pagination info: total, hasNextPage, nextCursor

Troubleshooting

Authentication Failed

  • Verify your API key is correct

  • Check if the key has the necessary permissions

No Results Found

  • Try different search terms

  • Ensure the notes exist in your workspace

  • Check if you have access to the notes

API Changes

If you encounter errors, the Slite API might have changed. Check:

  • Response format in the test scripts

  • Endpoint URLs

  • Required parameters

Contributing

Contributions are welcome! Please:

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

License

MIT License - see LICENSE file for details

Support

For issues or questions:

  • Create an issue on GitHub

  • Check Slite's API documentation

  • Review the test scripts for examples

Available Tools

7 tools
slite_askA

Ask a question to your Slite notes in natural language. Returns an AI-generated answer with sources.

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYesThe question to ask Slite
parentNoteIdNoOptional filter to only search within notes under this parent note ID

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the tool returns an AI-generated answer with sources, implying a read-only, non-destructive operation. However, it does not detail response structure, error conditions, rate limits, or authentication requirements. The description is minimally adequate but lacks depth.

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 consists of two concise sentences. The first sentence defines the action and input, the second defines the output. No unnecessary words, front-loaded with key information.

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 simplicity (2 parameters, no output schema), the description covers the main functionality. It could be improved by specifying the format of the answer or sources, but it's largely sufficient for an agent to understand what the tool does and what to expect.

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 coverage is 100%, with clear descriptions for both parameters. The tool description adds 'in natural language' for the question parameter, which slightly enhances meaning but is not essential. The parentNoteId parameter description in the schema is already explanatory. The description adds marginal value beyond the schema.

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 tool's purpose: 'Ask a question to your Slite notes in natural language' with output 'Returns an AI-generated answer with sources.' It distinguishes itself from sibling tools like slite_search (likely returns matching notes) and slite_get_note (retrieves a specific note).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (getting AI answers from notes). While it doesn't explicitly state when not to use it or mention alternatives, the sibling tool list implies alternatives for different use cases (e.g., slite_search for literal searches). The description is sufficient for an agent to decide.

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

slite_create_noteB

Create a new note in Slite

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesNote title
markdownNoNote content in markdown format
parentNoteIdNoParent note ID (optional - creates in personal channel if not specified)

TDQS

B3.3/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 disclosure but only states 'Create a new note'. It does not mention authentication requirements, rate limits, what happens if a note already exists, or any side effects. This is insufficient 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that is front-loaded with the core purpose. It contains no unnecessary words, though a bit more context could improve usefulness without sacrificing conciseness.

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 tool creates a note with three parameters and no output schema, the description should explain return behavior (e.g., created note ID), error conditions, or success criteria. It fails to provide these details, leaving the agent without enough context to fully understand the tool's behavior.

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 describes all three parameters (title, markdown, parentNoteId) with clear descriptions. The description adds no additional meaning beyond the schema, but since coverage is 100%, the baseline score of 3 is appropriate.

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 explicitly states the verb 'Create' and the resource 'a new note in Slite'. This clearly distinguishes it from sibling tools like slite_edit_note and slite_update_note, which modify existing notes.

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 use for creating a new note, but provides no guidance on when to use this tool versus alternatives like slite_update_note for modifications or slite_search for retrieval. 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.

slite_edit_noteA

Edit a Slite note using search-and-replace. Preferred for targeted edits - faster and safer than full rewrite. Each edit's oldText must be unique in the document.

ParametersJSON Schema
NameRequiredDescriptionDefault
noteIdYesThe ID of the note to edit
editsYesList of search-and-replace operations applied sequentially
dryRunNoIf true, validate edits without applying them

TDQS

A4.2/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. Discloses search-and-replace mechanism and uniqueness constraint. Does not detail error handling, idempotency, or return format, but adequate 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?

Three concise sentences, front-loaded with purpose, followed by usage guidance and constraint. No redundant information.

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 no output schema and no annotations, description covers purpose, preference, and key constraint. Missing potential details like return value or side effects, but sufficient for a simple edit tool.

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?

Schema coverage is 100% and descriptions are clear. Description adds 'applied sequentially' for edits and reinforces uniqueness for oldText, providing extra context beyond schema.

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?

Description clearly states 'Edit a Slite note using search-and-replace' and distinguishes from siblings by noting it's 'Preferred for targeted edits - faster and safer than full rewrite.' This sets it apart from slite_update_note.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on when to use (targeted edits) and a constraint (oldText must be unique). Does not explicitly list alternatives or when not to use, but the context is clear.

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

slite_get_noteB

Get a specific note by ID

ParametersJSON Schema
NameRequiredDescriptionDefault
noteIdYesThe ID of the note to retrieve
formatNoFormat to return (markdown or html)md

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are given, so the description carries full burden. It only says 'Get' without disclosing error behavior (e.g., what happens if noteId is invalid or not found), response format, or any side effects. More detail is needed for a safe read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence, 6 words), but lacks necessary details. It could be slightly longer to cover usage hints without being verbose.

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 that there is no output schema and no annotations, the description should provide more context about returns, errors, and usage. It barely covers the basic purpose, leaving the agent with many unknowns.

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 baseline is 3. The description adds no extra meaning beyond what the schema already provides (e.g., noteId is an ID, format has enum).

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 verb (Get) and resource (a specific note by ID), distinguishing it from siblings like slite_create_note or slite_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?

No explicit when-to-use or alternatives are provided; usage is implied from the tool name and purpose. Could mention that for retrieving a note by ID, this is the tool, but no guidance on when not to use it (e.g., when you need to search).

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

slite_get_note_childrenB

Get child notes of a parent note

ParametersJSON Schema
NameRequiredDescriptionDefault
noteIdYesThe ID of the parent note
cursorNoCursor for pagination (from previous response)

TDQS

B3/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 the full burden. It does not disclose pagination behavior (despite the cursor parameter), authentication needs, rate limits, or any side effects. The minimal description leaves the agent uninformed about important behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence, which is concise. However, it is too minimal and does not provide enough context or structure to be maximally useful. It sacrifices completeness for brevity.

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?

Without an output schema or annotations, the description is insufficiently complete. It does not explain what the response contains (e.g., list of note IDs or full notes), pagination details, or any error conditions. For a tool with no output schema, the description should elaborate on return values.

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%; both parameters have clear descriptions in the schema. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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 action and resource: 'Get child notes of a parent note'. It distinguishes from siblings like slite_get_note (which gets a single note) and slite_search (which searches across notes). The verb 'Get' and resource 'child notes' are specific.

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?

No guidance is provided on when to use this tool versus alternatives. For example, it does not explain when to use this over slite_get_note or slite_search. No explicit when-to-use or when-not-to-use information.

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

slite_update_noteA

Replace entire note content. Use slite_edit_note for small changes. WARNING: This overwrites everything.

ParametersJSON Schema
NameRequiredDescriptionDefault
noteIdYesThe ID of the note to update
titleNoNew title (optional - keeps existing if not provided)
markdownYesNew markdown content (replaces entire note)

TDQS

A4.5/5.0
Behavior4/5

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

No annotations exist, so description bears full burden. It warns that overwriting is irreversible (implicitly). Could specify that note ID must exist or return format, but the warning is adequate 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?

Two concise sentences with no wasted words. The warning is front-loaded, and the sibling alternative is immediately given.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-parameter tool with no output schema, the description, combined with full schema coverage, provides everything needed to use the tool correctly and avoid pitfalls.

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 covers all three parameters (100% coverage). Description reinforces that 'markdown' replaces entire content and 'title' is optional, but adds no new semantic detail beyond the schema.

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?

Description clearly states the tool replaces entire note content, using a specific verb and resource. It distinguishes itself from sibling 'slite_edit_note' by contrasting small vs. full replacement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to use 'slite_edit_note' for small changes, providing a clear alternative. The warning about overwriting everything sets strong usage boundaries.

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. 7 tool updatesv1.0.0
    • First observedslite_ask
    • First observedslite_create_note
    • First observedslite_edit_note
    • First observedslite_get_note
    • First observedslite_get_note_children
    • First observedslite_search
    • First observedslite_update_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

A3.5/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: ask is for Q&A, create/edit/get/search/get_children/update each target different aspects of note management. Even edit_note and update_note are differentiated by targeted vs. full replacement.

Naming Consistency4/5

All tools use the slite_ prefix with snake_case, mostly following a verb_noun pattern (e.g., slite_create_note). Minor inconsistency: slite_ask and slite_search lack a noun in their names, but the pattern is still predictable.

Tool Count5/5

With 7 tools, the server is well-scoped for a note-taking service. Each tool serves a core function without superfluous duplicates, and the count feels appropriate for the domain.

Completeness2/5

The tool set covers create, read, and update operations, but notably lacks a delete note tool. Additionally, there is no explicit list-all-notes tool (only search), which may force agents to use workarounds. These gaps are significant for a CRUD-like service.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • Joplin MCP Server

    jakubfrieb
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI assistants to interact with Joplin notes and notebooks, including searching, reading, and listing notebooks through natural language commands via the MCP protocol.
    179 npm
    48
    MIT

  • joplin-mcp

    songtianlun
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables interaction with Joplin notes through MCP, allowing searching, creating, updating, and deleting notes via the Joplin Web Clipper API.
    5 npm
    MIT

  • mcp-knowledge-base

    gaurav-oberoi
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables access to a notes knowledge base via MCP, providing tools for keyword search, note creation, and retrieval, along with browseable note resources.
    7 npm
    MIT

  • mcp-silverbullet

    jgurhem
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP clients to read and search pages in a remote SilverBullet space and create or append to notes under a configurable prefix via SilverBullet's HTTP API.
    Apache 2.0