Postemi: Social Media Scheduler

get_subscription

Read-onlyIdempotent

The subscription that governs the current workspace: its state (none, trialing, active, past_due, read_only or cancelled), the plan name, the billing period, when the current period ends, whether the connected user is the one paying, how many X posts this billing month has used out of the plan's quota (xPosts), and any checkout that has not been paid or expired (pendingCheckout, with the same link).

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. Also call it after the user says they have paid, to confirm the state is "trialing" or "active" before continuing setup; the state changes within seconds of the payment. If it is still "none", ask the user to finish the payment or wait a moment and call again.

When apiAndMcpAccess turns true after a payment, the client should refresh its tool list or reconnect: a connection made before paying sees the billing tools only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_subscription"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`output`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is behavioral context — it delivers the full state vocabulary, the fact that state changes within seconds of payment, the retry protocol when state is still 'none', and the non-obvious connection-refresh consequence of apiAndMcpAccess turning true. That last item is information an agent cannot get from any structured field.

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?

Front-loaded with what is returned, then triggers, then the post-payment edge case — a sensible ordering. It runs three paragraphs and the final paragraph on tool-list refresh is somewhat tangential, but it is operationally load-bearing and nothing is padded.

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?

An output schema exists, yet the description still supplies what the schema cannot: the temporal behavior of the state field, the retry loop, and the post-payment tool-list staleness problem. For a zero-parameter read, nothing an agent needs in order to call it at the right moment is missing.

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?

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The description instead documents the shape of the result, which is helpful but not a parameter concern.

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?

Names a specific verb+resource (get the subscription governing the current workspace) and enumerates exactly what the response covers: state, plan name, billing period, period end, payer identity, X post usage against quota, and pending checkout. This clearly separates it from get_plans (catalogue of available plans), subscribe (initiating), and manage_subscription (mutating).

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?

Explicit when-to-use triggers (user asks about plans, asks to subscribe, asks to manage subscription) plus explicit when-not ('Never volunteer it, and never suggest a plan or an upgrade in any other context'). It also documents a second, non-obvious trigger — calling after the user reports payment — and what to do if the result is still 'none'.

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.