CometChat docs search + implementation bundles: add chat, voice, video & moderation to your app.
Scored across 4 tools
Each tool targets a distinct retrieval mode: search for topic discovery, fetch for a known URL/path, list for enumerating bundle identifiers, and get for compiling a defined scenario's pages. The descriptions explicitly cross-reference each other and state when to use which tool, leaving no realistic overlap.
All names are snake_case verb_noun with a consistent 'cometchat' namespace segment (fetch_...doc_page, get_...bundle, list_...bundles, search_...docs). Minor deviations: 'fetch' vs 'get' for read-style operations and singular 'doc_page' vs plural 'docs', but the pattern remains predictable.
Four tools is a lean but well-scoped surface for a documentation server, and each covers a genuinely different retrieval need. list_cometchat_bundles is borderline redundant given get_bundle's unknown_bundle error already enumerates valid ids, but it still earns its place as a discovery call.
The lifecycle of docs retrieval is covered: discover via search, enumerate curated scenarios via list, compile a scenario via bundle, and read any page live via fetch, with documented error and truncation behavior. Minor gaps: no way to list navigation/site structure or browse pages without a query, and no feedback/correction channel for stale pages.
Returns one CometChat documentation page in full, as markdown with its title, url and section. Takes a url or path already in hand: a docs link from a bundle, or a result url from search_cometchat_docs, which is where a topic or API name goes instead, since that is not a path.
Each call reads the live docs site, so it sees pages the search index has not picked up yet. A moved page is followed for up to 3 redirects; a page over 50 KiB is truncated, ending in a link to the full page. No key or account is needed, and nothing is cached.
Errors: not_found for an unknown page or one redirected to the docs root, invalid_input for a path resolving outside the documentation, backend_unavailable when the site fails or the whole redirect chain exceeds the 5 s default timeout (retryable).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Page path such as '/sdk/javascript/overview' (a leading slash, a '/docs' prefix and a '.md' or '.mdx' suffix are optional), or a full https://www.cometchat.com/docs/... URL; up to 500 characters. Query strings and #fragments are ignored. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Absolute canonical page url, after any redirect. |
| title | Yes | Page title. |
| content | Yes | Page body as markdown. |
| section | Yes | Documentation section, derived from the page's path. |
| contentLength | Yes | Byte length of content, after any truncation. |
| redirectedFrom | No | Path originally requested, present only when that page has moved; url and section describe where it landed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly/openWorld/non-destructive), so the bar is lower, but the description still discloses live-site reads, 3-redirect follow limit, 50 KiB truncation with a link to the full page, no auth, no caching, and a full error taxonomy including which error is retryable. That is behavior an agent cannot infer from any structured field.
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?
Information is front-loaded: what it returns, then what it takes, then runtime behavior, then errors. Dense but nearly every clause carries actionable content; the redirect/truncation clause is a single compact sentence rather than sprawl.
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?
An output schema exists, so the description does not need to detail the return object, yet it still hints at the fields. For a single-parameter read tool with annotations and an output schema, everything an agent needs to call it correctly and interpret failures is present.
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 would be a 3. The description adds real meaning beyond the schema by framing the parameter's provenance (a bundle link or a search result URL) and by tying a bad path to specific errors (not_found vs invalid_input for paths resolving outside the docs).
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?
States a specific verb and resource ('Returns one CometChat documentation page in full') and even names the return shape (markdown with title, url, section). The contrast with search_cometchat_docs is explicit, so an agent can route without opening either schema.
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?
Gives the exact precondition ('Takes a url or path already in hand: a docs link from a bundle, or a result url from search_cometchat_docs') and names the alternative for the opposite case ('a topic or API name goes instead, since that is not a path'). This is a textbook when/when-not split.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one CometChat implementation bundle: the scenario's current documentation pages (for a UI Kit, its integration guide, then the platform's AI reference page) compiled into one markdown document, each headed by its source URL, plus paths of related pages, the prerequisites, and a last_verified date.
Eleven bundles cover UI Kit quickstarts (React, Angular, React Native, Flutter, iOS, Android), JavaScript SDK messaging, the no-code widget, moderation setup, multi-tenant chat, and presence and typing. list_cometchat_bundles names them all; for a topic no bundle covers, or for one reference page rather than a setup's pages, search_cometchat_docs searches the documentation.
bundle is an identifier, not a title and not a framework: 'react-uikit-quickstart', rather than 'React UI Kit' or 'react'. One that is well-formed but names no bundle returns unknown_bundle listing every valid one; anything else, invalid_input. Pages are included whole, in order, while the document fits in 60 KiB; a page that does not fit is listed by path under More pages rather than cut, except a first page too big on its own, which is cut at a paragraph and ends with a link to the full page. Pages are read from the live docs site; no key or account is needed. A built bundle is served for 10 minutes, then refreshed in the background. A page that cannot be loaded does not fail the call: the previous bundle, or a partial one naming the pages it lacks, is served instead, and backend_unavailable is returned only when no page loads and nothing is cached yet.
| Name | Required | Description | Default |
|---|---|---|---|
| bundle | Yes | Bundle identifier as list_cometchat_bundles returns it, e.g. 'react-uikit-quickstart': lowercase letters, digits and hyphens, opening with a letter or digit, up to 100 characters. |
| Name | Required | Description |
|---|---|---|
| title | Yes | Human-readable bundle title. |
| bundle | Yes | Bundle identifier, as passed in. |
| content | Yes | The bundle's documentation pages as markdown, each headed by its source URL, followed by the paths of related pages and of any page that did not fit or could not be loaded. |
| framework | Yes | Framework or platform the bundle targets; 'any' when platform-neutral. |
| last_verified | Yes | ISO date this bundle's list of documentation pages was last reviewed. The page content itself is read from the live documentation. |
| prerequisites | Yes | What must be in place before following the bundle's pages, such as a runtime version or CometChat app credentials. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only and non-destructive; the description adds substantial context beyond them: whole pages in order, a 60 KiB document budget, oversized pages listed under 'More pages' rather than truncated (with a paragraph-level cut exception for an oversized first page), a 10-minute serve window with background refresh, graceful degradation via the previous or partial bundle, and backend_unavailable only when nothing loads and nothing is cached. No key or account required is also stated, which annotations cannot express.
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?
Front-loaded with what is returned, then alternatives, then the parameter trap, then operational behavior — a sensible order. The prose is dense with semicolon-linked clauses and a long final sentence about failure modes, which costs a little readability, but every sentence carries information an agent needs to call the tool correctly.
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?
An output schema exists, so return shape need not be restated, and the description still covers the operational envelope an agent must anticipate: content ordering, size limits and truncation, caching staleness, and degraded/error responses. Nothing material for correct invocation is missing given a single required parameter.
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% and already documents the identifier's format, so the baseline is 3; the description earns an extra point by clarifying that the value is an identifier, not a title or framework ('react-uikit-quickstart', not 'React UI Kit' or 'react'), and by mapping the two distinct error outcomes (unknown_bundle with the valid list versus invalid_input) to the kinds of wrong input. It does not add syntax beyond the schema, so it stops short of 5.
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?
Names a specific verb and resource ('Returns one CometChat implementation bundle') and immediately defines the artifact: the scenario's documentation pages compiled into one markdown document, each headed by its source URL, plus related paths, prerequisites, and a last_verified date. The following sentence enumerates the eleven covered scenarios, so an agent knows exactly what content surface this tool owns versus its 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?
Explicitly routes between siblings: list_cometchat_bundles names the bundles, search_cometchat_docs is the fallback for a topic no bundle covers or for a single reference page, and fetch_cometchat_doc_page covers the single-page case. Both the when and the when-not conditions are stated, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every CometChat implementation bundle: the setup scenarios whose current docs pages get_cometchat_implementation_bundle compiles by identifier, with each one's title, framework ('any' when platform-neutral) and last_verified date.
No parameters are required: one call returns the complete set, ordered by identifier, with no filter, paging or cap. The set is fixed at startup, since only page content is read from the docs site; the listing itself opens no connection and needs no key or account, so repeat calls return the same bundles.
For a topic no bundle covers, or for one reference page rather than a setup's pages, search_cometchat_docs searches the documentation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| total | Yes | Number of bundles. |
| bundles | Yes | Every bundle, ordered by identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered; the description still adds real behavioral context beyond that: no key or account required, no network connection opened by the listing, the set is fixed at startup, and repeat calls return identical bundles. That idempotence and auth-free guarantee is exactly what an agent needs and is not in the structured fields.
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?
Three short paragraphs, front-loaded with the definition and immediately followed by invocation facts and then fallback routing. Every sentence carries information an agent would otherwise have to guess: the enumeration's completeness, its ordering, and where to go when it does not apply.
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?
An output schema exists, so return values need not be documented, yet the description still summarizes the per-bundle fields and the 'any' framework sentinel. Combined with the idempotence and no-auth notes, nothing an agent needs in order to call this zero-argument tool correctly 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?
There are zero input parameters, which sets the baseline at 4. The description reinforces this by explicitly stating that no parameters are required and that there is no filter, paging or cap, so an agent will not go looking for optional arguments that do not exist.
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 ('Lists every CometChat implementation bundle') and then defines what a bundle actually is (setup scenarios whose docs pages get_cometchat_implementation_bundle compiles by identifier), which distinguishes it from every sibling. It also names the fields returned (title, framework, last_verified), so an agent knows the shape of the catalog before calling.
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?
It gives clear positive context (one call returns the complete set, no filters or paging needed) and explicit negative routing: for an uncovered topic or a single reference page, use search_cometchat_docs instead. It stops short of explicitly telling the agent to call this first to discover identifiers before invoking get_cometchat_implementation_bundle, so the discovery workflow is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches all of CometChat's documentation (SDKs, UI Kits, Calls, REST API, AI agents, notifications, moderation, the no-code widget, UI Kit Builder and more) for the pages covering a topic or API name, and returns ranked excerpts with each page's url.
When a page's url or path is already in hand, fetch_cometchat_doc_page returns that page in full; for a common setup scenario (a UI Kit quickstart, SDK messaging, the widget, moderation), list_cometchat_bundles names the implementation bundles, each the scenario's current docs pages compiled into one document.
Pages holding every keyword rank first, falling back to any keyword when no page holds them all; no match is an empty results list, not an error. For a query of 4 to 8 distinct keywords, pages missing one incidental keyword join the ranking at half weight, which is how an API renamed between versions is still found; a platform or language word is never the one dropped. Without the version filter, current-version pages lead, and each result reports isCurrent plus a version label when the page is versioned; the filter restricts results to pages carrying that label, so unversioned pages such as the REST API reference are excluded. limit caps the rows returned, never the totalAvailable count, and there is no offset.
Results come from a snapshot of the documentation repository, rebuilt periodically, so a page published since the last rebuild is missing until then; fetch_cometchat_doc_page reads the live site. Errors: invalid_input for a malformed argument, backend_unavailable when the index cannot be read. Over HTTP, every MCP request counts against one per-client-IP limit, initialize and tools/list included, by default 120 per 60 s, then HTTP 429 with Retry-After; no authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results, from 1 to 25; default 10. | |
| query | Yes | Plain keywords, 1–500 characters; short queries work best. Name the platform or framework when the answer is platform-specific ("iOS delete message", "React UI Kit message list"); otherwise results span platforms. API names such as markAsRead are searchable, as are the languages of a page's code examples. Quotes and operators such as OR have no special meaning, and common words such as "how", "is" and "can" are not counted as keywords. A version written in the query ("v4") is matched as a keyword: it favours pages mentioning it but does not restrict results to that version, even when it is the whole query. To get one version's pages, put the label in the version filter instead. | |
| version | No | Version label from the docs version picker, e.g. 'v5'. The leading v is optional and case does not matter, so V7, 7 and v7.0 all name v7. Each SDK and UI Kit numbers its versions independently, so one label spans every product that uses it. A label no page carries returns no results rather than an error. |
| Name | Required | Description |
|---|---|---|
| results | Yes | Matching pages, best first. |
| totalAvailable | Yes | Number of matching pages, which can exceed the rows returned. For a query of 4 to 8 distinct keywords it also counts the pages holding all but one of them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds substantial non-annotation context: match/fallback ranking, empty list rather than error on no match, snapshot staleness versus the live site, error codes, and the per-IP HTTP rate limit with 429/Retry-After. That is well beyond what the annotations 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?
Front-loaded with purpose and sibling routing before behavioral detail, and every paragraph is ordered by likely need. It is dense and long, though — the '4 to 8 distinct keywords ... half weight' explanation is more mechanism than an agent strictly needs to choose or call the tool.
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 3-parameter search tool with an output schema and full annotation coverage, nothing essential is missing: staleness, empty-result semantics, error codes, rate limiting, and no-auth are all stated. Return-value explanation is appropriately delegated to the output schema.
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%, so a 3 is the floor; the description goes further by explaining cross-parameter behavior the schema cannot — that limit caps returned rows but never totalAvailable, and that there is no offset. It also clarifies that a version keyword in the query does not restrict results, pointing at the version filter instead.
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?
States a specific verb (searches) plus the exact resource scope — all CometChat documentation across named product areas — and the return shape (ranked excerpts with each page's url). It is immediately distinguishable from fetch_cometchat_doc_page (full page retrieval) and the bundle tools.
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?
Explicitly routes the agent: 'When a page's url or path is already in hand, fetch_cometchat_doc_page returns that page in full', and 'for a common setup scenario ... list_cometchat_bundles names the implementation bundles'. Both the when-to-use and the when-to-use-something-else conditions are stated.
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_page6 fields changedInput schema / properties / path / descriptionPrevious value: -"Documentation path or full URL. Relative paths like '/sdk/javascript/overview' and full URLs both work."New value: +"Page path such as '/sdk/javascript/overview' (a leading slash, a '/docs' prefix and a '.md' or '.mdx' suffix are optional), or a full https://www.cometchat.com/docs/... URL; up to 500 characters. Query strings and #fragments are ignored."Output schema / properties / content / descriptionPrevious value: -"Full page content as markdown (truncated if very large)."New value: +"Page body as markdown."Output schema / properties / contentLength / descriptionPrevious value: -"Content length in bytes after truncation."New value: +"Byte length of content, after any truncation."Output schema / properties / redirectedFrom / descriptionPrevious value: -"Path originally requested, present only when that page has moved. url and section describe the page it moved to."New value: +"Path originally requested, present only when that page has moved; url and section describe where it landed."Output schema / properties / section / descriptionPrevious value: -"Documentation section the page belongs to."New value: +"Documentation section, derived from the page's path."Output schema / properties / url / descriptionPrevious value: -"Canonical page URL."New value: +"Absolute canonical page url, after any redirect."get_cometchat_implementation_bundle6 fields changedInput schema / properties / bundle / descriptionPrevious value: -"Bundle name in lowercase kebab-case, e.g. 'react-uikit-quickstart'."New value: +"Bundle identifier as list_cometchat_bundles returns it, e.g. 'react-uikit-quickstart': lowercase letters, digits and hyphens, opening with a letter or digit, up to 100 characters."Output schema / properties / bundle / descriptionPrevious value: -"Bundle identifier."New value: +"Bundle identifier, as passed in."Output schema / properties / content / descriptionPrevious value: -"The full implementation recipe as markdown."New value: +"The bundle's documentation pages as markdown, each headed by its source URL, followed by the paths of related pages and of any page that did not fit or could not be loaded."Output schema / properties / framework / descriptionPrevious value: -"Target framework/platform."New value: +"Framework or platform the bundle targets; 'any' when platform-neutral."Output schema / properties / last_verified / descriptionPrevious value: -"Date the bundle was last verified against live SDK versions."New value: +"ISO date this bundle's list of documentation pages was last reviewed. The page content itself is read from the live documentation."Output schema / properties / prerequisites / descriptionPrevious value: -"Prerequisites before applying the bundle."New value: +"What must be in place before following the bundle's pages, such as a runtime version or CometChat app credentials."list_cometchat_bundles4 fields changedOutput schema / properties / bundles / descriptionPrevious value: -"All available implementation bundles."New value: +"Every bundle, ordered by identifier."Output schema / properties / bundles / items / properties / framework / descriptionPrevious value: -"Target framework/platform."New value: +"One of android, angular, any, flutter, ios, javascript, react, react-native, or widget."Output schema / properties / bundles / items / properties / last_verified / descriptionPrevious value: -"Date the bundle was last verified against live SDK versions."New value: +"ISO date this bundle's list of documentation pages was last reviewed."Output schema / properties / total / descriptionPrevious value: -"Number of bundles available."New value: +"Number of bundles."search_cometchat_docs12 fields changedInput schema / properties / limit / defaultAdded value: +10Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return. Default 10, maximum 25."New value: +"Maximum results, from 1 to 25; default 10."Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / query / descriptionPrevious value: -"Search query. 1–500 characters."New value: +"Plain keywords, 1–500 characters; short queries work best. Name the platform or framework when the answer is platform-specific (\"iOS delete message\", \"React UI Kit message list\"); otherwise results span platforms. API names such as markAsRead are searchable, as are the languages of a page's code examples. Quotes and operators such as OR have no special meaning, and common words such as \"how\", \"is\" and \"can\" are not counted as keywords. A version written in the query (\"v4\") is matched as a keyword: it favours pages mentioning it but does not restrict results to that version, even when it is the whole query. To get one version's pages, put the label in the version filter instead."Input schema / properties / version / descriptionPrevious 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."New value: +"Version label from the docs version picker, e.g. 'v5'. The leading v is optional and case does not matter, so V7, 7 and v7.0 all name v7. Each SDK and UI Kit numbers its versions independently, so one label spans every product that uses it. A label no page carries returns no results rather than an error."Output schema / properties / results / descriptionPrevious value: -"Ranked search results."New value: +"Matching pages, best first."Output schema / properties / results / items / properties / isCurrent / descriptionPrevious value: -"False when the page documents an older version of its SDK or UI Kit."New value: +"False when the page documents an older version of its SDK or UI Kit, or a doc set retired from the docs navigation, which may carry no version label."Output schema / properties / results / items / properties / section / descriptionPrevious value: -"Documentation section the page belongs to."New value: +"Documentation section the page belongs to, e.g. 'UI Kit / React'."Output schema / properties / results / items / properties / snippet / descriptionPrevious value: -"Matched excerpt with context."New value: +"Matched excerpt with context, up to 300 characters."Output schema / properties / results / items / properties / url / descriptionPrevious value: -"Direct link to the source page."New value: +"Absolute page url, accepted as-is by fetch_cometchat_doc_page."Output schema / properties / results / items / properties / version / descriptionPrevious value: -"Version label of the page's SDK or UI Kit, e.g. 'v7'. Omitted for pages that are not versioned."New value: +"Version label of the page's SDK or UI Kit, e.g. 'v7'. Absent on a page that carries no version, including the pages of a retired SDK or UI Kit."Output schema / properties / totalAvailable / descriptionPrevious value: -"Total matching pages available (may exceed the returned count)."New value: +"Number of matching pages, which can exceed the rows returned. For a query of 4 to 8 distinct keywords it also counts the pages holding all but one of them."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.
Search the Amomic-AI docs and REST API for AI agents on calls, WhatsApp, chat and email.
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.
Add one secure layer between your agents and this server.
