Skip to main content
Glama

Put an image in the post

place_image
Read-onlyIdempotent

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read: the Markdown for an image already uploaded to your draft, ![alt](name "caption"), and with markdown the post with it in after the paragraph after names (or at the end) and the image rules read on it. Alt text is required (WCAG 2.1): without it, or with one that is the file name, "screenshot", the caption again, under 5 or over 250 characters, it returns the question to ask the engineer and no snippet: never write one yourself. decorative: true, only on the engineer's word, places a decorative image with empty alt. Saves nothing: save the post with update_draft.

Input Schema

NameRequiredDescriptionDefault
idYesThe draft's 8-character id (list_drafts lists yours)
altNoThe engineer's own description of what it shows, 5 to 250 characters, not the file name, "screenshot" or the caption (WCAG 2.1); never yours. Refused, with the reason, when it doesn't serve
nameYesThe image's name, as the upload answered
afterNoA few words of the paragraph the image goes after; left out, it goes at the end
captionNoA caption shown under it (optional, at most 140 characters)
markdownNoThe whole post: returned with the image in, and the image rules read on it
decorativeNotrue only when the engineer says the image is purely decorative: no alt, no caption, and screen readers skip it

Output Schema

NameRequiredDescriptionDefault
idYes
nameYes
nextYes
problemNoWhy the alt text was refused: empty, short, long, filename, generic or caption
snippetYes
findingsYes
markdownNo
questionNo
needs_altYes
next_actionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent, and non-destructive, and the description adds important behavioral context: auth scope, that it saves nothing, that invalid alt text returns a question rather than a snippet, and how decorative images are handled. These details go well beyond the structured annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description contains useful information and little outright fluff, but it is a dense run-on with awkward phrasing, especially the opening sentence about Markdown insertion. It is not front-loaded as cleanly as it could be, which makes the rules harder to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter tool with an output schema and annotations, the description covers the key operational context: auth, image pre-upload, alt validation, decorative handling, placement, and no-save behavior. It could more explicitly route image uploading to request_image_upload, but the core completeness is strong.

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%, so all seven parameters are already documented. The description reinforces alt-text and decorative behavior, but most parameter meaning is duplicated from the schema rather than adding new semantics beyond it. A baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

It states a specific action: producing the Markdown for an already-uploaded image and the post with that image inserted after a named paragraph, while explicitly noting it does not save. It also distinguishes itself from update_draft for saving. The phrasing "A read:" is awkward, but the purpose is still clear enough for an agent to identify.

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?

The description gives explicit prerequisites (engineer Microsoft sign-in, image already uploaded), conditions for decorative images (only on the engineer's word), the alt-text requirement and refusal behavior, and the alternative action for saving with update_draft. It effectively covers when to use this tool and what not to do.

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.