Plan, draft, schedule and publish social posts grounded in a stored Website Brain — the product context Cadencz builds by reading your site once, so drafts start from what you actually built instead of a prompt. 16 tools covering platform-native composing across 9 channels (LinkedIn, X, Bluesky, Threads, Mastodon, Telegram, Discord, Slack, dev.to), weekly planning, scheduling and analytics. Nothing publishes without human approval.
Scored across 14 tools
Most tools target distinct resources and actions (compose vs schedule vs publish vs cancel vs analytics). The main overlap is between compose_post and plan_week (both generate drafts) and between approve_plan_item and schedule_post (both result in a post being scheduled), but the descriptions clarify the plan-vs-ad-hoc distinction well enough.
All tools use consistent snake_case verb_noun phrasing, with a clean get_*/list_* split for read operations (get_analytics, get_current_plan, list_brains, list_channels) and clear action verbs elsewhere (compose_post, schedule_post, publish_now).
14 tools is well-scoped for a social media planning assistant covering the full plan-compose-schedule-publish loop plus supporting reads (brains, channels, workspaces, usage, analytics). No obvious redundancy.
The lifecycle from planning through publishing and cancellation is covered, with analytics and allowance checks. Minor gaps: no way to edit or delete a draft/variant, and variant_id is referenced but no tool lists or regenerates variants.
Approve a post from this week's plan, which schedules it for its planned time.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description adds the causal side effect that approving schedules the post at its planned time. It does not disclose what happens on re-approval, whether approval is reversible via cancel_scheduled_post, or behavior when the planned time has already passed.
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?
One compact sentence that front-loads the action and its consequence. No filler, though the brevity is partly why the parameter and edge-case gaps remain.
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 state-mutating scheduling tool with annotations covering the safety profile and no output schema, the description covers the core effect adequately. It still leaves the key operational question unanswered: where item_id comes from and what result the approval produces.
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 single required item_id is undocumented in both schema and description. The phrase 'a post from this week's plan' only obliquely hints that item_id is a plan-item identifier; it never says to source it from get_current_plan or describes its format.
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 verb (approve) and resource (a post from this week's plan) plus the effect (schedules it for its planned time). It is distinguishable from publish_now and schedule_post by the 'from this week's plan' scoping, though it never names those siblings to make the boundary explicit.
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 phrase 'from this week's plan' implies the tool applies to items already in the plan, which is useful context. However, it never says when to choose this over schedule_post or publish_now, nor that the item must first exist in the plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a scheduled post so it does not go out; it goes back to being a draft.
| Name | Required | Description | Default |
|---|---|---|---|
| variant_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, so the mutation profile is known. The description adds genuinely new behavioral context: the post is not deleted but reverts to draft, which tells the agent the action is reversible and the item still exists afterward.
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 efficient sentence, front-loaded with the action and followed by the outcome. No wasted words.
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 one-parameter tool with no output schema, the state-transition outcome is covered, but the agent gets no information about the required variant_id or what errors occur if the post isn't in a scheduled state. Adequate but with a clear gap around the sole input.
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?
There is one required parameter, variant_id, with 0% schema description coverage, and the description never mentions it or explains what a variant is. With low coverage the description is expected to compensate, and it does not.
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 verb ('cancel') and resource ('scheduled post') plus the outcome ('goes back to being a draft'). It does not explicitly differentiate itself from siblings like publish_now or schedule_post, but the action is unambiguous.
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 when-to-use or when-not guidance; the agent must infer that this is the inverse of schedule_post/publish_now. The description explains the consequence but never states the conditions or alternatives for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write one social media post for a platform (LinkedIn, X, Threads, Bluesky…) from an idea, grounded in the Brain — what Cadencz knows about the business — and in the person's own voice (the workspace's Brain, unless brain_id names another). The post is saved as a draft in Cadencz; nothing is published. Draws one AI generation.
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | ||
| brain_id | No | ||
| platform | No | x |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, non-open-world. The description adds valuable context beyond that: the operation saves a draft rather than publishing, grounds output in the workspace Brain unless brain_id overrides, and consumes one AI generation. These side-effect and cost disclosures are useful for an agent, though error handling and draft lifecycle details are absent.
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?
Front-loaded with the core action and scoped detail in two sentences. The parentheticals add useful context but could be trimmed slightly; overall it is efficient and every sentence contributes something material.
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 a 3-parameter write tool with no output schema and rich annotations, the description covers the essential job, the draft-only side effect, the Brain grounding rule, and AI cost. It leaves the return value (e.g., draft identifier) unstated, but that is a minor omission given the lack of an output schema.
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%, so the description carries the burden. It explains brain_id semantics well (defaults to the workspace's Brain unless another is named) and gives the platform parameter meaning with examples. It does not restate the full enum, mention the default 'x', or describe the idea parameter beyond 'from an idea', leaving some gaps.
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 verb ('Write one social media post'), names the resource and platform scope, and explicitly distinguishes itself from publishing tools by stating the post is saved as a draft and nothing is published. An agent can distinguish this from publish_now and schedule_post without opening any schema.
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?
Clear context: use this to generate a single draft post grounded in the Brain, and it will not publish. It implies when not to use it (anything requiring publication), but stops short of explicitly naming alternatives like publish_now or schedule_post. No prerequisites or exclusions are stated beyond the draft-only nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report how the person's published social posts performed — likes, replies, reposts and other engagement per platform over the last N days (default 30).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; openWorldHint=false also sets scope. The description adds that data is limited to the person's own published posts and to a bounded recent window, but it omits the 90-day ceiling on the window and any statement about aggregation or freshness.
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?
One front-loaded sentence that states the subject, the metrics, the scope and the default window with no filler.
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?
With one optional parameter, read-only annotations and no output schema, the description covers what an agent needs to invoke it and know what it reports. Only minor gaps remain (parameter bounds, aggregation semantics).
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%, so the description must carry meaning — and it does supply the key value the schema lacks: the default of 30 days and the semantic of 'last N days'. It does not note the 1–90 bounds, so it only partially compensates.
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?
Names a specific verb (Report) and resource (the person's published social posts' performance), and enumerates the metrics returned (likes, replies, reposts, engagement) plus per-platform granularity. No sibling tool overlaps this role, so an agent can select it without ambiguity.
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 time-window phrasing ('over the last N days (default 30)') implies the usage context, but there is no explicit when-to-use/when-not guidance and no named alternative among the many post-related siblings. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show this week's social media content plan in Cadencz: each planned post with its theme, platform, day and status. Use after plan_week, or when asked what is planned this week.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds the shape of the result (per-post theme/platform/day/status), which is behavioral context beyond the annotations.
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, front-loaded with what is returned and followed by the trigger condition. No filler, no restatement of the title.
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?
With no input parameters, no output schema, and annotations covering safety, the description supplies exactly what is missing: the returned fields and the workflow position after plan_week. An agent has everything needed to call and interpret it.
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?
The tool takes zero parameters, so the baseline is 4. The description instead clarifies the output fields an agent can expect, which is the only semantic gap worth filling here.
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?
Specific verb and resource: shows this week's social media content plan, and enumerates the returned fields (theme, platform, day, status). It is clear what the tool produces, though it does not explicitly distinguish itself from list_scheduled_posts or get_plan_usage, which are the nearest siblings.
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?
Gives a concrete trigger: 'Use after plan_week, or when asked what is planned this week.' That covers both a chained workflow and a natural user request. It stops short of stating when NOT to use it (e.g., versus listing scheduled posts or checking plan usage).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show how much of the workspace's allowance is used this period (posts written, AI generations, scheduled posts) and what is left.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare a safe, read-only, closed-world operation, so the description only needs to add context. It usefully discloses the exact usage dimensions reported (posts written, AI generations, scheduled posts) and that remaining allowance is included, which is valuable since no output schema exists.
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 contains no filler. It efficiently covers the metric scope and the 'what is left' outcome without unnecessary detail.
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 zero-parameter, read-only tool without an output schema, the description sufficiently explains what is returned: usage against allowance plus remaining amounts. It does not specify response formatting, but that is a minor gap given the tool's simplicity.
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?
With zero parameters, the baseline is 4. The description cannot add parameter meaning, and none is needed for this tool.
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 verb ('Show'), resource ('workspace's allowance'), scope ('this period'), and the exact metrics covered, so an agent knows it reports usage/quota rather than plan details. It does not explicitly distinguish itself from nearby tools such as get_analytics or get_current_plan, which prevents a perfect score.
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?
There is no explicit when-to-use guidance, no named alternatives, and no exclusions. The purpose implies it is used when checking allowance consumption, but the description provides no routing logic against siblings like get_analytics or get_current_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Brains in this workspace. A Brain is what Cadencz learned about a business from its website: product, audience, positioning and voice. Usually there is one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is fully covered by structured data. The description adds useful context that a workspace usually has a single Brain, but does not describe return shape or pagination behavior.
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 short sentences, front-loaded with the action, the second sentence efficiently defining the domain object. No filler.
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 zero-param read-only list tool with full annotation coverage and no output schema, the description is adequate. It defines the resource and its typical cardinality, which is what an agent needs to decide whether to call it.
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?
Zero parameters, so baseline is 4. The description correctly implies no filtering arguments are needed, and nothing is misrepresented.
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 verb and resource ('List the Brains'), and adds a domain definition of what a Brain is. An agent knows exactly what this returns and how it differs from siblings like list_channels or list_workspaces.
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 implies a listing context and clarifies cardinality ('Usually there is one'), but never states when to call this vs. list_workspaces or query_brain, nor that it takes no arguments to scope the workspace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the social media accounts connected to Cadencz (X, LinkedIn, Threads, Bluesky and others). Use before scheduling or publishing, or when asked which accounts are connected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds the platform scope but says nothing about return shape, pagination, or auth requirements. With annotations carrying the safety profile, this is adequate rather than rich.
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 tight sentences: the first identifies the resource and scope, the second front-loads the usage trigger. No filler or repetition of the title.
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 zero-parameter read-only lister with no output schema and full annotation coverage, the description is nearly complete. A minor gap is that it never hints at what the returned accounts contain (e.g. identifiers needed downstream by schedule_post or publish_now).
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?
The tool takes zero parameters, so the baseline is 4. There is no parameter semantics to describe, and the description does not misrepresent any inputs.
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 verb and resource: 'List the social media accounts connected to Cadencz', and even enumerates the covered platforms (X, LinkedIn, Threads, Bluesky). This cleanly separates it from sibling listers like list_workspaces and list_brains.
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?
Gives explicit trigger conditions: 'Use before scheduling or publishing, or when asked which accounts are connected.' It sets clear context but does not name an alternative tool or state exclusions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List posts scheduled to go out on social media in the coming days (default 7), with platform and time. Use when asked what is scheduled, queued or going out soon.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a useful behavioral detail – the default 7-day window – but says nothing about pagination, result caps, or what happens when nothing is scheduled.
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 tight sentences: what it returns first, when to use it second. No filler, no redundancy, front-loaded with the actionable scope.
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 read-only list tool with one optional param and no output schema, the description covers the default window, the return content (platform, time), and the use case. Missing only edge-case behavior (empty results, upper bound), which is minor here.
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 compensate. It does disclose the default (7 days), which is the most important semantic for the optional 'days' parameter, but omits the range bounds (1–60) that the schema enforces. Partial compensation for a single optional param.
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 verb (List) and resource (posts scheduled to go out on social media) plus scope (coming days, default 7) and returned fields (platform, time). An agent can distinguish it from cancel_scheduled_post or schedule_post without opening schemas, though no sibling is named explicitly.
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?
Gives concrete trigger phrasing: 'Use when asked what is scheduled, queued or going out soon.' That maps natural user intent to this tool. It does not name alternatives or exclusions (e.g., versus get_current_plan or get_plan_usage), which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Cadencz workspaces (businesses or brands) the person can use. Only needed when they have more than one; every other tool defaults to the current workspace.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond the annotations: that workspaces are per-person and that all other tools implicitly operate on the current workspace, which affects whether calling this is necessary at all.
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, zero filler, with the conditional need front-loaded ahead of the defaulting behavior. Every clause earns its place.
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 zero-parameter, non-destructive read tool with no output schema, the description supplies everything required: what it returns (the person's workspaces), and when it is warranted versus the implicit default.
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?
Zero parameters, so schema coverage is trivially complete and there is nothing for the description to disambiguate. Baseline of 4 applies for a no-argument tool.
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 verb (List) and resource (workspaces) and immediately clarifies what a workspace is ('businesses or brands') plus the scope ('the person can use'). An agent can distinguish this from sibling list_brains and list_channels without opening a schema.
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?
Explicitly states when it is needed ('Only needed when they have more than one') and explains the default behavior of all other tools ('every other tool defaults to the current workspace'), which is exactly the when/when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan this week's social media posts: Cadencz writes a batch of drafts across the connected platforms from the Brain and the week's goal, for the person to review in Plan my week. Nothing is published. Each planned post draws from the shared AI-generation allowance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so mutation/safety is partially covered. The description adds meaningful non-obvious behavior: nothing is published, drafts are queued for human review, and each post consumes the shared AI-generation allowance (quota awareness). It does not state limits on batch size or error behavior.
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?
Three sentences, front-loaded with the action and scope, then the review outcome, then the quota caveat. Every sentence carries distinct information with no repetition of the title.
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 zero-parameter, no-output-schema tool, the description covers the action, the non-publishing guarantee, the review surface, and quota cost. The only gap is how the week's goal is supplied or what the agent should do next (e.g., point to get_current_plan/approve_plan_item).
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?
The tool takes zero parameters, so there is no schema surface for the description to compensate for; baseline is 4. No misleading parameter claims are made.
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?
Specific verb (plan/write drafts) plus resource (this week's social media posts) and scope (batch across connected platforms, sourced from the Brain and the week's goal). It is clearly distinguishable from siblings like compose_post and schedule_post, which act on individual posts.
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 implies usage (generate a batch of reviewable drafts for the week) and states the output destination ('Plan my week'), but never explicitly says when to choose this over compose_post or schedule_post, nor any preconditions such as needing a connected channel or Brain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a draft post to its social network right now. Public and irreversible: ask the person to confirm first, then call with confirm: true.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | ||
| variant_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the action is public and irreversible, and it requires explicit human confirmation.
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 tight sentences with zero waste. The irreversible/public warning and confirmation requirement are front-loaded, making the critical operational guidance immediately visible.
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 two-parameter action with no output schema and annotations covering safety, the description is nearly complete: it covers timing, public visibility, irreversibility, and the confirmation workflow. The main remaining gap is explaining variant_id, but that is a minor omission given the overall clarity.
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% for two required parameters. The description explains the confirm parameter's required value, but it does not explain what variant_id identifies or how to obtain it, so the description only partially compensates for the schema 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 verb (publish), resource (draft post), target (its social network), and timing (right now). It clearly distinguishes the immediate action from siblings like schedule_post, compose_post, and cancel_scheduled_post.
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?
It gives a clear precondition: ask the person to confirm first, then call with confirm: true. The immediate timing is also explicit, though it does not name the alternative scheduling tool by name or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer questions about the person's own business from what Cadencz knows about it — its product, audience, positioning, competitors and brand voice, learned from their website. Use this whenever they ask what Cadencz knows about their business, product or customers, and before writing posts. Defaults to the workspace's Brain when brain_id is omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| brain_id | No | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful context beyond that: the knowledge is 'learned from their website' and brain_id 'defaults to the workspace's Brain when omitted'. No return-shape or staleness details, but solid for a read tool.
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, front-loaded with the verb and knowledge source, then the usage trigger, then the default behavior. Little waste, though the enumeration of knowledge categories is slightly padded.
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 read-only two-parameter tool with no output schema, the definition covers purpose, usage timing, data provenance and default argument behavior. Nothing critical is missing, though details on what the answer looks like or its freshness are absent.
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 carry the load. It does explain the brain_id default ('defaults to the workspace's Brain when brain_id is omitted'), which is genuinely useful, but the required 'question' parameter gets no clarification and no format or scope guidance is given.
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 verb ('answer questions') and resource ('what Cadencz knows about it'), and enumerates the knowledge domain (product, audience, positioning, competitors, brand voice). An agent can distinguish it from sibling listers like list_brains, though the description never explicitly contrasts with list_brains.
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?
Gives explicit triggers: 'whenever they ask what Cadencz knows about their business, product or customers' and 'before writing posts', which implicitly routes ahead of compose_post. It stops short of naming alternatives or stating when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a draft post (variant_id from compose_post or the plan) to publish at a given time. Confirm the time with the person first.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | ||
| variant_id | Yes | ||
| scheduled_at | Yes | ISO 8601 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so safety characteristics are covered. The description adds a useful behavioral caution about confirming the time with a person, but it does not disclose timezone handling, what happens to past times, or whether the post can be cancelled afterward.
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 short sentences with no wasted words. The primary action is front-loaded, and the confirmation caution follows immediately.
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 scheduling mutation with no output schema, the description gives the essential source for variant_id and a time-confirmation requirement. It is incomplete on timezone semantics and does not explain the expected outcome of scheduling, such as whether the post becomes visible in list_scheduled_posts.
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?
With only 33% schema description coverage, the description partially compensates by explaining that variant_id comes from compose_post or the plan. However, it does not clarify the timezone parameter or how scheduled_at and timezone interact, leaving a significant 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 uses a specific verb and resource: 'Schedule a draft post ... to publish at a given time.' It also identifies variant_id as coming from compose_post or the plan, but it does not explicitly distinguish this tool from siblings such as publish_now or cancel_scheduled_post.
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?
It gives clear context for when to use the tool: scheduling a draft post for future publication, after compose_post or a plan. It also adds an operational caution, 'Confirm the time with the person first,' but does not state when not to use it or name alternative tools like publish_now.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compose_post2 fields changedInput schema / properties / platform / defaultAdded value: +"x"Input schema / properties / platform / enumAdded value: +[
+ "bluesky",
+ "devto",
+ "discord",
+ "facebook",
+ "farcaster",
+ "linkedin",
+ "mastodon",
+ "pinterest",
+ "reddit",
+ "slack",
+ "telegram",
+ "threads",
+ "wordpress",
+ "x"
+]approve_plan_itemcancel_scheduled_postcompose_postget_analyticsget_current_planget_plan_usagelist_brainslist_channelslist_scheduled_postslist_workspacesplan_weekpublish_nowquery_brainschedule_post
Add one secure layer between your agents and this server.