Skip to main content
Glama

Postkey: Instagram DM Automation and Comment-to-DM

Finish a file upload

postkey_finish_upload

Postkey: Adds the file sent to postkey_begin_upload's link to the Library, and answers with its library_item_id (use it with postkey_attach_library_item or library_item_ids). Postkey checks that the whole file arrived and is no larger than the size the upload was started with. If nothing arrived, or the link ran out, the upload is given back and you start again with postkey_begin_upload. For a video, send meta with duration_sec, width and height: each platform's length limit is checked with them before the post is sent.

Input Schema

NameRequiredDescriptionDefault
kindYesWhat the file is. Only video and image files can go on a post.
metaNoFor a video: { duration_sec (seconds, decimals allowed), width, height (pixels) }, for example from ffprobe. Anything else is ignored.
pathYesThe path postkey_begin_upload answered with, as it was.
titleYesThe file's title in the Library, 1 to 300 characters.

Output Schema

NameRequiredDescriptionDefault
okYesfalse: refused (isError; code, message, guide_topic, url); no change.
nextNoWhat to do next.
noteNoPresent when the file was already in the Library.
size_bytesNoThe stored size.
library_item_idNoThe new Library file's id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / ok / description
      Previous value: -"false: refused (isError true; code, message, guide_topic, url), nothing changed."New value: +"false: refused (isError; code, message, guide_topic, url); no change."
  2. Changed5 schema fields changed
    • changedInput schema / properties / kind / description
      Previous value: -"What the file is."New value: +"What the file is. Only video and image files can go on a post."
    • changedInput schema / properties / meta / description
      Previous value: -"Facts about the file: duration_sec (seconds, may have decimals), width and height (pixels). Anything else is ignored."New value: +"For a video: { duration_sec (seconds, decimals allowed), width, height (pixels) }, for example from ffprobe. Anything else is ignored."
    • changedInput schema / properties / path / description
      Previous value: -"The path postkey_begin_upload answered with."New value: +"The path postkey_begin_upload answered with, as it was."
    • changedInput schema / properties / title / description
      Previous value: -"The file's title in the Library."New value: +"The file's title in the Library, 1 to 300 characters."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "library_item_id": {
      +      "description": "The new Library file's id.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "next": {
      +      "description": "What to do next.",
      +      "type": "string"
      +    },
      +    "note": {
      +      "description": "Present when the file was already in the Library.",
      +      "type": "string"
      +    },
      +    "ok": {
      +      "description": "false: refused (isError true; code, message, guide_topic, url), nothing changed.",
      +      "type": "boolean"
      +    },
      +    "size_bytes": {
      +      "description": "The stored size.",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    }
      +  },
      +  "required": [
      +    "ok"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses key runtime behavior: Postkey verifies that the whole file arrived and that it is no larger than the size declared at upload start. It also explains what happens on failure and notes that video metadata is used to check platform-specific length limits before posting.

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 a single dense paragraph that front-loads the action, then covers validation, failure recovery, and video metadata. Every sentence carries operational information, though the block could be slightly easier to scan if the failure and video-meta guidance were separated.

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?

Given that an output schema exists, the description need not explain return values in detail, and it still names library_item_id and its downstream use. For a four-parameter upload-finalization tool with nested metadata, it covers the essential workflow, validation behavior, failure handling, and video-specific requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents each parameter well. The description still adds useful meaning by tying path to postkey_begin_upload's response, explaining meta's role in platform length checks for video, and noting that library_item_id can be used downstream.

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 states a specific action: finishing the upload started by postkey_begin_upload, adding the file to the Library, and returning its library_item_id. It clearly distinguishes this step from postkey_begin_upload and postkey_attach_library_item, so an agent can identify the tool's role in the upload workflow.

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?

It explicitly says this is the step after postkey_begin_upload and tells the agent to use the returned id with postkey_attach_library_item or library_item_ids. It also states the failure path: if nothing arrived or the link expired, the upload is given back and the agent must start again with postkey_begin_upload.

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.

Resources