hunchful

Post as what you run (draft or publish)

create_post

Write a post for something the person runs (a förening's, a company's, a community's, a creator or topic channel) — words, words with photos or a clip (media: ids from upload_media), a poll, or a challenge (a quiz question with the right answer; good for a quick förhör). Pick WHO it's from with as and WHO sees it with audience (everyone · followers · members = the home's Nyheter · team · subscribers — only what that channel offers the person; list_identities shows them). Only when they ask; write in their voice and the channel's language, never invent people, numbers or quotes. By default it's a DRAFT card in their Stream: "Publish" (or "Schedule") does it with one tap, through the channel's own moderation. It's published right away only if they turned on "May publish directly" for your app AND nobody under 18 can see the channel (youth and all-ages channels, a class's: always a draft). Either way it's labelled AI-made; a direct publish can be taken back for 24 h; photos are checked before anyone else sees them.

Input Schema

TableJSON Schema

Name	Required	Description
`as`	No	Which of what the person runs to act as — a key from list_personas, e.g. "forening:a1b2c3d4e5" or "channel:Xy12Ab34Cd", or its name, e.g. "Löparklubben". May be left out when only one fits.
`kind`	No	text (default), poll, or challenge (a question with one right answer).
`mode`	No	"publish" (default) publishes now only if the person turned on "May publish directly" for your app AND no one under 18 can see it — else it's a draft; "draft" always makes a draft they publish with one tap.
`text`	Yes	The post's words (≤ 1000 characters; with a poll or a challenge: an optional line above it), e.g. "Träningen i helgen flyttas till Ribersborg — samma tid."
`media`	No	Photos/clips from upload_media (1–10; 2+ make a carousel), with kind text — the words become the caption. Example: [{"mediaId": "Ab12Cd34Ef56Gh78", "alt": "Laget efter matchen"}]
`title`	No	A short name for the draft card (not part of the post), e.g. "Helgens träning".
`correct`	No	challenge: the right option, 0-based, e.g. 0.
`options`	No	poll / challenge: 2–4 different options, e.g. ["1252", "1350", "1523"].
`audience`	No	Who should see it: everyone, followers, members (the home's Nyheter — its members only), team, or subscribers. Leave out for the channel's usual. Example: "members"
`question`	No	poll / challenge: the question, ≤ 120 characters, e.g. "Vilket år grundades Stockholm?"
`publishAt`	No	When it should go out, 5 minutes to 30 days ahead, ISO 8601 with the person's UTC offset, e.g. 2026-10-09T08:00:00+02:00. Leave out for now.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`as`	Yes
`url`	Yes
`why`	Yes
`note`	Yes
`itemId`	Yes
`postId`	Yes
`status`	Yes
`undoUntil`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Far exceeds the annotations (readOnly=false, destructive=false): it discloses the draft-by-default card, the two conditions required for immediate publishing, youth/all-ages always-draft rule, AI-made labelling, 24 h retraction window, and pre-publication photo checks. These are exactly the side effects an agent must know before writing.

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?

Front-loads the purpose and the draft/publish consequence despite being a dense, parenthetical-heavy paragraph. Some content (publish-mode behavior) is duplicated between the description and the `mode` parameter, but almost every clause carries actionable constraints.

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?

For an 11-parameter, multi-variant tool with an output schema already available, the description covers authoring voice, audience scoping, moderation, scheduling and reversibility. Nothing an agent needs to call this correctly appears to be 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 already 100%, so the baseline is 3, but the description adds real meaning: media ids come from upload_media, `as` is a key from list_personas/list_identities, `audience` maps to concrete channel scopes, publishAt window is 5 min–30 days, and challenge's `correct` is the right option. Only minor gaps (no explicit poll vs challenge option-count guidance beyond schema enums).

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?

States a concrete verb+resource ("Write a post for something the person runs") and enumerates the post shapes it supports (text, media, poll, challenge) plus the persona/audience axes. An agent can distinguish it from edit_post, schedule_post and create_post_draft by the 'as/audience' framing, though the draft-default behavior does slightly overlap with create_post_draft.

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?

"Only when they ask" is an explicit usage constraint, and the description spells out the draft-vs-publish decision path and audience/identity prerequisites. It does not, however, name sibling alternatives such as create_post_draft or schedule_post, so the routing decision between near-identical tools is left to inference.

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

All hunchful tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.