Skip to main content
Glama

Create Post With Image

create_post_with_image
Destructive

Create a LinkedIn post with an attached image from a local path, optionally previewing it via dry run without publishing.

Instructions

Create a new LinkedIn post with an attached image.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe post body text.
dry_runNoWhen True, compose the post but do not publish.
image_pathYesLocal path to the image file to attach.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.26.2

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the agent knows this publishes to an external network. The description adds nothing beyond that: it does not say the post is immediately live and publicly visible, whether it is reversible, what auth/scopes are required, or that dry_run exists as a safe preview path.

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?

A single tight sentence with the action front-loaded and no filler. It is efficient, though arguably too terse for a tool that publishes externally.

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

Completeness3/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 need no explanation, and the simple three-parameter schema is fully documented. Still, for an externally-publishing mutation the description omits any note about the dry_run preview, visibility of the published post, or failure modes (bad path, oversized image).

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 all three parameters (text, image_path, dry_run) are documented in the schema, so the baseline of 3 applies. The description adds no format, size, or path-validity detail beyond what the schema already states.

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?

States a specific verb and resource ('Create a new LinkedIn post') plus a distinguishing qualifier ('with an attached image') that separates it from the sibling create_post. It does not, however, explicitly name create_post as the text-only alternative, leaving that inference to the agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use, when-not-to-use, or alternative guidance. Nothing tells the agent to pick this over create_post for text-only posts, and the built-in dry_run escape hatch for previewing is never mentioned.

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