List all planned services with current vote counts. Returns JSON array: [{ slug, name, description, votes }], sorted by votes descending. No payment required — this is a free discovery tool. Use the slug values with vote_on_service to cast votes. This tool is idempotent and safe to call repeatedly.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds that it returns a sorted JSON array with specific fields, and that it's safe to call repeatedly, providing useful behavioral context beyond 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?
Extremely concise: three sentences that front-load the purpose, then detail output and usage guidance. Every sentence 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?
Given no parameters and no output schema, the description fully specifies the return format and behavior. No gaps remain for an agent to select and invoke this tool 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?
No parameters exist, so baseline is 4. Description adds value by explaining the output format and sorting, which helps an agent understand what the tool returns without needing parameter details.
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?
Description uses specific verb 'List' and resource 'planned services' with current vote counts. It distinguishes from sibling tools like vote_on_service by clarifying this is for viewing, not voting.
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 no payment required, it's a free discovery tool, and directs to use the slug values with vote_on_service for casting votes. This clearly explains when to use this tool versus alternatives.
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 have distinct purposes, but there is some overlap, especially among call tools (ai_call, place_call, open_voice_bridge) and image generation/editing tools (generate_image, edit_image, animate_image). Descriptions help differentiate, but an agent might still select the wrong one.
The vast majority of tools follow a verb_noun pattern (e.g., generate_image, send_sms). A few exceptions exist (await_result, check_job_status, epub_to_audiobook) but the overall pattern is strong and predictable.
With 50 tools, the server is very extensive. While each tool earns its place given the broad scope of AI services, the count feels high and could overwhelm agents, making selection less efficient.
The tool surface is remarkably comprehensive, covering generation, editing, conversion, communication, async management, payments, and error handling. There are no obvious gaps for the stated Bitcoin-powered AI toolkit purpose.
