A read-only, no-auth MCP server that lets AI coding agents browse CometChat's public documentation and pull ready-to-use integration recipes for adding chat, voice, video, and moderation to an app.
Search docs (search_cometchat_docs) — query SDK guides (JS, React, iOS, Android, Flutter, React Native), UI Kits, REST API, tutorials, and OpenAPI specs; returns ranked snippets with titles, source URLs, section, version label, and whether the page is current. Supports an optional version filter and limit up to 25.
Fetch a page (fetch_cometchat_doc_page) — get one doc page in full as markdown by relative path or full URL, with title and section metadata, following moved pages (reports redirectedFrom); very large pages are truncated.
Get an implementation bundle (get_cometchat_implementation_bundle) — pull a curated scenario recipe (React, Flutter, iOS, Android, React Native, JS SDK, widget embed, moderation, multi-tenant, presence/typing) containing prerequisites, install commands, configuration, working code, and common pitfalls.
List bundles (list_cometchat_bundles) — discover every available bundle with its identifier, title, target framework, and last-verified date.
Resources — an orientation skill (cometchat://skills/overview) plus 11 bundle resources exposing the same scenarios as MCP resources.
Safe by design — all four tools are read-only (readOnlyHint: true) with declared output schemas; no account, API key, or authentication required, and no writes to any CometChat app.
Enables integration with Android apps using the CometChat Android UI Kit (Jetpack Compose) and SDK for real-time chat, voice, and video.
Provides Angular UI Kit integration for adding chat, voice, and video capabilities to Angular applications.
Allows Flutter apps to integrate real-time chat, voice, and video using the CometChat Flutter UI Kit and SDK.
Enables iOS apps to integrate real-time chat, voice, and video using the CometChat iOS UI Kit (SwiftUI) and SDK.
Provides the JavaScript SDK for integrating real-time messaging and media into web applications.
Supports Android app integration using the Jetpack Compose-based CometChat UI Kit for modern Android development.
Facilitates integration with Next.js applications, leveraging React UI Kit for building chat features.
Allows React applications to add real-time chat, voice, and video using the CometChat React UI Kit.
Provides a no-code widget integration for Shopify stores to add chat functionality.
Offers a no-code widget for embedding chat into Squarespace websites.
Enables Swift-based iOS apps to integrate CometChat using the SwiftUI UI Kit and SDK.
Provides a no-code widget for adding chat to Webflow sites.
Offers a no-code widget for embedding chat into Wix websites.
Enables a no-code widget integration for adding chat to WordPress sites.
Add real-time chat, voice, video, and moderation to your app through your AI coding agent.
Docs • CometChat • Get an account (free, 100 MAU)
CometChat's first-party MCP server. Connect Claude, Cursor, Windsurf, VS Code Copilot, Codex, or any other Model Context Protocol–compatible agent and integrate CometChat into your app from natural-language prompts.
Ask the agent: "add a chat tab where users can DM each other" — it reads CometChat's documentation, picks the right components for your stack, and writes the integration code.
Read-only. No account, no API key, no authentication required.
An AI agent reading CometChat's docs and writing a working chat integration from a single prompt.
Related MCP server: ElevenLabs MCP Server
Agent | How to add |
Claude.ai / Claude Desktop | Settings → Connectors → Add custom connector → URL: |
Cursor |
|
Windsurf | Plugins (hammer icon) → Manage plugins → View raw config → paste config below |
VS Code (Copilot Agent) |
|
Claude Code (CLI) |
|
Smithery |
|
Codex CLI |
|
{
"mcpServers": {
"cometchat": {
"url": "https://mcp.cometchat.com/mcp"
}
}
}After connecting, prompt your agent with any of these:
"How do I install the React UI Kit in my Vite project?"
"Walk me through multi-tenant chat for a Next.js SaaS where workspaces are isolated."
"Show me how to add presence indicators and typing dots to my iOS conversation list."
"Set up content moderation so banned words are blocked before delivery."
"Build a no-code chat widget for my Webflow site."
"What's the rate limit for sending messages, and what error code do I get when I hit it?"
The agent reads CometChat's documentation, pulls the relevant implementation bundle, and writes the integration code into your project.
search_cometchat_docs — Search the SDK, UI Kit, Calls, REST API, AI agent, notification and moderation docs by topic, API name or error message. Returns ranked snippets with page URLs, current versions first. Optional version filter and limit (up to 25).
fetch_cometchat_doc_page — Fetch one documentation page in full as markdown by URL or path, following moved pages. Pages over 50 KiB are truncated with a link to the full page.
get_cometchat_implementation_bundle — Return the implementation bundle for a named scenario: the scenario's current docs pages (for a UI Kit: its integration guide, then the platform's AI reference page) compiled into one document, plus related page paths.
list_cometchat_bundles — List every available implementation bundle (identifier, title, framework, date its page list was reviewed) for discovery.
All four carry readOnlyHint: true, a title annotation, and a declared outputSchema with structured results. Names are ≤ 64 characters. Each description states what the tool does, when it fits and its limits (errors, rate limit), naming this server's other tools only where one serves a specific need ("identifiers come from list_cometchat_bundles"). They carry no directives to the agent, no references to other servers or products, and no marketing language. tests/tools.test.ts guards the tool, parameter and output-field descriptions and the initialize instructions against a list of banned phrasings, and checks that list still rejects the shapes it was written for; it is a banlist, not a proof.
URI | Purpose |
| Agent orientation skill — Product summary, decision guidance, workflow, common gotchas, verification checklist |
| React UI Kit install + init + login + chat surface |
| React Native UI Kit with navigation and chat screen |
| Flutter UI Kit install + init + basic chat |
| iOS UI Kit install + chat view |
| Android UI Kit install + chat screen |
| Angular UI Kit install + init + login + chat surface |
| Vanilla JS SDK — send/receive text and media messages |
| No-code widget embed for HTML, with pointers to WordPress, Webflow and Squarespace |
| Moderation getting started, with pointers to rules, lists and flagged messages |
| Multi-tenancy — isolated apps under one plan, App Management APIs |
| Online presence, typing indicators, read receipts |
You prompt your agent in natural language.
The agent reads the orientation skill (cometchat://skills/overview) to understand which tool/bundle fits your request.
For top scenarios, the agent pulls an implementation bundle — the current docs pages for that integration in one document.
For long-tail questions, the agent searches CometChat's docs and reads specific reference pages.
The agent writes the code into your project, using the bundle as the source of truth and your project structure as the constraint.
CometChat is a real-time communications platform for adding chat, voice, and video calling to web and mobile apps. Used in production across SaaS, marketplaces, gaming, healthcare, education, and creator platforms.
Free tier: first 100 monthly active users, no credit card required.
SDKs: JavaScript, React Native, iOS, Android, Flutter.
UI Kits: React, React Native, iOS, Android, Flutter, Angular, Vue.
No-code: chat widget for any HTML site.
Sign up: app.cometchat.com — you'll need an App ID, Auth Key, and Region to build with the code the agent writes.
Field | Value |
Display name | CometChat Docs |
Version | 0.1.7 |
Protocol | MCP |
Transport | Streamable HTTP (with SSE) |
Authentication | None (public docs only) |
Capabilities |
|
Health endpoint |
|
Your agent (Claude / Cursor / Windsurf / …)
↓ MCP over Streamable HTTP
↓
mcp.cometchat.com/mcp (this server)
↓
├── search_cometchat_docs → SQLite FTS5 index of cometchat/docs
├── fetch_cometchat_doc_page → cometchat.com/docs/*.md (first-party)
└── get_cometchat_implementation_bundle → live docs pages listed in src/bundles/manifest.tsStateless server, single universal endpoint, no user-specific state.
Search index rebuilds from github.com/cometchat/docs on every push to that repo's main branch.
Implementation bundles have no content of their own. Each is a list of docs pages (src/bundles/manifest.ts), read from the live docs on request, so a docs fix reaches the bundle with no MCP change. A built bundle is served for 10 minutes; after that a call still gets it at once and starts one background rebuild. A rebuild that hits a timeout or 5xx never replaces the cached bundle and is retried with a backoff (30 s, doubling, up to 10 minutes), so a docs outage neither drops bundles nor floods the docs site. A deleted page (404) is what the docs say: once a second build in a row agrees, that rebuild is kept and names the missing page. npm run verify:bundles fails when a listed page moves, disappears, no longer fits in its bundle, is no longer the current version in docs.json, or tells people to install a package version that is unpublished, on an older major, or an exact pin a minor behind (checked against npm, pub.dev, CometChat's Maven repo, CocoaPods trunk and GitHub); the maintainers run it daily.
# Clone the docs repo (used to build the search index)
git clone --depth 1 https://github.com/cometchat/docs.git ../cometchat-docs-repo
# Install + build the FTS index + run the server
npm install
DOCS_REPO=../cometchat-docs-repo npm run build:index
npm run dev
# Run the test suite (vitest: validation, truncation, bundles, tools, resources, fetch,
# search ranking and the index builder)
npm test
# Score search ranking on the index you built (CI pins the docs commit: see DEPLOY.md)
DOCS_REPO=../cometchat-docs-repo npm run eval:search
# Check every docs page a bundle lists still exists and is current (network)
npm run verify:bundlesThe server listens on http://0.0.0.0:3000 by default. Health probe at GET /health, MCP endpoint at POST /mcp.
npx @modelcontextprotocol/inspector
# add server: http://localhost:3000/mcpYou should see all 4 tools with readOnlyHint: true and all 11 resources.
docs-mcp/
├── src/
│ ├── server.ts # MCP server entry, transport, tool dispatch
│ ├── tools/{search,fetch,bundle}.ts
│ ├── search/sqlite.ts # SQLite FTS5 client
│ ├── bundles/manifest.ts # each bundle's docs pages
│ ├── bundles/loader.ts # compiles bundles from live docs pages
│ ├── resources/registry.ts # skill + bundle resources
│ └── lib/{errors,truncate,validation,logger}.ts
├── scripts/build-index.ts # builds SQLite FTS5 index from cometchat/docs
├── skills/overview.md # agent orientation skill
├── tests/ # vitest suite
├── .claude-plugin/
│ ├── plugin.json # Claude Code plugin manifest
│ └── marketplace.json # Claude Code marketplace manifest
├── .codex-plugin/plugin.json # Codex plugin manifest
├── .cursor-plugin/plugin.json # Cursor Marketplace manifest
├── .mcp.json # MCP config (Claude Code auto-discovery)
├── mcp.json # Open Plugins standard manifest
└── assets/logo.svg # CometChat logoEnv var | Default | Notes |
|
| HTTP port |
|
| Bind host |
|
| Used for URLs in responses + the |
|
| SQLite FTS5 index location. Server still boots if missing; search returns |
|
| Orientation skill ( |
|
| Per-fetch HTTP timeout |
|
|
|
|
| Standard Node.js setting (Express runs in production mode); set |
|
| Comma-separated |
| unset | Comma-separated browser |
|
| Set |
|
| Set |
|
| Max requests per window per IP. Positive integer; |
|
| Rate-limit window in ms. Positive integer |
|
| Set |
|
| How often to check the docs repo for a new commit (a |
|
| Where rebuilt index generations are written (tmpfs in production) |
|
| Previous index generations retained on disk for instant fallback |
|
| Absolute floor: a candidate index with fewer pages is rejected |
|
| Relative floor: reject a candidate losing more than this fraction of the served page count, or of the served pages whose versions come from docs.json navigation |
|
| Public docs repo; cloned anonymously, no credentials |
|
| Branch to follow |
| unset | Freeze on one commit and stop following |
| unset | PostHog project API key. Unset = usage analytics fully disabled (no-op) |
|
| PostHog instance host |
| unset | Required when |
See DEPLOY.md for container build, environment, and platform notes.
The same server URL is listed across multiple agent marketplaces:
Marketplace | Listing |
Smithery | |
Glama | |
Cursor Marketplace |
|
Cursor Directory |
|
Anthropic Connector Directory |
|
Codex Marketplace |
|
Issues / feedback: open an issue in this repo.
CometChat support: support@cometchat.com.
Live MCP status: curl https://mcp.cometchat.com/health returns {"status":"ok"} when healthy.
PRs welcome — especially:
New implementation bundles: add an entry to src/bundles/manifest.ts listing existing docs pages. If no page covers the scenario, write the page in cometchat/docs first; bundle content always comes from the docs.
Tool improvements behind the existing read-only contract.
Out of scope today:
Tools that write to a customer's CometChat app (separate authenticated connector, on the roadmap).
Mixed read/write tools (Anthropic auto-rejection rule).
The CometChat MCP server is read-only and requires no account, API key, or authentication. It serves only CometChat's public documentation and does not request, store, or transmit your code, prompts, or personal data. Standard request metadata (such as IP address) may be processed transiently for rate limiting and abuse prevention.
For full details, see CometChat's privacy policy: cometchat.com/legal-privacy-policy.
Apache-2.0. See LICENSE.
Fetches the full content of a single CometChat documentation page by URL or path. Returns the page content as markdown along with title and section metadata. Path can be passed as a full https://www.cometchat.com/docs URL or as a relative path such as '/sdk/javascript/overview'.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Documentation path or full URL. Relative paths like '/sdk/javascript/overview' and full URLs both work. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Canonical page URL. |
| title | Yes | Page title. |
| content | Yes | Full page content as markdown (truncated if very large). |
| section | Yes | Documentation section the page belongs to. |
| contentLength | Yes | Content length in bytes after truncation. |
| redirectedFrom | No | Path originally requested, present only when that page has moved. url and section describe the page it moved to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description builds on that by disclosing the return format ('markdown along with title and section metadata') and the flexible path input. It doesn't cover error behavior or rate limits, but for a simple read operation this is solid additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed with all essential information: operation, resource, return type, and accepted path forms. No filler or redundant phrases; front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, the description covers everything an agent needs: the exact input format, the returned content type, and metadata inclusion. There are no hidden requirements or ambiguous behaviors left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description already explains that both relative paths and full URLs work. The tool description largely repeats this same information with a concrete example, adding no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetches' and a clear resource: 'the full content of a single CometChat documentation page'. It explicitly contrasts with sibling tools by emphasizing 'single page', distinguishing it from search or bundle-list operations. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: fetch a known documentation page by URL or path when you need its full markdown content and metadata. It doesn't explicitly name alternatives or exclusion conditions, but the use case is evident from the resource and the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a curated implementation bundle for a named CometChat integration scenario. Each bundle includes prerequisites, install commands, configuration, working code examples, and common pitfalls. Available bundles cover common integration patterns across React, Flutter, iOS, Android, React Native, and the JavaScript SDK.
| Name | Required | Description | Default |
|---|---|---|---|
| bundle | Yes | Bundle name in lowercase kebab-case, e.g. 'react-uikit-quickstart'. |
| Name | Required | Description |
|---|---|---|
| title | Yes | Human-readable bundle title. |
| bundle | Yes | Bundle identifier. |
| content | Yes | The full implementation recipe as markdown. |
| framework | Yes | Target framework/platform. |
| last_verified | Yes | Date the bundle was last verified against live SDK versions. |
| prerequisites | Yes | Prerequisites before applying the bundle. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction exists. The description adds genuine behavioral context by specifying that the result includes prerequisites, install commands, configuration, working code examples, and common pitfalls, which tells the agent what to expect from the tool beyond the read-only guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the core action and resource, then efficiently summarize bundle contents and supported platforms. Every sentence adds value and there is no redundant restatement of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, the description is nearly complete: it explains what the bundle contains and which platforms are covered. It falls just short by not explicitly pointing the agent to list_cometchat_bundles for discovering available bundle names, though the sibling tool name makes this inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description already documents the kebab-case format and gives an example. The tool description adds little beyond saying the bundle is for a named integration scenario, so the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') tied to a clear resource ('a curated implementation bundle') and a named integration scenario. It also enumerates what the bundle contains, distinguishing this tool from documentation search or bundle listing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you need a ready-made implementation bundle for a CometChat scenario. However, there is no explicit guidance on when to use it versus list_cometchat_bundles or fetch_cometchat_doc_page, and it does not mention that list_cometchat_bundles should be used first to discover valid bundle names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every available CometChat implementation bundle with its identifier, title, target framework, and last-verified date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| total | Yes | Number of bundles available. |
| bundles | Yes | All available implementation bundles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals this is a non-mutating operation. The description adds that the tool returns the full set of bundles, which is a meaningful behavioral guarantee beyond the annotation, and it lists the data fields returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence that front-loads the action and scope while also summarizing the output fields. Every part of the description earns its place, and there is no unnecessary repetition of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only list operation with an output schema, the description is fully sufficient. An agent can determine when to call it)Skip and what it will receive without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parametershol, so the schema is already 100% descriptive. No additional parameter explanation is needed; the description correctly focuses on what the response contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a precise verb ('Lists') and identifies the exact resource ('every available CometChat implementation bundle') plus the returned fields. This makes it easy to distinguish from the singular get_cometchat_implementation_bundle and the search-focused search_cometchat_docs tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the enumeration/discovery tool for bundles, useful before fetching a specific bundle via get_cometchat_implementation_bundle. It does not explicitly state exclusions or name alternatives, but the zero-argument interface leaves little ambiguity in when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches CometChat documentation including SDK guides (JavaScript, React, iOS, Android, Flutter, React Native), UI Kit references, REST API documentation, integration tutorials, and OpenAPI specs. Returns ranked snippets with titles and direct links to source pages. Pages for the current version of each SDK and UI Kit are preferred over older versions, and each result reports its version label and whether it is current. To reach older docs, pass the version filter with that version's label.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. Default 10, maximum 25. | |
| query | Yes | Search query. 1–500 characters. | |
| version | No | Optional version label from the docs version picker, e.g. 'v7' or 'v5'. Each SDK and UI Kit numbers its versions independently, so a label matches every product that uses it. Omit to search all versions, with current versions preferred. |
| Name | Required | Description |
|---|---|---|
| results | Yes | Ranked search results. |
| totalAvailable | Yes | Total matching pages available (may exceed the returned count). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses meaningful behaviors: results are ranked snippets, pages carry titles and direct links, current versions are preferred, and each result reports a version label and currency. This adds actionable behavioral detail that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence defines scope and output, the second explains version behavior and usage. Every sentence earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with an output schema and readOnlyHint annotation, the description covers what the tool returns, what it searches, version handling, and how to access older content. Nothing essential for selecting or invoking it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the version preference behavior and how the version filter interacts with it ('To reach older docs, pass the version filter'). This goes beyond the schema's dry parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Searches CometChat documentation') and enumerates the content scope (SDK guides, UI Kit references, REST API, tutorials, OpenAPI specs). It also differentiates itself from sibling tools like fetch_cometchat_doc_page by emphasizing ranked snippets, titles, and direct links rather than page retrieval or bundle listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context on version behavior: current versions are preferred, and older docs require a version filter with the correct label. However, it does not explicitly say when to choose this tool over siblings like fetch_cometchat_doc_page, nor does it state exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.6fetch_cometchat_doc_page1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "description": "Full page content as markdown (truncated if very large).",
+ "type": "string"
+ },
+ "contentLength": {
+ "description": "Content length in bytes after truncation.",
+ "type": "number"
+ },
+ "redirectedFrom": {
+ "description": "Path originally requested, present only when that page has moved. url and section describe the page it moved to.",
+ "type": "string"
+ },
+ "section": {
+ "description": "Documentation section the page belongs to.",
+ "type": "string"
+ },
+ "title": {
+ "description": "Page title.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Canonical page URL.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "url",
+ "section",
+ "content",
+ "contentLength"
+ ],
+ "type": "object"
+}get_cometchat_implementation_bundle1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bundle": {
+ "description": "Bundle identifier.",
+ "type": "string"
+ },
+ "content": {
+ "description": "The full implementation recipe as markdown.",
+ "type": "string"
+ },
+ "framework": {
+ "description": "Target framework/platform.",
+ "type": "string"
+ },
+ "last_verified": {
+ "description": "Date the bundle was last verified against live SDK versions.",
+ "type": "string"
+ },
+ "prerequisites": {
+ "description": "Prerequisites before applying the bundle.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "description": "Human-readable bundle title.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "bundle",
+ "title",
+ "framework",
+ "prerequisites",
+ "last_verified",
+ "content"
+ ],
+ "type": "object"
+}list_cometchat_bundlessearch_cometchat_docs2 fields changedInput schema / properties / version / descriptionPrevious value: -"Optional documentation version filter, e.g. 'v4' or 'v3'."New value: +"Optional version label from the docs version picker, e.g. 'v7' or 'v5'. Each SDK and UI Kit numbers its versions independently, so a label matches every product that uses it. Omit to search all versions, with current versions preferred."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "results": {
+ "description": "Ranked search results.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "isCurrent": {
+ "description": "False when the page documents an older version of its SDK or UI Kit.",
+ "type": "boolean"
+ },
+ "section": {
+ "description": "Documentation section the page belongs to.",
+ "type": "string"
+ },
+ "snippet": {
+ "description": "Matched excerpt with context.",
+ "type": "string"
+ },
+ "title": {
+ "description": "Page title.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Direct link to the source page.",
+ "type": "string"
+ },
+ "version": {
+ "description": "Version label of the page's SDK or UI Kit, e.g. 'v7'. Omitted for pages that are not versioned.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "url",
+ "snippet",
+ "section",
+ "isCurrent"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalAvailable": {
+ "description": "Total matching pages available (may exceed the returned count).",
+ "type": "number"
+ }
+ },
+ "required": [
+ "results",
+ "totalAvailable"
+ ],
+ "type": "object"
+}v0.1.5fetch_cometchat_doc_pageget_cometchat_implementation_bundlesearch_cometchat_docsScored across 4 tools
Each tool has a clearly distinct purpose: listing bundles, searching docs, fetching a full doc page, and retrieving a specific implementation bundle. No two tools overlap in functionality, so an agent can confidently select the right one.
All tool names follow a consistent verb_noun pattern in snake_case (list_, search_, fetch_, get_), making the API predictable and easy to reason about. The prefix 'cometchat' further reinforces the domain.
With only 4 tools, the server is well-scoped for its purpose of documentation and bundle retrieval. Each tool earns its place, and the count is within the ideal 3-15 range without unnecessary bloat.
The surface covers the essential operations: discovering bundles, getting a specific bundle, searching documentation, and fetching a full doc page. There are no obvious gaps for the stated domain, and version filtering is handled via the search tool.
Search @imqueue docs and scaffold typed services & clients from your AI coding agent.
Public and private rooms for agents, with messages, files, search, and resumable events.
Helps AI coding agents integrate MetaMask Embedded Wallets (Web3Auth) SDKs.
Create and manage AI agents that collaborate and solve problems through natural language interacti…
