SyncBooster

Get account

syncbooster_get_account

Read-only

Returns the current UTC time, your plan limits, AI token balance, story limits and agent credential scopes. The token balance and the free-plan story allowance are those of the calling user; when acting on a brand as a team member, the brand owner pays for AI tokens and stories. Creating a post with syncbooster_create_post costs 20 AI tokens per post; editing, previewing, scheduling and publishing are free. Channel timezones and local times are available with list_brands.

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": "syncbooster_get_account"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`plan`	Yes
`limits`	Yes
`now_utc`	Yes
`stories`	Yes
`ai_tokens`	Yes
`credential`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already establish read-only, non-destructive, closed-world behavior, so the bar is lower; the description still adds real semantics beyond them. The token attribution rule (caller vs. brand owner) and the per-operation cost model (20 tokens to create a post, free to edit/preview/schedule/publish) are behavioral facts no annotation or schema conveys. It does not mention rate limits or staleness of the returned balance.

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?

It is front-loaded with the returned data, then layers on ownership and cost semantics, which is the right order. Every sentence carries information, though the cost-of-posting sentence sits slightly awkwardly in a getter description and could be tightened. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shape need not be explained; the description instead covers the non-obvious interpretation layer, namely whose quota is being reported. For a zero-parameter read tool this is close to complete, with only the when-to-call ordering versus get_brand_context left implicit.

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 takes zero parameters and the schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description enumerates concrete resources returned: UTC time, plan limits, AI token balance, story limits, and agent credential scopes. That is far more specific than the bare name 'get_account', and it partially differentiates from siblings by pointing to list_brands for timezone data. It does not distinguish itself from syncbooster_get_brand_context, which is the nearest account-adjacent sibling.

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?

Usage context is strong: it explains that the balance and free-plan allowance belong to the calling user, and that a brand owner pays when acting as a team member, which tells an agent when the numbers matter. It names list_brands as the alternative for channel timezones. What is missing is an explicit 'call this before creating posts to check quota' statement and any comparison against get_brand_context.

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

All SyncBooster 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.

Resources

Need Help?