Ballpark budget and range for an app/product, mirroring dribba.com's public calculator. Minimum project budget is €30,000.
| Name | Required | Description | Default |
|---|---|---|---|
| design | No | ||
| timeline | No | ||
| platforms | Yes | At least one target platform. | |
| complexity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: estimates are approximate ('ballpark'), mirror an external calculator, and have a €30,000 minimum project budget.
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?
Two short sentences with no filler. The core purpose is front-loaded, and the minimum budget constraint earns its place as a key operational detail. Every word adds value.
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?
The description tells the agent the tool produces a budget/range and a minimum constraint, but with no output schema it does not explain the expected response shape, currency beyond the minimum, or how the optional parameters affect the result. It is adequate for recognizing the tool's job but leaves room for uncertainty around calling and interpreting results.
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 only 25% — only 'platforms' gets a description. The description does not compensate for the missing parameter semantics; it never explains what values like 'basic', 'custom', 'rush', 'normal', or 'mvp' mean or how they influence the estimate. The agent is left with enum labels and little guidance.
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 specific action: provide a ballpark budget and range for an app/product, clearly distinguishing it from sibling tools like company_facts, list_projects, list_services, and submit_contact_request. It also references dribba.com's public calculator, giving the agent a concrete anchor for the behavior.
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 phrase 'Ballpark budget and range for an app/product' gives clear context for when this tool applies, and no sibling tool competes for the same purpose. It does not explicitly state when not to use it, but the domain is distinct enough that usage is evident.
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 serves a distinct purpose: company facts, cost estimation, project listing, service listing, and contact submission. There is no overlap or ambiguity between them.
Four tools follow a clear verb_noun pattern (estimate_project, list_projects, list_services, submit_contact_request), but 'company_facts' deviates by using a noun_noun structure, breaking the otherwise consistent convention.
With 5 tools, the server is well-scoped for its purpose—showcasing the company and generating leads. Each tool earns its place without redundancy or bloat.
The tool surface covers the core journey: learn about the company, see services and projects, get an estimate, and contact. A notable minor gap is the lack of a tool to fetch detailed information on a specific project, but this is not a blocker for most use cases.
