list_collectionsList the collections (piles) the user already groups their scripts into, with counts. Call it before grouping anything so you reuse their existing names instead of inventing near-duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns collections 'with counts' and emphasizes the existing groupings, which helps the agent understand what data to expect 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?
The description is two sentences, with the primary action stated first and a concise usage directive second. Every word adds value, and there is no redundancy or 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 zero parameters, rich annotations, and a clear description that mentions return value (counts) and purpose, the tool is fully contextualized. The sibling list provides further differentiation, but the description alone is sufficient for an agent to invoke it correctly.
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 input schema has zero parameters and 100% coverage, so there are no parameter semantics to explain. The baseline for 0-param tools is 4, and the description does not need to add parameter details. It appropriately focuses on purpose and usage.
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 clearly states the tool lists collections (piles) with counts, specifying both the resource (collections) and the scope (user's existing script groups). This distinguishes it from sibling tools like list_planned_scripts, which focus on scripts themselves rather than their groupings.
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 explicitly instructs to call this tool 'before grouping anything' to reuse existing names, providing a clear when-to-use directive and rationale. This prevents duplicate collection names and is a strong usage guideline.
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.
Each tool targets a distinct resource-action pair: planning (add, edit, archive, list, get, reorder), teleprompter delivery (send), and scheduled posts (list, cancel, retry). Even closely named tools like get_planned_scripts vs list_planned_scripts are clearly separated by metadata vs full-text purpose. No two tools overlap in function.
Names are uniformly snake_case and follow a verb_noun pattern, but there is slight inconsistency: 'add_scripts_to_plan' uses a prepositional phrase while similar operations use past-participle adjectives ('edit_planned_scripts', 'archive_planned_scripts'). Verb choices like list vs get are consistent with their functions. Minor deviations prevent a perfect score but the pattern is highly predictable.
12 tools is well within the ideal 3-15 range for a focused domain. Each tool covers a clear need for content planning and teleprompter delivery without bloat or missing essentials. The count feels appropriately scoped for the server's purpose.
The toolset offers full lifecycle coverage for content plans (create, read, update, delete via archive, reorder) and scheduled posts (list, cancel, retry), with connected account listing for context. The only seemingly absent operation—permanent deletion—is intentionally excluded for safety. Read and write paths are complete, and the design prevents dead ends.