get_productGet one live FastDrop product by its slug. Returns the MCP URL if set, mcpVerified, last-verified timestamp when available, and the probed tool list (name + description) read from the endpoint - not maker-supplied tags.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug from the /p/<slug> URL |
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral details: it returns MCP URL, mcpVerified, last-verified timestamp (when available), and probed tool list read from endpoint (not maker-supplied tags). This enriches the agent's understanding beyond the structured 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?
The description is a single, clear sentence that efficiently conveys the tool's action and return data. It is front-loaded with the core purpose. No unnecessary words. However, it could be slightly more structured, e.g., separated into purpose and return information, but it is still concise.
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 simplicity (one required parameter, read-only, has output schema), the description is fully sufficient. It covers what the tool does, how to identify the resource (slug), and what data to expect. No omissions for this level of complexity.
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%, with the slug parameter well-described as 'Product slug from the /p/<slug> URL'. The description does not add new details about the parameter beyond what the schema provides. It mentions the return fields indirectly, but that does not enhance parameter understanding. Baseline score of 3 is appropriate.
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 identifies the verb 'Get', the resource 'one live FastDrop product', and the identifier 'by its slug'. It distinguishes the tool from siblings like search_products and list_comments by specifying a single product retrieval. The return fields are also listed, leaving no ambiguity about the tool's purpose.
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 have a slug and need product details. It does not explicitly state when not to use it or suggest alternatives, but the sibling tool names provide context for differentiation. A more explicit exclusion statement would warrant 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.
Each tool has a clearly distinct purpose: searching by capability, getting product details, listing comments, launches, reviews, and searching by text/tags. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (find_tools, get_product, list_comments, list_launches, list_reviews, search_products), with clear and predictable verbs.
Six tools is appropriate for a product discovery server, covering search, detail retrieval, and listing of associated data without being excessive or insufficient.
The tool set covers the core operations for the domain: searching, viewing individual products, and browsing launches, comments, and reviews. No obvious gaps for a read-only discovery service.