Set how much a growth marketing loop does on its own: review, one_click or autonomous. Requires the 'config' scope and Founder tier. Social and distribution channels never accept 'autonomous': they are review-and-post by a human.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| loop_type | Yes | The growth loop to configure, e.g. linkedin_post or geo_improvement. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false already indicating mutation, the description adds valuable behavioral context: the required scope and tier, and a critical constraint that social/distribution channels are always human-reviewed rather than autonomous. This goes beyond what annotations provide.
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 consists of exactly two sentences, each contributing distinct value: purpose, requirements, and an exception. It is tightly packed with no filler words, making it easy for an agent to parse.
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 two-parameter setter with no output schema, the description covers purpose, authentication, and channel-specific constraints. It does not define what each autonomy level does behaviorally in detail, but the enum names and the 'does on its own' context give sufficient guidance. A 5 would require explicit explanation of each level's effect.
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 describes loop_type with an example but does not describe the 'level' enum's semantics. The description compensates by enumerating the levels (review, one_click, autonomous) and explaining their high-level meaning, plus adding the social-channel restriction. This meaningfully augments the 50% schema coverage.
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 the specific verb 'Set' and the noun 'how much a growth marketing loop does on its own', clearly identifying the resource and action. It distinguishes from siblings like set_loop_cadence, which configures the schedule rather than autonomy.
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 states explicit prerequisites: requires the 'config' scope and Founder tier. It also provides a when-not condition by specifying that social and distribution channels never accept 'autonomous'. However, it does not explicitly name alternative tools, so it falls just 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.
Add one secure layer between your agents and this server.
Most tools follow a clear action+resource pattern (get_, list_, set_, ship_, etc.) with distinct purposes. A few boundaries could cause confusion, such as get_move vs get_output (both return drafts) and ship_move vs set_output_status (both mark things shipped), though descriptions mitigate this sufficiently.
The overwhelming majority use consistent snake_case verb_noun naming (list_feed, ship_move, get_visibility). The only outlier is 'whoami', a common convention but not verb_noun; otherwise the pattern is highly predictable.
At 41 tools, the surface is well over the 25-tool threshold for 'too many'. While the domain is broad, this volume places significant cognitive load on agents and suggests some consolidation or modularization could help.
Core workflows for moves and outputs are covered (create/list/get/update/ship/skip/undo). However, the tool descriptions reference 'approve_output' as the publishing action, yet that tool is absent from the list, leaving a dead end for channel distribution. There are also no tools for editing competitors or managing Memory pages beyond recording insights.