Skip to main content
Glama

OpenVidu Docs

by io.openvidu
OverviewDiscussionsAdmin

Get release notes

get_changelog
Read-onlyIdempotent

Returns the release notes / changelog page(s) already indexed for a version (e.g. 'OpenVidu Meet release notes', 'OpenVidu Platform release notes'), without having to guess the URL via search_docs or list_doc_sections. A page cut at 'max_chars' carries 'truncated', 'next_offset' and 'headings': pass its 'url' to get_doc_page with that offset to read on, or with one of those headings to read just that release. 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
productNoRestricts the search to sections whose name contains this word, e.g. 'meet' or 'platform'. Omit to return every release-notes page found.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover safety (readOnly/idempotent/non-destructive), yet the description adds substantial behavior: the '"truncated'/next_offset/headings' structure of a cut page, the 'version_used' field that must be surfaced, and the 'version_warning'/'version_sensitive' signals that indicate edition/product ambiguity in the index. This is real context beyond 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.

Conciseness4/5

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

Front-loads the purpose, then layers continuation and version-handling guidance. It is long and dense for a 3-parameter tool, but nearly every sentence carries actionable instruction (truncation handling, version disclosure, edition/product caveat), so little is wasted.

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?

No output schema exists, but the description explains the response fields (version_used, version_warning, version_sensitive, truncated, next_offset, headings) and covers the index's lack of edition/product awareness. An agent has everything needed to call and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents product, version, and max_chars fully. The description's version guidance largely reiterates the schema's warning against inferring versions from dependencies, adding routing advice rather than new parameter semantics. Baseline 3 is appropriate.

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?

The description opens with a specific verb+resource: it returns release notes/changelog pages already indexed for a version, and explicitly contrasts this with guessing a URL via search_docs or list_doc_sections. That is enough to distinguish it from every sibling without opening a 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?

It states when to use it (to avoid URL-guessing via search_docs/list_doc_sections), how to continue reading a truncated page (get_doc_page with next_offset or a heading), and names the alternative tool (resolve_openvidu_version_edition_product, plus AGENTS.md/CLAUDE.md first check) for resolving the version. Explicit alternatives and conditions are all present.

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