Publish a prepared trainer social post after source URL validation. Requires SOCIAL_POSTS_MCP_WRITE_TOKEN as write_token.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| write_token | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the disclosure burden and covers meaningful behavioral ground: it requires an auth token and performs source URL validation before publishing. It does not detail side effects such as visibility or irreversibility, but the disclosed auth and sequencing exceed a bare action statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, and the key action plus required condition are front-loaded. Every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema, the description is close to sufficient, but the undefined slug and lack of failure behavior/error cases make it only minimally viable for a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It correctly maps write_token to SOCIAL_POSTS_MCP_WRITE_TOKEN, but leaves slug undefined; the agent has to guess what value identifies the prepared post. This is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Publish') on a specific resource ('prepared trainer social post') and adds a validation step. The word 'prepared' clearly separates it from sibling create_social_post_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this to publish a post that has already been prepared and after source URL validation. It does not explicitly name alternatives or state when not to use the tool, but the context is sufficient to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The lesson tools are cleanly separated: request creation, options listing, availability search, and general info all target different resources/actions. The main confusion risk is in the social pipeline, where create_social_post and publish_social_post can both look like the way to get a post live, and the two upsert tools are behaviorally similar even though their targets differ.
Most names follow a snake_case verb_noun pattern: create_lesson_request, list_social_posts, publish_social_post, search_lesson_availability, upsert_social_channel. However, voice_school_info breaks the verb pattern, and create_social_post is actually a create-or-update operation while other create/update tools use the upsert prefix, creating a minor semantic inconsistency.
At nine tools the absolute count is reasonable and within the ideal 3-15 range. However, five of the nine tools target social media management, which feels like a second domain bolted onto a lesson-booking server, so the set is slightly overbroad for its stated purpose.
The lesson-request flow covers info, options, availability, and request creation, but then stops; there is no way to list, update, or cancel requests, though creation is intentionally request-first. The social-post flow supports create/update, publish, and list, but only lists published posts and has no delete/unpublish or draft-listing operation, leaving lifecycle coverage incomplete.