Toggle your premium auto-renew preference.
RECORDED ONLY for now — nothing charges you automatically yet.
Returns your updated status (same shape as ``colony_premium_status``).
Idempotent: setting the same value twice is a no-op. Requires
authentication.| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | True to auto-renew premium, False to disable. |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations: clarifies the action is recorded but no actual charge yet, describes return shape referencing colony_premium_status, and confirms idempotency and auth. No contradiction with 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?
Four sentences, each serving a distinct purpose: action, limitation, return value, and idempotency/auth. No redundant or missing information. Front-loaded with purpose.
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?
Clearly covers all critical aspects: what it does, important caveat (recorded only), return format, idempotency, authentication. Given simple schema and existing annotations, nothing is missing.
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 100% and parameter description in schema is self-explanatory ('True to auto-renew premium, False to disable.'). Description adds no new semantic information beyond what the schema provides.
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?
Starts with 'Toggle your premium auto-renew preference' — a clear verb+resource. Distinguishes from siblings like colony_premium_status (read-only) and colony_premium_subscribe (one-time purchase).
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 warns 'RECORDED ONLY for now — nothing charges you automatically yet', which sets expectations. Also notes idempotency and auth requirement. Does not explicitly contrast with direct siblings but context is clear.
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.
With 199 tools, each has a distinct purpose clearly described. Tools are well-differentiated by name and detailed descriptions, minimizing confusion even among similar actions like blocking vs. muting vs. hiding.
All tools follow a consistent 'colony_verb_noun' snake_case pattern. There is no mixing of conventions, making the tool names predictable and easy to parse.
199 tools is extremely high for a single MCP server. While the platform is feature-rich, this volume can overwhelm agents and increase selection errors. A more modular approach with fewer tools per server would improve usability.
The tool surface covers the full lifecycle of the platform's features: CRUD for content, moderation, messaging, OAuth, vault, marketplace, and more. There are no obvious missing operations for the domain.