GoodSender

Get Post

get_post

Read-onlyIdempotent

Get one post by id, including markdown body.

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": {
      "PostID": "<PostID>"
    },
    "name": "get_post"
  }
}

Input Schema

Name	Required	Description	Default
`PostID`	Yes	Post id.

Output Schema

Name	Required	Description
`Slug`	Yes	URL slug.
`Tags`	Yes	Tags.
`Title`	Yes	Visible post headline; also the search/social title fallback when SEO Title is empty.
`Author`	Yes	Author display name if set.
`PostID`	Yes	Post id.
`Status`	Yes	draft or published.
`Summary`	Yes	Human-facing lede; also the word-aware metadata-description fallback when Description is empty.
`Markdown`	Yes	Markdown body.
`SEOTitle`	Yes	Stored optional search/social title override, or empty when Title supplies the fallback.
`AuthorURL`	Yes	Author URL if set.
`CreatedAt`	Yes	ISO-8601 created time.
`UpdatedAt`	Yes	ISO-8601 updated time.
`Categories`	Yes	Categories.
`Provenance`	Yes	Agent attribution, absent on a human-authored post.
`Description`	Yes	Stored optional search/social description override, or empty when the word-aware Summary fallback supplies metadata.
`PublishedAt`	Yes	ISO-8601 publish time if set.
`CoverImageAlt`	Yes	Cover image alt text, or empty when unset. (FR-020)
`CoverImageURL`	Yes	Cover image URL, or empty when unset. Rendered on the post page, card, social metadata, and in the newsletter email - distinct from any image inside Markdown. CoverImageAlt describes it.
`AuthorAvatarURL`	Yes	Author photo URL if set — shown beside the byline and as the author's image in structured data.
`LastBroadcastAt`	Yes	ISO-8601 broadcast time if set.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description's only added behavioral value is that the returned post includes its markdown body; it says nothing about behavior for a missing/invalid id.

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?

A single short sentence, front-loaded with the verb and scope, with zero filler.

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?

With an output schema present, return values need not be explained, and annotations carry the safety and idempotency profile. The description covers what an agent needs to call it, though a pointer to how a PostID is obtained would make it complete for a multi-tool post workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema coverage including type, length bounds and required status, so the schema does the heavy lifting. The phrase "by id" aligns with PostID but adds no format or sourcing guidance beyond it — baseline 3.

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?

States a specific verb and resource ("Get one post by id") and adds the notable scope detail that the markdown body is included, which separates it from list_posts and get_post_distribution. It does not name a sibling explicitly, so it falls short of a 5.

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?

Usage is only implied: "by id" signals this is the single-item retrieve versus the list_* siblings, but there is no explicit when-to-use statement, no prerequisite (e.g., needing an existing PostID from list_posts), and no named alternative.

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

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