Which integrations are available for this server?

The server depends on packages hosted on JSR registry (@cosense/std and @cosense/types) and requires configuration to access these dependencies. Provides tools to interact with Cosense pages, which are part of the Scrapbox ecosystem. Features include retrieving pages, listing available pages, searching pages, and inserting text into pages.

How do I use cosense-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cosense-mcp-server search for pages about API documentation" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

cosense-mcp-server

by yosider

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Cosense MCP Server

A MCP server for Cosense.

Tools

The following tools are available for interacting with Cosense pages:

get_page: Retrieves a page with the specified title
list_pages: Lists available pages in the resources
search_pages: Searches for pages containing the specified query string
insert_lines: Inserts text after a specified line in a page

Related MCP server: MCP Tool

Installation

Prerequisites

Set the following environment variables:

COSENSE_PROJECT_NAME — your Cosense project name.
COSENSE_SID — session cookie used for authentication. Required for writing pages and reading private pages. Treat this like a secret. See https://scrapbox.io/scrapboxlab/connect.sid for more details.

For VS Code Users

Use one of these one-click installation buttons:

Install with pnpm in VS Code Install with pnpm in VS Code Insiders

Install with yarn in VS Code Install with yarn in VS Code Insiders

Note: After clicking the button, replace your_project_name and your_sid with your actual values in the configuration. For manual setup, you can also edit .vscode/mcp.json directly.

For Claude Desktop Users

Add one of the following configurations to your claude_desktop_config.json:

Using pnpm

{
  "mcpServers": {
    "cosense-mcp-server": {
      "command": "pnpm",
      "args": ["-s", "dlx", "@yosider/cosense-mcp-server"],
      "env": {
        "COSENSE_PROJECT_NAME": "your_project_name",
        "COSENSE_SID": "your_sid"
      }
    }
  }
}

Using yarn

{
  "mcpServers": {
    "cosense-mcp-server": {
      "command": "yarn",
      "args": ["dlx", "-q", "@yosider/cosense-mcp-server"],
      "env": {
        "COSENSE_PROJECT_NAME": "your_project_name",
        "COSENSE_SID": "your_sid"
      }
    }
  }
}

Using npx

This package depends on JSR-hosted packages. npx requires adding the JSR registry to ~/.npmrc first.

Step 1: Add JSR registry to ~/.npmrc

Linux/macOS:

echo "@jsr:registry=https://npm.jsr.io" >> ~/.npmrc

Windows (PowerShell):

echo "@jsr:registry=https://npm.jsr.io" >> $env:USERPROFILE\\.npmrc

Step 2: Add configuration

{
  "mcpServers": {
    "cosense-mcp-server": {
      "command": "npx",
      "args": ["-y", "@yosider/cosense-mcp-server"],
      "env": {
        "COSENSE_PROJECT_NAME": "your_project_name",
        "COSENSE_SID": "your_sid"
      }
    }
  }
}

Development

Running from Source

If you prefer to run the server from a local copy of this repository, build it first:

git clone https://github.com/yosider/cosense-mcp-server.git
cd cosense-mcp-server
pnpm install
pnpm run build

Then configure your MCP client to use the local build:

{
  "mcpServers": {
    "cosense-mcp-server": {
      "command": "node",
      "args": ["/path/to/cosense-mcp-server/build/index.js"],
      "env": {
        "COSENSE_PROJECT_NAME": "your_project_name",
        "COSENSE_SID": "your_sid"
      }
    }
  }
}

Debugging

Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector, which is available as a package script:

pnpm run inspect

The Inspector will provide a URL to access debugging tools in your browser.

Acknowledgments

This project is forked from funwarioisii/cosense-mcp-server.

Available Tools

4 tools

get_pageB

Get a page with the specified title from the Cosense project.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title of the page

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, error handling for missing pages, or side effects. The term 'get' implies reading, but this is not explicitly stated.

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, concise sentence that directly states the tool's purpose without any unnecessary words. It is well-structured and efficient.

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 simple get operation with one parameter, the description is minimally adequate. However, it omits details about the return value and error conditions, which would be helpful since no output schema is provided.

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 already has 100% coverage with a description for the 'title' parameter. The description does not add additional meaning beyond what the schema provides, so it meets the baseline for schema coverage.

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 'Get a page with the specified title from the Cosense project,' using a specific verb and resource. It distinguishes itself from siblings like list_pages (listing) and search_pages (searching) by focusing on retrieval by title.

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 over siblings or when not to use it. The description merely defines the action without contextual usage instructions.

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

insert_linesA

Insert lines after the specified target line in a Cosense page. If the target line is not found, append to the end of the page.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Title of the page to modify
`targetLineText`	Yes	Text of the line after which to insert new content. If not found, content will be appended to the end.
`text`	Yes	Text to insert. If you want to insert multiple lines, use \n for line breaks.

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, but the description discloses the main action and the fallback behavior when target is not found. It does not mention potential side effects, error handling (e.g., page not found), or behavior with multiple matching target lines, but overall behavior is clear.

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 two sentences long, front-loaded with the main action, and contains no fluff. Every sentence adds essential 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?

For a simple insertion tool with three parameters, the description adequately covers the key behaviors (insert after target line, fallback append). It lacks mention of error cases (e.g., page not existing) or duplicate target lines, but these are not critical for basic understanding.

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 input schema provides 100% coverage for parameter descriptions. The tool description adds value by clarifying the fallback behavior of 'targetLineText' (append if not found), which is not in the schema. This enhances meaning beyond the schema alone.

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 uses the specific verb 'insert lines' and specifies the resource 'Cosense page' and location 'after the specified target line'. It clearly distinguishes from siblings (get_page, list_pages, search_pages) which are read-only tools.

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 for inserting lines after a target or appending, but does not explicitly state when to use it vs. alternatives, nor does it provide exclusions or prerequisites.

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

list_pagesC

List Cosense pages in the project.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior1/5

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

Despite having no annotations, the description fails to disclose any behavioral traits such as being read-only, having side effects, or requiring authentication. The agent gets no safety context beyond the verb 'list.'

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, succinct clause with no extraneous words. It is front-loaded and perfectly concise for the tool's simplicity.

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 absence of an output schema and annotations, the description lacks information about return format, whether all pages are listed, or any ordering. This is insufficient for full autonomous use.

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 zero parameters and schema coverage at 100%, the description adds value by specifying the resource ('Cosense pages') and scope ('in the project'), which is not captured by the empty input 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 it lists Cosense pages in a project, using a specific verb and resource. It differentiates from siblings like get_page (single page) and search_pages (filtered). However, it does not specify if it returns all pages or just a subset, lacking slight scope detail.

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 like get_page, insert_lines, or search_pages. The agent must infer context from the name alone.

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

search_pagesB

Search for pages containing the specified query string in the Cosense project.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query string (space separated)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided. The description does not disclose behavioral traits such as read-only nature, case sensitivity, pagination, or result limits. It only restates the function name.

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?

Single sentence with no redundant information. Highly concise and front-loaded with the core purpose.

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?

Adequate for a simple tool with one parameter and no output schema. However, lacks details on return format, result ordering, or behavior for empty/missing queries.

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 one parameter described as 'Search query string (space separated)'. The description does not add meaning beyond the schema, so baseline score of 3 is appropriate.

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 (search) and the resource (pages containing query string) and specifies the context (Cosense project). It distinguishes from siblings like get_page (single page) and list_pages (list all) by using 'Search', but does not explicitly contrast.

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 on when to use this tool versus alternatives (e.g., list_pages or get_page). No mention of when-not-to-use or conditions like partial matching, pagination, or sorting.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a distinct purpose: get_page retrieves a specific page, insert_lines modifies page content, list_pages enumerates pages, and search_pages queries by text. No functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (get_page, insert_lines, list_pages, search_pages), making them predictable and easy to understand.

Tool Count4/5

With 4 tools, the set is concise but covers essential operations for a Cosense server: reading, writing, listing, and searching. It is slightly minimal but appropriate for the domain.

Completeness3/5

The tools cover basic CRUD-like operations (get, insert, list, search) but lack delete or create functionality for pages explicitly. Insert_lines may create content but not a new page. Some gaps exist.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Artificial Wit AI
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113398

Related MCP Servers

Cosense MCP Server
Web Scraping Developer Tools
funwarioisii
F
license
B
quality
D
maintenance
An MCP server that allows Claude to access pages from Cosense projects, supporting both public and private projects with optional SID authentication.
Updated 2 years ago (2024-12-10 06:32 UTC)
2
1
MCP Tool
Developer Tools Autonomous Agents
PiuQiuPiaQia
F
license
D
quality
D
maintenance
A server built on mcp-framework that enables integration with Claude Desktop through the Model Context Protocol.
Updated a year ago (2025-10-15 06:34 UTC)
1
1
cc-tap
Agent Orchestration Developer Tools
es617
A
license
A
quality
D
maintenance
An MCP server that bridges Claude Desktop and Claude Code by letting Desktop read and interact with Claude Code Remote Control sessions, enabling cross-agent coordination.
Updated 5 months ago (2026-04-16 15:52 UTC)
6
3
MIT
Claude Code MCP Server
Code Execution File Systems Command Line
trickv
A
license
Not graded
quality
D
maintenance
An MCP server that allows Claude Desktop to remotely control Claude Code instances for executing commands and managing files.
Updated 10 months ago (2025-10-21 01:40 UTC)
30
GPL 3.0

Appeared in Searches

Assistance with CURSOR Programming

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/yosider/cosense-mcp-server'

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