Postemi: Social Media Scheduler

Start a Postemi subscription for the current workspace. Creates a Stripe Checkout link for the plan and billing period the user chose, and returns it. Nothing is charged by this call.

Call this only when the user asks about plans, asks to subscribe, or asks to manage their subscription. Never volunteer it, and never suggest a plan or an upgrade in any other context.

How to use it:

Confirm the plan (tier: basic, pro, creator, team) and the period (monthly or yearly) with the user first. Call get_plans if they have not chosen yet. Only a plan with apiAndMcpAccess: true in get_plans keeps this connection working after the payment; Basic does not include API or MCP access. When the user picks such a plan, tell them before they pay that you will not be able to schedule for them afterwards.
Call this tool once, then give the user the checkoutUrl. The user opens it and pays with their OWN Link wallet or card. Do NOT pay with a one-time or agent-issued card, a virtual card number, or any credential of your own: a Postemi subscription renews monthly or yearly, and a one-time credential fails at the first renewal, which cancels the plan.
After the user says they have paid, call get_subscription to confirm the state is "trialing" or "active" before continuing setup. Do not assume. If get_subscription already reports a pendingCheckout, hand that link back instead of calling this again. The link expires; the answer says when.

Works for connections made by signing in (Claude, ChatGPT and other OAuth clients), for the workspace owner only. A connection made with an MCP key is refused; the user subscribes in Postemi instead. Refused when the workspace already has a live subscription: use manage_subscription for plan changes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tier": "<tier>",
      "period": "<period>"
    },
    "name": "subscribe"
  }
}

Input Schema

Name	Required	Description	Default
`tier`	Yes	The plan "slug" from get_plans: basic, pro, creator, team.
`period`	Yes	How often the plan renews.

Output Schema

Name	Required	Description	Default
`output`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A5/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: the call creates an external Stripe Checkout link, charges nothing itself, returns checkoutUrl, and the link expires. It also discloses critical constraints around payment credentials, workspace ownership, OAuth vs MCP-key connections, and refusal when a live subscription already exists.

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?

The description is long but justified for a high-stakes payment flow. It front-loads the core action and no-charge guarantee, then organizes prerequisites, the call sequence, and edge cases into clear numbered steps.

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 the tool's complexity, external payment dependency, and authorization constraints, the description is complete. It even explains the returned checkoutUrl despite an output schema existing, and it covers refusal and retry cases thoroughly.

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?

Although the schema already has 100% coverage and enum values, the description adds critical meaning: Basic does not include API or MCP access, and only plans with apiAndMcpAccess: true keep the connection working after payment. It also tells the agent to confirm tier and period with the user before calling.

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 uses a specific verb and resource: 'Start a Postemi subscription' and 'Creates a Stripe Checkout link for the plan and billing period the user chose.' It clearly distinguishes this tool from manage_subscription by noting that plan changes go through manage_subscription.

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 states when to call it: only when the user asks about plans, subscribing, or managing their subscription, and never volunteered otherwise. It also names alternatives and prerequisites, including get_plans when no plan is chosen, get_subscription to confirm payment, and manage_subscription for plan changes.

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

All Postemi: Social Media Scheduler tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

subscribe