Plot Speaks

Submit a story

submit_story

Destructive

Submits a finished Plot Speaks story for human review, credited to the name the writer chooses. Runs the format checks, a safety screen and a daily limit, then stores it; nothing is public until a person approves it. Returns a submission id and a one-time claim code for withdrawing or updating it. With replaces_id and claim_code, it replaces an earlier submission.

Input Schema

Name	Required	Description
`contact`	No	Optional: how the reviewer can reach the writer (email or handle). Seen only by the reviewer.
`story_md`	Yes	The full text of story.md
`claim_code`	No	Only to update an earlier submission: the claim code from its receipt
`secrets_md`	No	The full text of secrets.md (kept private on the server; mysteries need one)
`author_name`	Yes	The name credited publicly as "Written by" (2 to 60 characters; a pen name is fine). Checked by the reviewer with the story.
`replaces_id`	No	Only to update an earlier submission: its submission id
`email_when_approved`	No	Only on the account connector, and only if the writer said yes when you asked: "Would you like one email, to the Google address you signed in to Plot Speaks with, when a person approves this story? It's the only email Plot Speaks sends about it." Never set it without asking.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / email_when_approved

Added value: +{
+  "description": "Only on the account connector, and only if the writer said yes when you asked: \"Would you like one email, to the Google address you signed in to Plot Speaks with, when a person approves this story? It's the only email Plot Speaks sends about it.\" Never set it without asking.",
+  "type": "boolean"
+}

First observedOct 28, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes well past what the annotations declare: names the format checks, safety screen, daily limit, the pending-approval staging behavior, and the returned one-time claim code for withdrawal/updating. It never spells out what makes this destructive (e.g., that replacing overwrites the earlier submission irreversibly) or failure behavior when limits are hit, leaving some annotation-relevant context unstated.

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?

Three tightly packed sentences, front-loaded with the action and scope, then behavioral consequences, then the replacement variant. No filler.

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?

All seven parameters are documented in the schema, and the description fills in return values (submission id, one-time claim code) despite there being no output schema. Nothing material for a correct call is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that replaces_id and claim_code must be used together to replace a prior submission, and that the claim code also serves withdrawal/updating.

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?

Specific verb (submits) plus resource (a finished Plot Speaks story) with scope stated up front. It also distinguishes itself from write_story and review_story by noting human approval is required and that nothing is public yet.

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?

Clear about when to call it (finished story, credited to a chosen name) and when to use replaces_id/claim_code to update an earlier submission. It never names sibling alternatives like withdraw_submission or list_stories, so exclusions are implied rather than explicit.

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

All Plot Speaks 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?