Contio MeetingOS

Read a canvas's metadata and Markdown body. Use this for a quick look at a canvas when you do not need to edit it. `content` is the stored Markdown body — the same body v1GetCanvasContent returns — but carries no ETag, and recent writes may take a moment to appear here. `content_version` counts writes to the body and is not a concurrency token. Before editing, always call v1GetCanvasContent to obtain the 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 Markdown body. Use this for a quick look at a canvas when you do not need to edit it.

content is the stored Markdown body — the same body v1GetCanvasContent returns — but carries no ETag, and recent writes may take a moment to appear here. content_version counts writes to the body and is not a concurrency token. Before editing, always call v1GetCanvasContent to obtain the 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	Markdown body; the same body /content returns. Read /content for its ETag.
`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 body has been written. Not a concurrency token; use the ETag from /content.
`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 wrote the body, if known

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 10, 2026

changedOutput schema / properties / content / description

Previous value: -"Cached Markdown body. May trail live edits; see /content for the live body."New value: +"Markdown body; the same body /content returns. Read /content for its ETag."

changedOutput schema / properties / content_last_edited_by / description

Previous value: -"ID of the user whose edit last refreshed the cache, if known"New value: +"ID of the user whose edit last wrote the body, if known"

changedOutput schema / properties / content_version / description

Previous value: -"Number of times the cached body has been refreshed. Not a concurrency token."New value: +"Number of times the body has been written. Not a concurrency token; use the ETag from /content."

AddedSep 24, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real context: content may lag recent writes, it carries no ETag, content_version is a write counter not a concurrency token, role is EDITOR/VIEWER, and missing canvases return 404. None of this is derivable from the annotations.

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 purpose, then layers semantic caveats in short, distinct sentences. Dense but every sentence carries distinct information (staleness, ETag absence, version semantics, role, 404) with no filler, though it runs long enough to slow a quick read.

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 needn't explain return values, and it instead covers the behavioral edge cases (staleness, ETag, version, role, 404) that an agent needs to call and interpret this safely. Nothing material is missing.

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?

Single parameter with 100% schema description coverage, so the schema already documents 'id' fully. The description adds no syntax or format detail beyond it, which makes the baseline 3 appropriate.

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?

Gives explicit when-to-use ('a quick look ... when you do not need to edit it') and when-not/alternative ('Before editing, always call v1GetCanvasContent to obtain the body and its etag'). This is exactly the routing guidance the sibling relationship demands.

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?