Upload-Post

Official

by Upload-Post

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Generate platform-integration JWT

generate_jwt

Destructive

Generate a JWT and connection URL so end-users can link their social accounts inside an embedded, white-label Upload-Post flow. The profile must already exist.

Instructions

Generate a JWT + connection URL so an end-user can connect socials inside an embedded Upload-Post flow (white-label integration). The profile must already exist. Each call resets the profile's connection-page settings to the values passed. To simply help the account owner connect their own socials, prefer get_connect_link.

Input Schema

Name	Required	Description
`language`	No	Force the connection page language for this profile. When omitted, the page auto-detects the visitor's browser language and falls back to English.
`uiLabels`	No	Flat map of i18n dot-path keys to replacement strings for the connection page, e.g. { 'connect.title': 'Link your accounts' }. Max 100 entries; keys must match ^[a-zA-Z0-9_.]+$ and values are at most 300 characters. Echoed back in the `profile` object of validate_jwt.
`username`	Yes
`logoImage`	No
`platforms`	No
`redirectUrl`	No
`connectTitle`	No
`showCalendar`	No
`readonlyCalendar`	No
`connectDescription`	No
`redirectButtonText`	No

Output Schema

Name	Required	Description	Default
`result`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.11.1Sep 9, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed2 schema fields changedv0.7.0Jul 29, 2026

changedInput schema / properties / language / enum

Previous value: -[
-  "en",
-  "es",
-  "de",
-  "fr",
-  "pt"
-]New value: +[
+  "en",
+  "es",
+  "de",
+  "fr",
+  "pt",
+  "pl",
+  "tr"
+]

addedInput schema / properties / uiLabels

Added value: +{
+  "additionalProperties": {
+    "maxLength": 300,
+    "type": "string"
+  },
+  "description": "Flat map of i18n dot-path keys to replacement strings for the connection page, e.g. { 'connect.title': 'Link your accounts' }. Max 100 entries; keys must match ^[a-zA-Z0-9_.]+$ and values are at most 300 characters. Echoed back in the `profile` object of validate_jwt.",
+  "type": "object"
+}

First observedv0.4.0Jul 16, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The annotations declare destructiveHint=true, and the description explains exactly why: "Each call resets the profile's connection-page settings to the values passed," which is genuinely additive information an agent would otherwise have to discover by breaking a profile. It does not state JWT lifetime, scope of the token, or which settings are cleared when a param is omitted, which are the remaining behavior gaps.

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

Conciseness5/5

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

Four short sentences, each doing distinct work: purpose, prerequisite, destructive side effect, alternative. The alternative is placed last where a routing rule belongs, and nothing is repeated from the schema or annotations verbatim.

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?

The output schema covers return values, so the JWT/URL needn't be explained. However, for an 11-parameter destructive tool at 18% schema coverage, the definition leaves material gaps: which settings get reset when a field is omitted, and how long the JWT is valid / who may use it, are both unanswered.

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

Parameters2/5

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

Schema description coverage is only 18% across 11 parameters, so the description carries the burden — but it names none of the nine undocumented parameters (logoImage, platforms, redirectUrl, connectTitle, showCalendar, readonlyCalendar, connectDescription, redirectButtonText, username). It only implies collectively that they are connection-page settings, which helps framing but not per-parameter meaning.

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?

States a specific verb and dual resource — "Generate a JWT + connection URL" — and pins the audience and scenario (end-user connecting socials inside an embedded, white-label Upload-Post flow). This is clearly distinguishable from the adjacent get_connect_link and validate_jwt siblings without opening any schema.

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?

Gives an explicit prerequisite ("The profile must already exist") and an explicit routing rule to an alternative tool ("To simply help the account owner connect their own socials, prefer get_connect_link"). An agent has both the when and the when-instead handed to it.

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

Deploy Server