Skip to main content
Glama
mspstack

mcp-itglue

by mspstack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create IT Glue Document Image

itglue_create_document_image

Upload an image into an IT Glue document body so it renders inline or in a gallery, bypassing attachment-only limitations.

Instructions

Upload a picture INTO a document — the only way to get an image to render in a document's body (itglue_create_attachment only files it in the Attachments panel). Two placements: (1) INLINE — omit gallery_id; the result carries inline_resource_url, a relative path you must use verbatim as in Text/Step section HTML via itglue_create_document_section or itglue_update_document_section, or pass append_to_section_id to have this tool append the to an existing Text/Step section for you. (2) GALLERY — pass gallery_id (the document_gallery_id shown on a Gallery or Step section) to file the image into that gallery. Never put base64/data: URIs or S3 URLs in section content; IT Glue strips them. Provide exactly one source: upload_id (a file the client PUT via itglue_request_upload — the right choice for anything on the client's disk), url (the server fetches it), file_path (local stdio runs only), or content_base64 (tiny files only). content_base64 must be the exact bytes of a real image file — never write or reconstruct base64 yourself (IT Glue rejects anything ImageMagick cannot decode). file_name needs an extension (e.g. screenshot.png); inferred from url/file_path when omitted. Max 25 MB.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoURL the server fetches and base64-encodes
file_nameNoFile name with extension; inferred from url/file_path if omitted
file_pathNoLocal filesystem path to read (stdio transport only)
upload_idNoID from itglue_request_upload after the client has PUT the file to the returned URL — the server reads the bytes itself
gallery_idNodocument_gallery_id of a Gallery/Step section to file the image into; omit for an inline image
document_idYesThe document the image belongs to
content_base64NoBase64-encoded file bytes (a leading data: URI prefix is stripped) — small files only
response_formatNoOutput format: human-readable markdown (default) or structured JSONmarkdown
append_to_section_idNoInline only: ID of an existing Text/Step section to append <div><img src=…></div> to after upload

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.6.0
    • changedInput schema / properties / content_base64 / description
      Previous value: -"Base64-encoded file bytes (a leading data: URI prefix is stripped)"New value: +"Base64-encoded file bytes (a leading data: URI prefix is stripped) — small files only"
    • addedInput schema / properties / upload_id
      Added value: +{
+  "description": "ID from itglue_request_upload after the client has PUT the file to the returned URL — the server reads the bytes itself",
+  "type": "string"
+}
  2. Addedv0.5.0

TDQS

A4.9/5.0
Behavior5/5

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

Even though annotations already mark readOnlyHint=false, the description adds substantial behavioral context: the result carries inline_resource_url which must be used verbatim in section HTML, the server strips certain URL types, content_base64 must be exact bytes or ImageMagick rejects it, and there is a 25 MB limit. This goes far beyond the annotation surface and helps the agent anticipate real-world behavior.

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?

The description is long but every sentence carries operational weight, covering placements, source selection, URL handling, and constraints. It is front-loaded with the core purpose and the critical distinction from create_attachment. A slight reorganization of the inline/gallery flow could improve scannability, but there is no wasted prose.

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 a complex 9-parameter tool with no output schema, the description covers the all-important return behavior (inline_resource_url), the append workflow, the source options, and the failure-prone edge cases. An agent has enough context to select parameters and call the tool correctly without further inference.

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 coverage is already 100%, but the description adds meaning well beyond each parameter's schema line. It explains the relationship between upload_id and itglue_request_upload, clarifies that file_path is only for local stdio runs, and describes how file_name is inferred. The interplay between gallery_id and append_to_section_id is made concrete where the schema alone would leave ambiguity.

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 opens with a specific verb and resource—'Upload a picture INTO a document'—and immediately distinguishes itself from a sibling: 'the only way to get an image to render in a document's body (itglue_create_attachment only files it in the Attachments panel).' This makes the tool's purpose and boundary unmistakable.

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 when-to-use guidance for the two placements (inline vs gallery) and provides decision rules for choosing among the four sources: upload_id, url, file_path, and content_base64. It also warns about alternatives and forbidden inputs (base64/data: URIs and S3 URLs), telling the agent exactly when not to do something.

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

Deploy Server

Other Tools