Search the OpenDraft marketplace for AI-built apps. If no results match, your search is logged as a demand signal.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| category | No | ||
| max_price | No | ||
| tech_stack | No | ||
| completeness | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It discloses a non-obvious behavior: 'If no results match, your search is logged as a demand signal.' However, it omits other behavioral details such as whether results are paginated, what the response contains, or any authentication requirements. The disclosure is useful but incomplete, hence a mid-range score.
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 two sentences long, front-loaded with the primary action ('Search the OpenDraft marketplace...') followed by a concise note on side effects. Every sentence serves a purpose, with no redundant or vague wording. It is highly concise and well-structured.
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 has 6 parameters, no annotations, no output schema, and no parameter descriptions, the two-sentence description is insufficient. It does not explain the return format, pagination, how the filters interact, or even that it returns a list of matching listings. The demand signal note adds some context, but the overall description is inadequate for a search tool with this 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 description coverage is 0%, so the description must compensate by explaining parameters. It does not. The five parameters (limit, query, category, max_price, tech_stack, completeness) are only named, with enums for two, but no semantics are provided. The description adds no meaning beyond the parameter names themselves, leaving the agent to guess how filters combine and what input is expected.
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 function: 'Search the OpenDraft marketplace for AI-built apps.' It uses a specific verb ('search') and resource ('marketplace'), and the additional note about demand signals distinguishes it from sibling search tools like search_builders and get_listing. The purpose is unambiguous and well-differentiated.
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?
No explicit guidance is given on when to use this tool versus alternatives such as get_listing, get_trending, or search_builders. The demand signal note hints at a specific scenario, but it does not clarify when to prefer this tool over others. There are no exclusions or alternative recommendations, leaving the agent without usage context.
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 resources and actions. Some overlap exists among payment tools (initiate_purchase, headless_checkout, quick_purchase) and listing browsing tools (get_listing, get_trending, search_listings), but descriptions clarify their specific purposes.
Names are consistently snake_case and generally follow a verb_noun pattern (create_*, get_*, list_*, search_*). However, a few exceptions like 'quick_purchase' and 'headless_checkout' use adjective_noun constructions, and there is no single dominant verb style across the set.
With 26 tools, the count exceeds the 25-tool threshold for 'too many'. While the breadth of marketplace features (auth, listings, offers, payments, bounties, webhooks) justifies a larger surface, the number is still on the heavy side and could overwhelm agents.
The tool set covers core marketplace workflows (listings, search, offers, purchases, bounties). However, there are notable lifecycle gaps: no update/delete for listings, no create_bounty (only list/get), and no create_review. These missing operations limit full CRUD coverage.