Fixed-price websites, booking sites, webshops and web apps: products, prices, work and contact.
Scored across 4 tools
The four tools are mostly distinct: list_products is a catalog, list_work is a portfolio, request_contact is a lead handoff, and get_quote is a need-based recommendation. The only mild overlap is between get_quote and list_products because both can surface pricing/product information, but the descriptions differentiate catalog browsing from tailored quoting.
All tool names follow a clear snake_case verb_noun pattern: get_quote, list_products, list_work, request_contact. The convention is consistent across the set and easy to predict.
Four tools are well-scoped for a small pre-sales website-services server: browse products, request a quote, inspect portfolio work, and initiate contact. Each tool has a clear role and none feels redundant or excessive.
The surface covers the core pre-sales journey: product discovery, quote generation, portfolio evidence, and contact initiation. Minor gaps exist, such as no standalone product-detail or contact-request status tool, but agents can work around them through the existing tools.
Maps what the user needs to one product and returns its prices (once, yearly, first year, excluding 21% VAT), what is included and when they pay. Describe the need in plain words (Dutch or English) and/or pass features. If the need is unclear it asks questions instead of guessing; if it is outside the four products (for example an app for the App Store) it returns no price. Prices come only from the public price list. An indication, not a binding offer. No side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What the user needs, in their words. For example: a website for my taxi company where customers can book rides. | |
| locale | No | Language of the text in the result. Prices are the same in both. Default en. | |
| features | No | Optional: what the site must do, from this list. The most capable feature decides the product. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/no-side-effects annotations, it discloses the source of truth (public price list only), the non-binding nature of the output, the clarification behavior when needs are ambiguous, and the no-price outcome for out-of-scope requests. These are real behavioral traits an agent cannot infer from the 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?
Front-loaded with what the tool does and what it returns, then behavior, then caveats. Dense but nearly every clause carries information; the parenthetical price breakdown and the VAT note are slightly compressed into one long sentence but still readable.
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?
There is no output schema, and the description compensates by enumerating the returned fields (one-time, yearly and first-year prices ex 21% VAT, what is included, when they pay). Combined with the scope and ambiguity rules, an agent has everything needed to call it and interpret the result.
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 already 100%, but the description adds meaning on top: 'need' accepts plain Dutch or English, and for 'features' it states the decision rule that the most capable feature decides the product. It adds little for 'locale' beyond what the schema says, which keeps it from a 5.
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?
States a specific verb and resource: maps a need to exactly one product and returns its prices, inclusions and payment timing. This is clearly distinct from the siblings (list_products, list_work, request_contact), which do none of these things.
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?
Gives concrete usage context: describe the need in plain Dutch or English and/or pass features, and it will ask questions if the need is unclear. It also defines the out-of-scope case (outside the four products, e.g. an App Store app returns no price). It does not explicitly route the agent away from list_products when browsing the catalog, but the conditions for calling it are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The four products (website, booking site, webshop, web app) with the one-off price, the yearly price, what is included, when you pay, what every yearly price includes, the usage included per month for each product (visitors, emails, orders, database; not a limit), the overage terms (at cost, no markup, a monthly cap, a written yes from the customer above it), and the contact channels. Prices are in EUR excluding 21% Dutch VAT. No side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language of the text in the result. Prices are the same in both. Default en. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description repeats 'No side effects' and adds pricing/VAT/overage context, but does not add auth, rate-limit, or response-shape behavior beyond what annotations and schema cover.
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 front-loaded with the product list and every clause describes relevant return content, but it is a single dense run-on sentence that would be clearer as structured bullets. It is informative but not optimally 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?
With no output schema, the description carries the burden of explaining return values and does so thoroughly, covering products, one-off and yearly pricing, VAT, usage allowances, overage terms, and contact channels. It is nearly complete for invocation, though it lacks explicit sibling-routing guidance.
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% and the single locale parameter is already documented with its enum, default, and meaning. The description does not add any locale-specific semantics, so the baseline 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 states a specific verb and resource (list products/prices) and enumerates the exact product set and pricing fields returned. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as get_quote or request_contact.
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 explains what will be returned but gives no guidance on when to use this tool versus get_quote, request_contact, or list_work. There are no exclusions, prerequisites, or alternative-selection cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real client sites built and hosted by darioa (a tyre shop webshop, two chauffeur booking sites, a bike rental, a restaurant, a till system with a scale): what was built, which product it is, and the live site and case study. Optionally filter by product or by trade. No side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | No | Kind of business, for example taxi-chauffeur or restaurant. | |
| locale | No | Language of the text in the result. Prices are the same in both. Default en. | |
| product | No | One of the four products: website, booking (booking site), webshop, webapp (web app). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context by saying these are real, hosted client sites and by indicating the returned fields, though 'No side effects' is redundant with the 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 front-loaded with the core purpose and remains reasonably short. The parenthetical examples add concreteness, though 'No side effects' is unnecessary given the annotations.
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 three-parameter, read-only list tool with full schema coverage and explicit annotations, the description is complete enough. It explains the domain, gives representative examples, states the optional filters, and describes what the result contains despite there being no output 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?
Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description mentions filtering by product or trade but does not add syntax, defaults, or locale details beyond what the schema provides, so it meets the baseline without exceeding it.
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 verb and resource: listing real client sites built and hosted by darioa. It also clarifies the returned content (what was built, product type, live site and case study), making it distinguishable from sibling tools like list_products or get_quote.
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?
It clearly establishes the usage context: retrieve real client sites and optionally filter by product or trade. It does not explicitly name when to choose this over siblings, but the purpose is unambiguous enough that an agent can infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a real contact request for the user. Call ONLY after the user has seen exactly what will be sent and said yes (set userConfirmed true), and use their own name and email. Nothing reaches Dario yet: the user gets an email from darioa with a confirm button and only their click sends it (valid 24 hours); Dario then replies personally, usually within one working day. Repeating the identical call does not send a second email. Returns the WhatsApp link, phone and email for direct contact too. Limits: 5 requests per email address a day; throwaway email addresses are refused.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The user's name. | |
| Yes | The user's own email address; the confirmation email goes here. | ||
| phone | No | Optional: the user's phone number with country code. | |
| locale | No | Language Dario and the confirmation email should use. Default en. | |
| message | Yes | What the user needs, in a few sentences (include the product and any details from get_quote). Shown to Dario as written. | |
| product | No | One of the four products: website, booking (booking site), webshop, webapp (web app). | |
| websiteUrl | No | Optional: the user's current website. | |
| businessName | No | Optional: the user's business name. | |
| userConfirmed | Yes | true only after the user has seen the data above and agreed that Dario may contact them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: explains the two-step email confirmation with a 24-hour window, that nothing reaches Dario until the user clicks, response time expectation, idempotent repeat behavior, rate limit (5 per email per day) and rejection of throwaway addresses. It substantiates the idempotentHint rather than merely restating it.
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?
Front-loads purpose, then the precondition, then the mechanics, then limits. Every sentence carries information an agent would otherwise have to guess; no 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?
With 9 parameters, no output schema and openWorldHint, the description covers the full lifecycle (what is sent, when, by whom, limits, what comes back). The return payload is described in prose in lieu of an output 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?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: userConfirmed is a hard gate tied to a user-visible confirmation step, name/email must be the user's own, and the message is shown to Dario verbatim. Phone, locale, product and URL params are left entirely to the schema.
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?
Opens with a specific verb and resource: 'Starts a real contact request for the user.' It is immediately distinguishable from get_quote, list_products and list_work, which are read/lookup siblings, and the title reinforces the intent.
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?
'Call ONLY after the user has seen exactly what will be sent and said yes (set userConfirmed true)' is an explicit precondition, and 'use their own name and email' is an explicit constraint. The message parameter also points to get_quote as the source of details to include.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_quotelist_productslist_workrequest_contactNetik services (websites, systems, AI agents) with final prices, priced exactly as the site does.
Branding, design and web services you can order and pay for without a human on the seller side.
Build and edit launch-ready websites for tech founders from a brief or an authorised reference.
Netik services in Israel (websites, systems, AI agents) with final prices in ILS.
Add one secure layer between your agents and this server.