get_image
Retrieve an embedded Logseq screenshot by its ID, returning it as a viewable image for AI agents reading a read-only graph.
Instructions
One screenshot by the id shown next to it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Retrieve an embedded Logseq screenshot by its ID, returning it as a viewable image for AI agents reading a read-only graph.
One screenshot by the id shown next to it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=false). The description adds only that a single image is returned, but says nothing about the return format (raw bytes vs URL vs metadata), image type, or any size/rate constraints that an agent would need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, and the resource is front-loaded. It is efficient, though its brevity contributes to the ambiguity elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations about the response, the description should explain what the agent receives (image data, URL, or metadata) and how the id is sourced. It omits both, leaving the definition inadequate for a retrieval tool whose payload is its whole point.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the single 'id' parameter is undocumented in structured data. The description's 'the id shown next to it' adds only marginal meaning and does not specify the id's format or origin, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (one screenshot/image) and implies retrieval by id, so the gist is discernible. However, 'the id shown next to it' is vague about where that id comes from, and there is no differentiation from siblings like get_block, get_task, or get_page that also fetch entities by id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the sibling get/list tools, nor any prerequisites about needing an id obtained elsewhere. The phrase 'the id shown next to it' hints at a prior listing context but does not state it as a condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.