Skip to main content
Glama

get_workspace_item

Read-onlyIdempotent

Read one item from the user's Clarifo workspaces.

Every read returns content_version (the saved revision). Editor documents come back as text with citations written [n]; source_refs[n] gives the cited page and an openable link. Long items are paged: when has_more is true, call again with cursor=next_cursor until is_complete or has_more is false; never present a partial read as the whole document.

Args: item_id: From list_workspace_items. workspace_id: Optional; the item's workspace. view: full (default, paged text), manifest (section list with section_id and size, no body: start here for long documents), section (one section by section_id, with its subsections), blocks (the document as ordered blocks with block_id, section_id, kind, text, a table as rows of cells and a visual as its visual_id; use it to edit one paragraph or table, and to keep tables and visuals in their places), raw (stored content, long strings capped), visuals (every saved chart, table and card with its stored data, marked [chart V1: ...] in the text, and the saved Visual Story; show these, never a redrawn chart in their place), or since (no body: the item's linked companies, the day it was written, each company's share price change and the periods it has reported since; read the text too before comparing). section_id: For view=section, from the manifest. cursor: next_cursor of the previous page. max_chars: Page size, 2000-50000 (default 12000). company: For view=since: the company (name or ticker) when the item is not linked to one, or to pick one of its linked companies. render: For view=visuals: also return Clarifo's own PNG of each saved chart (drawn by Clarifo from the stored data; with rendered[].renderer "clarifo_chart" the look is Clarifo's chart style, not the editor's) and Visual Story card. Show these images when the user asks to see the document's visuals, and say Clarifo drew them from the saved data. At most 6 images per read; a visual with left_out "image_budget" did not fit: say so and point to editor_url.

Returns: {"item_id", "workspace_id", "workspace_name", "type", "title", "origin", "content_version", "editor_url", "quality", "text", "source_refs": [{"ref": 1, "page": 3, "url": "https://..."}], "is_complete", "has_more", "next_cursor"}

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "item_id": "<item_id>"
    },
    "name": "get_workspace_item"
  }
}

Input Schema

NameRequiredDescriptionDefault
viewNofull
cursorNo
renderNo
companyNo
item_idYes
max_charsNo
section_idNo
workspace_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover read-only and idempotent, and the description goes well beyond them: pagination contract (has_more/next_cursor/is_complete), the warning not to present partial reads as whole documents, the 6-image render budget with the 'image_budget' left_out case, and the note that rendered charts are Clarifo's own style rather than the editor's. This is exactly the extra context the annotations cannot carry.

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-loaded with the core action, then a paging rule, then per-argument detail; nearly every sentence adds information. The view enumeration is dense and long, and a few clauses (e.g. 'never a redrawn chart in their place') repeat the render guidance, so it is slightly heavier than strictly necessary.

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?

For an 8-parameter read with paging, multiple views, and an output schema, the description covers invocation, paging, citation handling, media rendering, and even summarizes the return shape. Nothing an agent needs to call it correctly appears missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does so for all eight parameters — including the view enum's seven modes with per-mode semantics, max_chars bounds (2000-50000, default 12000), and when company applies for view=since. No parameter is left undocumented.

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 opening line names a specific verb and resource ('Read one item from the user's Clarifo workspaces') and implicitly scopes it against list_workspace_items by noting item_id comes from that tool. An agent can tell exactly what single-object read this performs without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete routing advice within the tool: use manifest 'to start' for long documents, blocks to edit one paragraph or table, visuals to show saved charts, since for linked-company/price context. It does not name when NOT to use it versus siblings like document_summary, so the guidance is rich but not fully comparative.

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.