PostOnce

delete_account

Destructive

Removes PostOnce access to an owned social account. The account is disconnected with its credentials cleared (the response returns deleted=false and disconnected=true); its posts and history are kept, and reconnecting the same account restores posting. Farcaster, Nostr, and Telegram records are also disabled. Farcaster signer revocation requires a separate provider step; Nostr remote-signer logout is best effort; @PostOnceBot leaves a Telegram channel on a best-effort basis when no other PostOnce account uses it. This does not delete published social content.

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": {
      "id": "<id>"
    },
    "name": "delete_account"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`idempotency_key`	No

Output Schema

Name	Required	Description
`body`	No	Upstream error details, when available.
`code`	No	Error code when the tool result has isError=true.
`data`	No	Present on successful results; omitted on tool errors.
`meta`	No
`status`	No
`message`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With destructiveHint=true already declared, the description adds substantial real behavior: credentials are cleared, the response returns deleted=false and disconnected=true, posts and history persist, and provider-specific side effects are disclosed with their reliability (Farcaster signer revocation requires a separate step, Nostr logout is best effort, @PostOnceBot leaves Telegram channels best effort). The only shortfall is no mention of auth requirements or error behavior, but the destructive-vs-soft-delete nuance is well covered.

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?

The key distinction (access removed, data kept) is front-loaded in the first two sentences, and the provider-specific caveats follow in a logical order. The closing line about not deleting published social content partially restates the earlier 'posts and history are kept' point, and the Telegram clause is dense, but overall little is wasted.

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?

For a destructive disconnect operation with an output schema already present, the description covers reversibility, side effects, and per-provider limitations thoroughly. The remaining gap is solely around the two input parameters, which the description does nothing to explain.

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 0% for both parameters. The description never states that 'id' is the social account identifier or what 'idempotency_key' does for a retried delete call, so an agent gets no help distinguishing which identifier to supply or how retries behave.

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 opens with a specific verb and resource: 'Removes PostOnce access to an owned social account.' It immediately clarifies that this is an access revocation rather than a data deletion, which distinguishes it from any hard-delete interpretation and from siblings like delete_workflow.

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

Usage Guidelines3/5

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

The description implicitly defines the use case by explaining that posts and history are kept and that reconnecting restores posting, which tells an agent this is the reversible option. However, it never names an alternative tool (e.g., list_accounts to obtain the id) or states explicit conditions for choosing this over other account operations.

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

All PostOnce 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?