Add or update a social channel/group that trainer posts are attached to. Requires SOCIAL_POSTS_MCP_WRITE_TOKEN as write_token.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| slug | Yes | ||
| title | Yes | ||
| platform | Yes | ||
| is_active | No | ||
| coach_slug | Yes | ||
| description | No | ||
| write_token | Yes | ||
| channel_type | No | CHANNEL |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a write operation requiring SOCIAL_POSTS_MCP_WRITE_TOKEN, an important auth prerequisite not covered by annotations (none are provided). However, it does not explain conflict behavior, partial-update semantics, or consequences of changing slug/url, leaving some behavioral burden unmet.
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?
A single front-loaded sentence that names the operation and resource before the auth requirement, with no filler. Every phrase adds signal, and it is appropriately sized.
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?
Given the schema has no property descriptions and there are no annotations, the description covers only the core action plus one auth parameter. It omits sibling differentiation, required-field rationale, key/conflict semantics, and parameter details, so it is not complete enough for reliable invocation despite the output schema reducing the need to document return values.
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 description coverage is 0%, and the description only explains write_token. The meanings and relationships of coach_slug, platform, title, slug, url, is_active, description, and channel_type are left to inference from parameter names, which is insufficient for a nine-parameter upsert.
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?
States a specific action ('Add or update') and resource ('social channel/group') and ties it to trainer posts, so an agent knows what entity is being managed. However, it does not explicitly differentiate from the similarly named sibling upsert_trainer_social_link, so it stops short of a 5.
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?
No guidance on when to use this tool versus alternatives; it does not contrast with upsert_trainer_social_link or other sibling tools. The only usage hint is the required write_token, which is a prerequisite rather than a selection rule.
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.