Skip to main content
Glama
markaestro

Markaestro

Official

Mark a post as posted

mark_post_posted

Record a manual-reminder or TikTok-inbox post as published after you post it yourself, moving it from platform_action_required. No content is sent to any platform.

Instructions

Record that a person has posted a manual-reminder or TikTok-inbox post natively, which moves it from platform_action_required to published. Only for posts in platform_action_required that the user has already posted themselves. Nothing is sent to any platform.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
postIdYes
externalUrlNoLink to the live post, if the user has it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.3

TDQS

A4.1/5.0
Behavior4/5

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

The annotations already disclose that this is a non-read-only, non-destructive, closed-world, non-idempotent operation. The description adds useful behavioral context beyond that: it records a state transition and explicitly says nothing is sent to any platform, which clarifies the lack of external side effects.

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 short sentences, front-loaded with the core action and state transition, then the required precondition and the key side-effect clarification. No wasted text.

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 simple state-transition tool with annotations covering safety and no output schema, the description is nearly complete: it explains the action, eligibility condition, and lack of platform delivery. The main gap is that postId remains undocumented in both the description and the schema.

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

Parameters2/5

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

Schema description coverage is only 50% because postId has no schema description. The tool description does not explain either parameter: it does not clarify that postId identifies the post to update, nor does it add meaning for externalUrl beyond the schema's own description.

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?

The description names a specific verb ('Record'), the resource ('post'), and a precise state transition from platform_action_required to published. It clearly distinguishes this from publish_post or update_post by limiting it to manual-reminder or TikTok-inbox posts the user already posted natively.

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?

It gives clear when-to-use conditions: only for posts currently in platform_action_required and only when the user has already posted them. It does not explicitly name alternative tools to use in other cases, but the preconditions are specific enough to guide selection.

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