How do I use colyseus-docs-mcp?

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., "@colyseus-docs-mcp list all documentation pages" 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.

colyseus-docs-mcp

by VGFP

Overview Schema Related Servers Score Discussions

JavaScript

Local

colyseus-docs-mcp

An MCP (Model Context Protocol) server that exposes the Colyseus multiplayer-framework documentation to AI agents such as opencode, Claude Code, Cursor, etc.

Published as an npm package. With this server wired up, an agent you're chatting with can:

enumerate every documentation page (list_docs)
read any page rendered as clean Markdown (read_doc)
run a relevance-ranked full-text search (search_docs)
subscribe to per-page resources (colyseus://docs/{slug})

The MDX scaffolding (frontmatter, imports, <Tabs>, <Callout>, icon components, JSX comments, ...) is stripped ahead of time so the agent only ever sees prose + working code blocks.

Status

Loads 114 doc pages from the bundled docs/ snapshot.
Speaks MCP over stdio (the standard local-server transport).
Provides 3 tools, 1 resource template, and 1 ready-made prompt.
Zero runtime deps beyond @modelcontextprotocol/sdk and zod.
Lint + smoke-tested end-to-end.

Related MCP server: Godot Docs MCP

Install

# Run once (downloads & caches the package)
npx -y colyseus-docs-mcp

# Or install globally
npm install -g colyseus-docs-mcp
colyseus-docs-mcp

The server speaks JSON-RPC over stdio, so running the binary directly just waits for MCP messages on stdin - point an MCP client at it (see below) rather than running it by hand.

From source

git clone https://github.com/VGFP/colyseus-docs-mcp.git
cd colyseus-docs-mcp
npm install
npm run build
node dist/index.js      # speaks JSON-RPC over stdio

You can sanity-check the server without an MCP-aware client:

npm run smoke       # node scripts/smoke-test.mjs - exercises every tool/resource
npm run lint        # node scripts/lint-preprocessed.mjs - validates MDX stripping
npm test            # build + lint + smoke

Pointing an MCP client at it

opencode

Add the following to your project's .opencode/opencode.json (or ~/.config/opencode/opencode.json for global use):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "colyseus-docs-mcp": {
      "type": "local",
      "command": ["npx", "-y", "colyseus-docs-mcp"],
      "enabled": true
    }
  }
}

If you installed it globally, the command can be just ["colyseus-docs-mcp"]. For a local build, use the absolute path to dist/index.js:

{
  "mcp": {
    "colyseus-docs-mcp": {
      "type": "local",
      "command": ["node", "/absolute/path/to/colyseus-docs-mcp/dist/index.js"],
      "enabled": true
    }
  }
}

Restart opencode after saving the file - MCP servers are loaded once at startup.

Other MCP clients (Claude Code, Cursor, etc.)

The server speaks standard MCP over stdio, so any compliant client works. Use npx -y colyseus-docs-mcp or node /path/to/dist/index.js as the launch command.

Tools

`list_docs`

Returns the catalogue of every documentation page known to the server. Use this first when you don't know which page covers a topic.

// Input
{}

// Output (truncated)
{
  "total": 114,
  "docs_root": "/abs/path/to/colyseus-docs-mcp/docs",
  "pages": [
    { "slug": "",                  "title": "Colyseus - Multiplayer Game Framework for Node.js", "category": "index", "description": "…" },
    { "slug": "state",             "title": "State Synchronization", "category": "state",  "description": null },
    { "slug": "room/messages",     "title": "Message Composability", "category": "room",   "description": null },
    …
  ]
}

`read_doc`

Returns the preprocessed Markdown body of a single page.

// Input
{ "slug": "state" }     // "" or "index" returns the landing page

// Output
{
  "content": [
    { "type": "text", "text": "# State Synchronization\n\n…full Markdown…" }
  ]
}

The slug lookup is forgiving - "state", "/state", "state/", and "index" are all accepted.

`search_docs`

Relevance-ranked full-text search. Title hits weighted highest, then headings, then body. Each hit includes a ~250-character snippet around the first match.

// Input
{ "query": "schema @type decorator", "limit": 5 }

// Output
{
  "query": "schema @type decorator",
  "total_hits": 3,
  "hits": [
    {
      "slug": "state/schema",
      "title": "Schema Definition",
      "category": "state",
      "score": 23,
      "snippet": "…the **@type** decorator marks each property…"
    },
    …
  ]
}

Resources

A single URI template is registered so clients can also use resources/read instead of tools/call if they prefer:

colyseus://docs/{slug}

Example:

{ "uri": "colyseus://docs/room" }

Prompts

Name	Purpose
`colyseus_overview`	Returns a system-style primer describing Colyseus + the full doc index.

Configuration

Env var	Default	Purpose
`COLYSEUS_DOCS_PATH`	`<package_root>/docs`	Override the docs directory.

Pointing COLYSEUS_DOCS_PATH at a fresh clone of https://github.com/colyseus/docs is the easiest way to pull in upstream changes - the server reads MDX at startup, so just restart it after a git pull.

Updating the bundled docs

The docs/ directory is a snapshot of Colyseus's MDX pages. To refresh it:

# From another directory of your choice:
git clone https://github.com/colyseus/docs.git upstream-docs

# Back in this package:
rm -rf docs && cp -r ../upstream-docs/pages ./docs
npm run lint && npm run smoke

Releasing

The package version mirrors the Colyseus version whose docs are bundled, with an -mcp.N suffix for successive MCP-only revisions against the same upstream release (e.g. 0.17.10-mcp.1, 0.17.10-mcp.2, …). When you sync docs/ from upstream, bump the upstream segment and reset the MCP counter:

# After `npm run lint && npm run smoke` pass with the refreshed docs:

# New upstream release → reset mcp counter:
npm version 0.18.0-mcp.1

# Same upstream, new MCP-only change → bump mcp counter:
npm version prerelease --preid mcp   # 0.17.10-mcp.1 → 0.17.10-mcp.2

git push --follow-tags

Pushing a v* tag triggers .github/workflows/release.yml, which builds and publishes to npm (with provenance). The NPM_TOKEN secret must be set in the repository's Actions secrets.

Pre-release upstream tags (e.g. 0.18.0-preview.1) are mirrored as 0.18.0-preview.1-mcp.1.

Project layout

colyseus-docs-mcp/
├── .github/workflows/
│   ├── ci.yml             # build + lint + smoke on push/PR
│   └── release.yml        # npm publish on version tags
├── docs/                  # All MDX documentation pages (the data)
├── scripts/
│   ├── smoke-test.mjs     # End-to-end JSON-RPC exercise of every tool/resource
│   └── lint-preprocessed.mjs
├── src/
│   ├── index.ts           # MCP server registration + stdio transport
│   └── lib/
│       ├── docs.ts        # Doc discovery + MDX → Markdown preprocessor
│       └── search.ts      # Ranked full-text search
├── package.json
├── tsconfig.json
└── README.md

License

MIT (inherited from the upstream Colyseus docs - see LICENSE).

Available Tools

3 tools

list_docsList Colyseus documentation pagesA

List every Colyseus documentation page available to this MCP server. Returns each page's slug (use as the slug argument to read_doc), title, category, and a one-line description when present. Use this first to discover what topics are covered before reading individual pages.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses return fields (slug, title, category, one-line description) and notes that slug is used for read_doc. It could mention ordering or pagination, but for a parameterless list tool, the transparency is good.

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 paragraph of three sentences, each earning its place: main action, details of return value, usage guidance. It is front-loaded and free of fluff.

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 parameters, no output schema, and the presence of siblings read_doc and search_docs, the description is complete enough. It covers what the tool does, what it returns, and how to use the results. Minor gaps (e.g., error handling, sorting) are acceptable for a simple list.

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?

No parameters exist, so schema coverage is 100%. The description adds value by explaining that the slug field is meant to be used as the slug argument to read_doc, beyond just listing fields.

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 'List every Colyseus documentation page available to this MCP server,' specifying the verb (list), resource (documentation pages), and scope (every page). It distinguishes from siblings read_doc (reads a specific page) and search_docs (searches).

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?

The description explicitly says 'Use this first to discover what topics are covered before reading individual pages,' providing clear when-to-use guidance and implicitly contrasting with read_doc and search_docs.

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

read_docRead a Colyseus documentation pageA

Read a single Colyseus documentation page by its slug (e.g. 'room', 'room/messages', 'state', 'getting-started/typescript'). Use list_docs first to discover available slugs. Returns pre-processed Markdown — JSX scaffolding from the original MDX has been stripped, but every code block and every prose paragraph is preserved verbatim.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Document slug (path-style identifier). Empty string or 'index' returns the landing page. Slugs may also be tried as paths like '/state/schema'.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Describes output format: pre-processed Markdown with JSX stripped but code blocks and prose preserved. Implicitly indicates read-only operation. Does not disclose all possible behaviors (e.g., error handling, rate limits), but sufficient for scope.

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 sentences with no fluff. First sentence states purpose, second gives guidance, third explains output. Efficiently front-loads 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?

No output schema, so description compensates by explaining return format. Provides usage guidance and sibling tool reference. Could mention error cases or page existence handling, but overall complete for a simple read tool with one parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter 'slug' has schema description already, but tool description adds valuable examples and notes that empty string or 'index' returns landing page. Schema coverage is 100%, and description enhances understanding 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 verb and resource: 'Read a single Colyseus documentation page by its slug'. Examples of slugs are given. Distinguishes from sibling tools by referencing list_docs for discovery.

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?

Explicitly advises to use list_docs first to discover available slugs. Provides context on when to use this tool (reading a specific page) versus listing all pages. Lacks explicit when-not-to-use or alternative guidance, but adequate given sibling context.

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

search_docsSearch Colyseus documentationA

Full-text search across all Colyseus documentation pages. Results are ranked by relevance (title hits weighted highest, then headings, then body) and each hit includes a snippet around the first match. Use this to find pages about a specific API, concept, or recipe (e.g. 'reconnection', 'schema @type', 'rate limit', 'matchmaker').

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Free-form query. Multi-word queries match pages containing every term.
`limit`	No	Maximum number of hits to return (default 10).

TDQS

A4.4/5.0

Behavior4/5

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

The description discloses ranking behavior (weighted by title, headings, body) and that each hit includes a snippet. No annotations are provided, so the description carries the burden; it covers key behaviors but does not mention safety (e.g., read-only nature) or edge cases like no results.

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 extremely concise, with two sentences plus a list of examples. Every sentence serves a purpose: core function, behavior, and usage guidance. No fluff or redundancy.

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 search tool with 2 parameters and no output schema, the description provides sufficient context: scope, ranking, snippets, and example queries. It lacks coverage of response details when no results, but overall is complete enough for an AI agent to use correctly.

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% with both parameters described. The description adds value by explaining that multi-word queries match pages containing every term and providing examples of effective queries (e.g., 'reconnection', 'schema @type'), going beyond schema details.

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 it performs full-text search across all Colyseus documentation pages. It specifies the resource ('all Colyseus documentation pages') and the action ('search'), and distinguishes from siblings 'list_docs' and 'read_doc' by focusing on searching rather than listing or reading.

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 guidance on when to use the tool: 'Use this to find pages about a specific API, concept, or recipe' with relevant examples. However, it does not explicitly state when not to use it or mention alternatives like 'list_docs' or 'read_doc', leaving some room for ambiguity.

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.

3 tool updatesv0.17.10-mcp.1Jun 19, 2026
- First observedlist_docs
- First observedread_doc
- First observedsearch_docs

Install Server

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

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a completely distinct purpose: listing all pages, reading a specific page, and searching across pages. There is no ambiguity or overlap.

Naming Consistency5/5

All three tool names follow a consistent verb_noun pattern using snake_case (list_docs, read_doc, search_docs), making them predictable and easy to understand.

Tool Count4/5

Three tools is minimal but appropriate for a documentation server, covering the essential operations of discovering, reading, and searching content. It is slightly on the thin side but well-scoped.

Completeness4/5

The tool surface covers the core documentation tasks (listing, reading, searching). Minor gaps exist, such as no way to get a table of contents or hierarchical navigation, but list_docs already provides category information, so the gaps are not critical.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

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

developer-toolkit-mcp A
io.github.mjaskolski
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
AI & Machine Learning Search
21
medusa-mcp AOAuth
com.medusajs
Retrieve information from the Medusa documentation to assist you with your Medusa development.
Documentation Access Developer Tools E-commerce & Retail
3
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
OrchaOAuth
io.github.westonhancock
Securely search and manage workspace context files for AI agents and teams.
Search File Systems Knowledge & Memory
1

Related MCP Servers

RAG Documentation MCP Server
RAG Systems Documentation Access Vector Databases
jumasheff
A
license
A
quality
D
maintenance
Provides tools for retrieving and processing documentation through vector search, enabling AI assistants to augment their responses with relevant documentation context.
Updated a year ago (2025-03-16 09:51 UTC)
7
22
1
MIT
Godot Docs MCP
Documentation Access Developer Tools Search
nuskey8
A
license
Not graded
quality
C
maintenance
Enables AI agents to search and retrieve information from the official Godot game engine documentation. Provides tools to search documentation, get page content, and access detailed class information.
Updated a year ago (2025-10-02 01:07 UTC)
25
MIT
MCP Framework Documentation
Documentation Access Developer Tools Search
QuantGeekDev
A
license
A
quality
D
maintenance
Provides tools for AI agents to search, browse, and retrieve the full documentation for the mcp-framework. It enables agents to access documentation sections and page content directly within MCP-compatible environments like Claude Code and Cursor.
Updated 5 months ago (2026-04-01 17:57 UTC)
3
19
MIT
docubridge
Documentation Access Knowledge & Memory
VladMontana
A
license
Not graded
quality
D
maintenance
Provides AI assistants with direct access to local Markdown documentation libraries, enabling them to list, read, and search through docs on demand.
Updated 7 months ago (2026-02-13 17:32 UTC)
MIT

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/VGFP/colyseus-docs-mcp'

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