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. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits itself. It does disclose that requests are 'Free' and 'directly shape the roadmap', which implies a persistent side effect on the product. However, it does not disclose whether the submission is public, whether authentication is required, rate limits, or what happens after submission. For a simple feedback-submission tool this is adequate but not richly transparent.
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 three short sentences, purpose is front-loaded, and every sentence contributes ('Free.' and 'directly shape the roadmap' add behavioral context). No filler or repetition. Slightly compressed, but efficient for such a simple tool.
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 simple tool with 100% parameter coverage, no output schema, and no nested objects, the description covers the essential context: what it does, what kinds of requests are accepted, and that it's free. The only gaps are response/outcome behavior and any usage limits, which are minor for a feature-request submission tool. Adequately complete.
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%, so the schema already documents all three parameters clearly ('What you wish existed (10-1000 characters)', auditience as 'bot' or 'developer', bot_role as OPTIONAL). The description adds minimal parameter meaning beyond the schema, so the baseline of 3 is appropriate. The example list (test, profile, capability, integration) loosely hints at valid values for 'need' but adds no formal semantics.
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 states a clear purpose: submit what you need next to shape the platform's roadmap, with concrete examples (test, profile, capability, integration). It is distinguishable from the sibling tools, which are read-style tools (get_*, list_*, preview_*, score_*), making the feedback-channel nature of this tool evident. Slightly informal phrasing ('Tell the platform') but unambiguous.
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 context implies when to use it — when you want a new capability to be considered — but there is no explicit when-to-use guidance, no exclusions, and no comparison against alternatives. The sibling tools are sufficiently different in nature, so the lack of explicit routing is not a major gap, but the description leaves the decision to inference.
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 are clearly distinct: stats, pricing, profiles, fee previews, feature requests, scoring, and Storelayer actions each have separate purposes. The two Storelayer tools could be confused since both reference the same 57-widget catalog, but one is explicitly read-only recommendation and the other is activation/install. Pricing-related tools are also separated between general manifest and wallet-specific fee preview.
The majority of tools follow a verb_noun snake_case pattern: get_network_stats, get_pricing, list_profiles, preview_fee, request_feature, score_text. The two storelayer_* tools break the pattern by leading with a domain prefix and one uses a noun-noun form rather than verb_noun. Overall it is readable but not fully consistent.
Eight tools is a reasonable count for a server that combines scoring, pricing, profile lookup, and Storelayer integration. No tool feels redundant or unnecessary. The breadth of domains is wide, but each tool contributes to a distinct function.
The tool surface covers the main informational and free actions: stats, pricing, profile listing, fee preview, scoring, and feature requests. However, paid validation, progress reports, bundle purchases, and Storelayer verification/removal are only described as external endpoints or multi-step flows rather than exposed as MCP tools. These gaps are workable but may require agents to leave the MCP server for key monetized capabilities.