Skip to main content
Glama

PostWire

Show my PostWire account

my_account
Read-onlyIdempotent

Shows the signed-in PostWire account: plan, usage against each plan limit (posts this month, brands, AI drafts today), brands, and which social accounts are connected, each with its brand and the handle, display name and picture the network reports for it. When a limit is at least 80 % used, the result includes the plan that raises it, its monthly price and a checkout link. When no social account is connected, it includes a one-hour link to connect one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral detail beyond that: it specifies exactly what content appears (plan, usage limits, brands, connected accounts) and describes conditional behavior (upgrade link when a limit is ≥80%, connect link when no social account). This is rich transparency.

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 three sentences but packs all essential information without redundancy. It fronts the core purpose, then lists contents, then notes conditional additions. Every sentence earns its place; nothing extraneous.

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?

With no output schema, the description fully carries the burden of explaining return values. It does so comprehensively: plan, usage against limits, brands, connected accounts with details, and conditional upgrade/connect links. An agent can predict the output structure accurately. No gaps.

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?

The tool has zero parameters, and the empty schema covers 100% of them. Per the guidelines, the baseline for 0 parameters is 4. The description adds no parameter information because there are none, but it doesn't need to.

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 is specific: 'Shows the signed-in PostWire account' clearly identifies the verb and resource. It expands on what is shown (plan, usage, brands, connected accounts) and mentions conditional outcomes, making it easily distinguishable from sibling tools like list_brands or list_platforms.

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

Usage Guidelines4/5

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

The description clearly communicates the tool's scope: it provides an overall account snapshot. No explicit alternatives are mentioned, but none are needed since no sibling duplicates this functionality. The context is unambiguous enough for an agent to know when to call it.

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.