Skip to main content
Glama

OpenVidu Docs

by io.openvidu
OverviewDiscussionsAdmin

Get a documentation page

get_doc_page
Read-onlyIdempotent

Returns the content of a page of the OpenVidu documentation (openvidu.io) for a specific version, or of several pages at once with 'urls' (one round trip instead of several). Pass exactly one of 'url' and 'urls'. A URL ending in a #anchor, as search_docs returns for a match under a heading, returns only that heading's section, subsections included; 'heading' does the same by name, and comes with the page's 'intro' and 'headings': when the answer may also depend on setup or context described elsewhere, read those sections too, or drop the anchor to read the whole page. A page longer than 'max_chars' comes back cut: 'truncated' is true, 'total_chars' is its full length, 'next_offset' is the 'offset' that reads the next chunk, and 'headings' lists its sections and their sizes, so you can read only the one you need. Every URL returned is the page as a person opens it: link those in answers. list_doc_sections with 'section' gives valid URLs; so does search_docs. The response includes 'version_used': always tell the user which documentation version what you're telling them corresponds to. If it also carries 'version_warning', or 'version_sensitive': true on a result or in a page's 'version_note', the page changes between versions: say so explicitly and explain how to specify a different one. The index has no notion of edition or product, so if the answer depends on either, say which one you assumed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoOne page URL, as list_doc_sections or search_docs return it. With a #anchor, only that heading's section.
urlsNoSeveral page URLs instead of 'url', up to 10. Each comes back under 'pages', with its own error if it is not in the index, and a #anchor reads that section only.
offsetNoCharacter of each page to start from. Pass a previous response's 'next_offset' to read on.
headingNoWith 'url': read only the section under this heading, by its text as 'headings' or search_docs name it, or by its anchor.
versionNoVersion of the OpenVidu SERVER the project's deployment runs, as the deployment reports it ('3.9.0', '3.9.1'): documentation is published per minor release, so it resolves to '3.9'. DO NOT INFER it from the project's dependencies (livekit-client, livekit-server-sdk, web components): their versions do NOT correspond to the server's, and passing one here returns documentation for the wrong version. To find out for real, call 'resolve_openvidu_version_edition_product' with no arguments: it returns the procedure to obtain the version, the edition (ce/pro) and the product (Platform/Meet) from the deployment itself. Cheaper first check: the project's AGENTS.md/CLAUDE.md, where it may already be pinned. If you have none of these, OMIT the parameter: the default version is used and the response tells you whether that matters for the page being queried. Don't guess.
max_charsNoCharacters of each page to return, from 'offset'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoThe page as a person opens it: link this one.
errorNoWhy this page could not be returned.
introNoThe page's text before its first section, with a section.
pagesNo
contentNo
headingNoThe heading whose section this is.
headingsNoThe page's headings, when it is cut, a section of it was read, or the heading asked for is not on it.
truncatedNoThe page goes on past this chunk.
versionedNo
page_charsNoLength of the whole page, when a section was read.
next_offsetNo'offset' of the next chunk, when truncated.
total_charsNoLength of the page, or of the section read.
version_usedNoDocumentation version that answered.
requested_urlNo
resolved_fromNoHow it was chosen: default, explicit, normalized, alias_latest, or url (the release a get_doc_page URL names).
default_versionYes
heading_not_foundNo
available_versionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: truncation mechanics ('truncated', 'total_chars', 'next_offset'), the meaning of #anchor vs 'heading', the one-round-trip batching tradeoff, and the version-reporting contract ('version_used', 'version_warning', 'version_sensitive'). That is exactly the kind of operational context structured fields 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause and each subsequent sentence carries distinct payload (batching, anchors, truncation, versioning). It is nonetheless a dense, prose-heavy block, and the version guidance is longer than strictly needed, which keeps it short of a 5.

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?

Even though an output schema exists, the description anticipates the agent's real failure modes: version inference from unrelated dependencies, silent truncation, and unstated edition/product assumptions. Nothing an agent needs to call this correctly or report results faithfully is missing.

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% and the schema descriptions are already rich, so the baseline is 3. The description still adds non-schema constraints, notably the mutual exclusivity of 'url' and 'urls', anchor-vs-heading equivalence, and how 'offset'/'max_chars' chain across responses.

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 the content of a page of the OpenVidu documentation (openvidu.io) for a specific version') and explicitly covers the batch variant via 'urls'. It also distinguishes itself from siblings by naming search_docs and list_doc_sections as the sources of valid URLs.

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 an explicit selection rule ('Pass exactly one of url and urls'), explains when to read only a heading section vs. dropping the anchor to read the whole page, and routes to the right siblings (list_doc_sections, search_docs, resolve_openvidu_version_edition_product). Both when-to-use and when-to-widen are covered.

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

All OpenVidu Docs toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources