Skip to main content
Glama

Fetch CometChat Documentation Page

fetch_cometchat_doc_page
Read-only

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).

Input Schema

NameRequiredDescriptionDefault
pathYesPage 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

NameRequiredDescriptionDefault
urlYesAbsolute canonical page url, after any redirect.
titleYesPage title.
contentYesPage body as markdown.
sectionYesDocumentation section, derived from the page's path.
contentLengthYesByte length of content, after any truncation.
redirectedFromNoPath originally requested, present only when that page has moved; url and section describe where it landed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / path / description
      Previous 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."
    • changedOutput schema / properties / content / description
      Previous value: -"Full page content as markdown (truncated if very large)."New value: +"Page body as markdown."
    • changedOutput schema / properties / contentLength / description
      Previous value: -"Content length in bytes after truncation."New value: +"Byte length of content, after any truncation."
    • changedOutput schema / properties / redirectedFrom / description
      Previous 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."
    • changedOutput schema / properties / section / description
      Previous value: -"Documentation section the page belongs to."New value: +"Documentation section, derived from the page's path."
    • changedOutput schema / properties / url / description
      Previous value: -"Canonical page URL."New value: +"Absolute canonical page url, after any redirect."
  2. Changed1 schema field changed
    • 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"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.