Skip to main content
Glama

get_board_thumbnail

Retrieve a Miro board's thumbnail image URL for a quick preview. Reads the board's picture field, which is a small rendered preview rather than a full-fidelity export.

Instructions

Get the board's thumbnail image URL.

Reads the board's picture field — a small rendered preview, not a full-fidelity export. For PDF/SVG use the Enterprise export job tools.

Input Schema

NameRequiredDescriptionDefault
board_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden and does well: it explains the tool reads the board's `picture` field and explicitly limits fidelity to a low-resolution preview. It doesn't mention permissions or rate limits, which keeps it from a 5, but the key behavioral caveat (not full fidelity) is front and center.

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?

Two short sentences with zero waste, and the core promise (thumbnail URL, small preview) is front-loaded before the alternative is named. Every sentence earns its place.

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?

An output schema exists, so return values needn't be explained. Combined with the fidelity caveat and the pointer to export tools for PDF/SVG, an agent has everything needed to call this correctly for a simple one-parameter getter.

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?

There is one required parameter, `board_id`, and schema description coverage is 0%, so nothing in the schema explains it and the description doesn't mention it either. The parameter is self-evident by name, so this is adequate but not enriched beyond the structured field.

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 states a specific verb and resource: 'Get the board's thumbnail image URL.' It also distinguishes itself from the export family by saying it reads the small 'picture' preview rather than a full-fidelity export, so an agent can tell it apart from get_board_export_job_results without opening either 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 gives both when-to-use ('small rendered preview') and when-not-to-use ('For PDF/SVG use the Enterprise export job tools'), naming the concrete alternative. Nothing is left to inference about which sibling handles exports.

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