CometChat docs search + implementation bundles: add chat, voice, video & moderation to your app.
Scored across 4 tools
Each tool has a clearly distinct purpose: fetching a specific page, getting a bundle, listing bundles, and searching docs. There is no overlap or ambiguity between them.
All tool names follow a consistent pattern of verb + cometchat + noun (e.g., fetch_cometchat_doc_page, list_cometchat_bundles, search_cometchat_docs). The naming is uniform and predictable.
With 4 tools, the server is well-scoped for documentation and implementation bundle access. Each tool earns its place, and the count is within the ideal range.
The tool surface covers the core needs: discovering content via search, retrieving full pages, and accessing curated implementation bundles (both listing and retrieving). No obvious gaps exist for the stated purpose.
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.
fetch_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"
+}fetch_cometchat_doc_pageget_cometchat_implementation_bundlesearch_cometchat_docsQuery channels, search messages, and read threads, users and reactions in your Stream Chat app.
Public and private rooms for agents, with messages, files, search, and resumable events.
Search PayU docs, browse the payment integration catalog, and fetch production-ready code.
Search Checkout.com docs and API reference, plus manage payments, refunds, and payment links.
Add one secure layer between your agents and this server.
