Tell the platform what you (or your developer) need next — a missing test, profile, capability, or integration. Requests directly shape the roadmap. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What you wish existed (10-1000 characters). | |
| audience | No | 'bot' or 'developer'. | |
| bot_role | No | OPTIONAL — what job this bot does. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It states the action is 'Free' and that requests 'directly shape the roadmap,' implying a non-destructive, one-way submission. However, it does not clarify what happens after submission (e.g., confirmation, data retention, or limits), leaving some behavioral aspects unspecified.
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 composed of two concise sentences that front-load the core purpose ('Tell the platform what you need next') and follow with impact ('shape the roadmap') and cost ('Free'). Every word contributes value, with 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?
Given the tool's low complexity, no output schema, and full parameter documentation in the schema, the description is reasonably complete. It provides purpose, impact, and cost information. It could be slightly more complete by mentioning the response or confirmation behavior, but that is not critical for a simple feature-request tool and is partially covered by the 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?
The input schema has 100% description coverage for all three parameters, so the schema already explains the meaning of 'need', 'audience', and 'bot_role'. The tool description adds no additional parameter-level detail beyond what the schema provides, placing it at the baseline score.
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's purpose: to request a feature or need from the platform, with specific examples ('missing test, profile, capability, or integration'). It distinguishes itself from siblings like get_network_stats or get_pricing by focusing on submitting a request rather than retrieving information.
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 when to use this tool (when you need to request a feature), and notes that requests shape the roadmap. However, it does not explicitly mention alternatives or provide when-not-to-use guidance, leaving the user to infer usage context from the tool's name and examples.
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 target distinct concerns: stats, pricing, profiles, fee previews, feature requests, and scoring. The main ambiguity is between get_pricing and preview_fee, but their descriptions clarify that one is the general pricing manifest and the other is a wallet-specific quote.
The majority of tools follow a readable snake_case verb_noun pattern, such as get_network_stats, list_profiles, preview_fee, request_feature, and score_text. The outlier is storelayer_widget_menu, which is a noun phrase rather than a clear verb action, and the retrieval verbs vary slightly, but the overall pattern is consistent enough.
Seven tools is a reasonable size for a scoring and benchmarking platform and stays well within the ideal range. However, storelayer_widget_menu feels like an unrelated promotional addition that does not earn its place alongside the scoring-focused tools.
The free scoring path, profile listing, pricing, and network stats are present, but the paid validation workflow via POST /api/simulate, progress reports via POST /api/progress, and bundle purchases are only described in get_pricing rather than exposed as MCP tools. This leaves a notable gap in the core paid workflow, though agents could fall back to REST.