Skip to main content
Glama

Show generated item

read_artifact
Read-only

Return a generated item itself, for showing it where a YouSpot link cannot be opened: a social image comes back as the PNG, a PDF as an image of each page, an email, document or Substack post as its text. Takes an artifact_id from a generator or list_artifacts. A draft comes back watermarked; the user unlocks the clean copy for a credit, or at no charge on a Solo or Pro plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
artifact_idYesAn artifact_id from a generator or list_artifacts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

With readOnlyHint=true already declaring the safety profile, the description adds genuinely non-obvious behavior: drafts return watermarked and unlocking the clean copy costs a credit (free on Solo/Pro). That credit/watermark detail is not derivable from annotations or schema and is exactly the kind of context an agent needs before promising output to a user.

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?

Three sentences, all carrying load, with the core purpose front-loaded. Slightly dense in the middle enumeration, but nothing is redundant or filler.

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?

There is no output schema, so the description correctly compensates by describing return formats per artifact type, plus the draft/credit caveat. For a one-parameter read tool, an agent has everything it needs to call it and set user expectations.

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 description coverage is 100%, and the description merely echoes the schema's own wording about where the artifact_id comes from. No format, type, or validation detail is added beyond the structured field, so the baseline 3 applies.

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 gives a specific verb+resource ('Return a generated item itself') and then enumerates exactly what comes back per artifact type (PNG for social image, per-page images for PDF, text for email/document/Substack). This is far more than a name restatement and lets an agent predict the return shape.

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?

It names the triggering condition clearly ('for showing it where a YouSpot link cannot be opened') and states the input source ('an artifact_id from a generator or list_artifacts'). It does not, however, distinguish itself from the sibling get_artifact, which an agent would plausibly confuse it with.

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.