Contio MeetingOS

Read a canvas's metadata and cached Markdown body. Use this for a cheap look at a canvas when exact up-to-the-second content is not required. `content` is the Postgres cache refreshed by the in-app editor and by v1UpdateCanvasContent, so it may lag concurrent live edits; `content_version` counts cache refreshes and is not a concurrency token. Before editing, always call v1GetCanvasContent to obtain the live body and its `etag`. `role` is the caller's effective access (EDITOR or VIEWER). Inaccessible or unknown canvases return 404.

getCanvas

Read-onlyIdempotent

Read a canvas's metadata and cached Markdown body. Use this for a cheap look at a canvas when exact up-to-the-second content is not required.

content is the Postgres cache refreshed by the in-app editor and by v1UpdateCanvasContent, so it may lag concurrent live edits; content_version counts cache refreshes and is not a concurrency token. Before editing, always call v1GetCanvasContent to obtain the live body and its etag. role is the caller's effective access (EDITOR or VIEWER). Inaccessible or unknown canvases return 404.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Canvas ID

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	Unique identifier of the canvas
`role`	No	Caller's effective role on the canvas: EDITOR or VIEWER
`title`	No
`content`	No	Cached Markdown body. May trail live edits; see /content for the live body.
`created_at`	No
`updated_at`	No
`template_id`	No	Template the canvas was created from or last had applied, if any
`workspace_id`	No
`content_version`	No	Number of times the cached body has been refreshed. Not a concurrency token.
`owned_by_user_id`	No	ID of the user who owns the canvas
`created_by_user_id`	No	ID of the user who created the canvas
`workspace_canvas_role`	No	Access granted to every workspace member who is not an explicit collaborator: VIEWER or NOACCESS
`content_last_edited_by`	No	ID of the user whose edit last refreshed the cache, if known

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 24, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavioral context: content is a Postgres cache that may lag live edits, content_version is not a concurrency token, role reflects effective access, and inaccessible/unknown canvases return 404. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is compact but information-dense, with purpose front-loaded and each sentence adding a distinct behavioral fact. No filler or restatement beyond the purposeful first sentence.

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?

With an output schema present, the description need not restate return fields. It covers cache lag, concurrency caveat, required live lookup before edits, role semantics, and 404 behavior, making the tool's call context complete.

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 coverage is 100% ('Canvas ID') and the description does not add further meaning to the id parameter. The 404 behavior for unknown/inaccessible canvases is useful but relates to error semantics rather than parameter syntax or format, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

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?

Explicitly scopes when to use: 'Use this for a cheap look... when exact up-to-the-second content is not required.' It also tells the agent to call v1GetCanvasContent before editing to get the live body and etag, making the alternative and exclusion explicit.

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

All Contio MeetingOS tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?