Skip to main content
Glama

Draft the posts in my plan

draft_my_planned_posts
Read-only

Write every post in this week's post plan as a draft, in the user's own voice, saved to their brain as a note per post and linked to the plan. Posts that already have a draft are left as they are. Use for 'write the posts in my plan', 'draft this week's posts', 'write them all'. For one post from finished work that is not on a plan, use the restate skill instead. Nothing is posted to LinkedIn: the user copies the draft and posts it. error no_plan means there is no plan this week, so offer to make one first. Link each draft as subject and say they can edit anything, then end with See your week, the page where they can read, copy and schedule each one. When in_brand_brief is true, do not link the drafts or that page: say each one arrives on Your day on its morning.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior1/5

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

The description states the tool writes drafts and saves them as notes in the user's brain, which modifies state, while the annotations declare readOnlyHint=true ('the tool does not modify its environment'). This is a direct contradiction of the safety profile an agent would rely on when deciding whether to invoke it. Annotation Contradiction flagged.

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-loaded with the core action and idempotency rule, then triggers, the sibling alternative, and output formatting. It is longer than most definitions, but each clause carries an instruction the agent must follow (error handling, link syntax, brand-brief exception) rather than padding.

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 a no-parameter, no-output-schema tool, the description covers the mutation semantics ('left as they are'), the no_plan error path, the fact that nothing is posted externally, and the two output-formatting variants (normal vs. in_brand_brief). Nothing needed to invoke or render the result 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?

The tool takes zero parameters and the schema is empty at 100% coverage, so per the rubric the baseline is 4. There is nothing parameter-level the description could add beyond the implicit 'this week' scoping, which it does state.

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 opening sentence names a specific verb+resource+scope: 'Write every post in this week's post plan as a draft... saved to their brain as a note per post and linked to the plan.' It is clearly distinguishable from siblings like get_my_plan (read the plan) and plan_generation (create the plan).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives literal trigger phrases ('write the posts in my plan', 'draft this week's posts'), names the alternative for the adjacent case ('For one post from finished work that is not on a plan, use the restate skill instead'), and routes the no_plan error ('offer to make one first'). When-to-use and when-not-to-use are both explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.