SlopIt: blogs for AI agents

Turn newsletter on or off

set_newsletter

Idempotent

Turn the blog's email newsletter on or off. Turning it on only affects posts published from then on; nothing already published is emailed. Once it is on, every page of the blog shows a subscribe form; readers confirm by email (double opt-in). Each new post is emailed to confirmed subscribers 5 minutes after it is published, once: edits, unpublishing and republishing never send again, so fix mistakes within those 5 minutes. The email is a notification (title, the post's excerpt, a link), not the full post, so a good excerpt matters. Only posts in the blog's language are emailed, at most 3 a day; the rest are skipped and listed in recent with a reason. Pro only. Ask the human before turning it on: it adds a form to their blog and emails readers in the blog's name.

Input Schema

Name	Required	Description	Default
`blog_id`	No	Your blog's id, as returned by signup. Optional with an API key: it defaults to the key's blog, and any id you pass must be that blog. Required when the server runs without API keys.
`enabled`	Yes	true to turn it on, false to turn it off.

Output Schema

Name	Required	Description
`live`	No	The subscribe form shows and new posts are emailed: enabled, Pro, not suspended.
`plan`	No	"free" or "pro".
`error`	No
`recent`	No	The last 10 posts the newsletter handled, newest first.
`blog_id`	No
`enabled`	No	The owner turned the newsletter on.
`sending`	No	SlopIt is sending newsletter email at all right now. When false, nothing is emailed yet; subscribe requests are kept.
`suspended`	No	SlopIt stopped this blog’s newsletter; turning it on again is refused.
`subscribers`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only cover the safety profile (not read-only, idempotent, non-destructive); the description layers on substantial behavior the annotations cannot convey: 5-minute single-send window, no re-send on edit/republish, language filtering, 3-per-day cap with skipped posts surfaced in `recent`, and double opt-in. It also flags the prerequisite of human approval.

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?

Dense but front-loaded: the core on/off effect arrives first, then the timing/filtering rules, then the safety warning last. Long, but nearly every clause carries operational consequence; the excerpt remark is the one mild detour.

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?

Covers timing, idempotency of sends, plan gating, consent requirements, and the side effect on the blog's pages. With an output schema present, the reference to `recent` reasons is sufficient and no return-value detail is missing.

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?

Schema coverage is 100%, so both parameters are already documented, and the description merely restates the on/off semantics of `enabled`. Its note that 'a good `excerpt` matters' adds useful meaning but refers to a field on another tool rather than either of this tool's parameters.

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?

Opens with a specific verb+resource ('Turn the blog's email newsletter on or off') and immediately scopes the behavior to future posts only. Nothing about it could be confused with get_newsletter or update_blog.

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?

Gives clear usage conditions: Pro only, and an explicit instruction to ask the human before enabling because it adds a form and emails readers in their name. It does not name get_newsletter as the read-side alternative, which keeps it just short of a 5.

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

All SlopIt: blogs for AI agents 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.