Scripe

Posts — read

posts_read

Read-onlyIdempotent

posts_read — Scripe posts (LinkedIn posts and drafts: list and read, save the user's text, AI-write, edit, schedule, publish, media and team engagements): read operations. Call posts_read({ action: "", arguments: { …its arguments } }); describe_actions has an operation's full docs when its signature is not enough.

list_posts(projectId?: string, status?: oneOrMany<waitingProcessing|draft|waitingApproval|approved|rejected|published|scheduled|suggested>, statusCategory?: oneOrMany<suggested|draft|inProgress|review|scheduled|published>, statusId?: oneOrMany, delivery?: oneOrMany<not_scheduled|scheduled|due|missed|published>, review?: oneOrMany<not_requested|pending|approved|rejected>, dateFrom?: date, dateTo?: date, publishedFrom?: date, publishedTo?: date, q?: string, content?: preview|full|none, cursor?: string, limit?: int) — the LinkedIn posts and drafts in a Scripe project, newest first.
get_post(postId: string) — one Scripe post (a LinkedIn post or draft) by id — the full content, which list_posts only excerpts — including the media it will publish with — read that before attach_media_to_post, which is a full-state write — and the workspace…
list_post_statuses(projectId?: string) — a Scripe project's content pipeline: every kanban column (draft / inProgress / review / scheduled / published categories) with postCount, how many posts sit in it right now.
get_post_engagements(postId: string) — a Scripe post's team engagement timeline: the likes, comments and reposts queued to fire under OTHER brands' LinkedIn identities after the post goes live, plus availableActors — the workspace brands and company pages this post could…
get_draft_run(runId: string, waitSeconds?: int) — Poll a Scripe draft run: the posts Scripe is writing for planned ideas (draft_planned_posts), the visuals it puts on posts (add_post_media) and the team engagement it sets up (set_up_team_engagement) — status, post links, hooks, media.

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": {
      "action": "<action>"
    },
    "name": "posts_read"
  }
}

Input Schema

Name	Required	Description	Default
`action`	Yes	The operation.
`arguments`	No	Its arguments, as its signature names them.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real behavior: list_posts returns 'newest first', get_post returns the full content that list_posts only excerpts, get_draft_run is explicitly a poll with a waitSeconds bound, and get_post_engagements exposes availableActors. It is docked because several bullets trail off mid-sentence ('and the workspace…', 'this post could…'), so disclosed behavior is partially lost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The bulleted per-operation structure is front-loaded and scannable, but the opening parenthetical enumerates capabilities that belong to sibling write tools ('save the user's text, AI-write, edit, schedule, publish'), which is noise in a read-only definition. Multiple bullets are truncated with ellipses, so the text is both over-broad at the top and incomplete at the bottom.

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 five-action dispatcher with no output schema, the description does a solid job of explaining what each operation returns (newest-first lists, full content vs excerpt, kanban columns with postCount, engagement timeline with availableActors, poll status with post links). The truncated bullet endings leave a few return-value details unfinished, which is the main completeness gap.

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 100% schema coverage applies only to the two top-level fields; the real parameters live in the free-form `arguments` object, which the schema documents with nothing more than 'as its signature names them'. The description compensates well by listing each operation's parameters with types and full enum values (status, statusCategory, delivery, review, content), though it adds no per-parameter semantics beyond the names themselves.

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?

Opening sentence names the resource (Scripe posts: LinkedIn posts and drafts) and the scope (read operations), then enumerates five concrete operations with signatures, each with a one-line purpose. An agent can distinguish this from posts_write/posts_delete purely from the description, and can tell list_posts from get_post from list_post_statuses at a glance.

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?

Explicit routing is present: 'describe_actions has an operation's full docs when its signature is not enough' tells the agent where to go when an operation is underspecified, and get_post's entry states it must be read before attach_media_to_post because that is a full-state write. It does not, however, explicitly say when to use posts_read versus the sibling posts_write/posts_delete, leaving the read/write split implicit in the tool name.

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

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