Custom closets built to your measurements, shipped anywhere in the US. Estimates and quote requests.
Scored across 4 tools
Each tool has a clearly distinct purpose: company info, price estimation, measuring guidance, and quote submission. There is little meaningful overlap between them, so an agent can select the right tool confidently.
All names use snake_case, but they mix noun phrases, an instructional phrase, and a verb-object pattern. The set is readable but lacks a predictable verb_noun convention throughout.
Four tools is well-scoped for a narrow pre-sales closet estimation and quote-request server. Each tool covers a distinct step and none feels redundant.
The core customer journey is covered: learn about the business, estimate pricing, measure the closet, and request a quote. Minor gaps exist around browsing configurations or tracking an existing order, but the main workflow is complete.
Who Paradise Closets is: custom closets built to the customer's measurements, shipped anywhere in the US, DIY install (no installation service), and how to contact them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real business context that prevents agent error: closets are DIY install with NO installation service, and shipping is anywhere in the US. That 'no installation service' caveat is exactly the kind of disclosure that stops a bad answer, though the description doesn't say the data is static.
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?
A single sentence, front-loaded with who the company is, then the key facts, then contact. Every clause carries information; zero 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 no output schema, the description must preview the returned content, and it does so by enumerating the fields effectively. Minor gap: it doesn't say whether the contact info includes phone, email, or hours, which would help an agent decide if it can answer a specific contact question.
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?
The tool takes zero parameters, so baseline is 4. The description correctly implies a no-argument, whole-record fetch with no filtering semantics needed.
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 names a specific resource (company profile for Paradise Closets) and enumerates its contents: custom sizing, US shipping, DIY install, and contact details. An agent can distinguish it from the pricing, measuring, and quote siblings, though it lacks an explicit verb like 'Get' and frames itself as a topic label rather than an action.
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?
Usage is only implied: an agent must infer that this is the tool for company, shipping-policy, or contact questions. No when-not-to-use guidance or explicit routing to siblings (e.g. closet_price_estimate for pricing) is given, so an agent could plausibly call this for a quote question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ballpark price range for a custom reach-in or walk-in closet, using the same formula as the estimator on pclosets.com/quote. Give the ship-to zip_code to add a live freight estimate (LTL carrier quote, residential delivery with liftgate) and a total; otherwise shipping is quoted with the order. Final price is confirmed after a designer reviews the measurements.
| Name | Required | Description | Default |
|---|---|---|---|
| finish | No | white | |
| drawers | No | Number of drawers | |
| package | No | Premium: dovetail drawers with soft-close, plus crown and base molding. Standard: standard drawers, no crown or base molding. | premium |
| zip_code | No | Optional ship-to US ZIP code (e.g. 08701) for a live freight estimate | |
| closet_type | Yes | Reach-in (one wall) or walk-in (up to three walls) | |
| depth_inches | No | Unit depth in inches: 14 (standard), 16 or 22 | |
| width_inches | No | Reach-in: back wall width in inches | |
| special_color | No | Special color (specialty matte colors, priced from the supplier's specialty level) | |
| wall_a_inches | No | Walk-in: wall A width in inches | |
| wall_b_inches | No | Walk-in: wall B width in inches | |
| wall_c_inches | No | Walk-in: wall C width in inches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true; the description earns credit by explaining the open-world behavior concretely (live LTL carrier quote, residential delivery with liftgate) and by setting expectations that the result is a ballpark confirmed by a designer, not a binding price. It does not disclose latency, failure modes, or what the response object looks like, keeping it short of a 5.
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 sentences, purpose front-loaded, then the zip_code conditional, then the caveat about designer confirmation. Each sentence carries information, though the freight parenthetical is dense and could be trimmed without loss.
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 an 11-parameter estimator with no output schema, the description covers purpose, the optional freight branch, and that the returned figure is provisional. The main residual gap is that it does not characterize the shape of the returned range/total, but the phrasing 'price range ... and a total' gives enough for correct invocation.
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 91%, so the schema already documents parameters well, including the reach-in vs walk-in wall/dimension split and the package tiers. The description adds only marginal meaning, mainly reinforcing the zip_code freight behavior; it adds nothing about how reach-in widths versus wall_a/b/c should be supplied or what happens when measurements are missing.
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 — a ballpark price range for a custom reach-in or walk-in closet — and grounds it in a reference implementation ('same formula as the estimator on pclosets.com/quote'), which tells the agent this is the cheap pre-quote path. It does not explicitly name the sibling request_quote as the escalation, so differentiation from that sibling is only implied.
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 zip_code conditional is spelled out clearly: supply it to get a live freight quote and total, omit it and shipping is quoted with the order. However, there is no explicit statement of when to prefer this over request_quote or how_to_measure, and no when-not guidance — usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step-by-step guidance for measuring a closet before getting an estimate or requesting a quote.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations clarify its safe, closed-world status, the description reinforces that it is a 'step-by-step guidance' tool. This adds useful context about the format of the output (instructional) beyond what the technical annotations provide.
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, highly concise sentence that front-loads the core value proposition and is extremely efficient.
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 that it is a pure knowledge/guidance retrieval tool with no parameters, the description is completely sufficient to guide an agent on when and why to invoke it.
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?
Since the tool accepts 0 parameters and has 100% schema coverage, the baseline score is 4. The description adds no semantic meaning regarding parameters because none exist.
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 its purpose is to provide 'step-by-step guidance for measuring a closet.' It is distinct from related sibling tools like price estimation and quote requests.
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 explicitly dictates when to use this tool: 'before getting an estimate or requesting a quote,' providing a perfect context for its utility relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the customer's closet details to Paradise Closets so a designer contacts them with a quote (same as the form on pclosets.com/quote). Only call this when the customer asked to be contacted and agreed to share their details. Requires name, US ZIP, an email or phone, closet type and dimensions.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Customer's full name | |
| No | Customer email (email or phone is required) | ||
| notes | No | Anything else: doors, windows, style, timing | |
| phone | No | Customer phone, 10+ digits (email or phone is required) | |
| finish | No | white | |
| drawers | No | Number of drawers | |
| package | No | Premium: dovetail drawers with soft-close, plus crown and base molding. Standard: standard drawers, no crown or base molding. | premium |
| zip_code | Yes | US ZIP code where the closet ships | |
| closet_type | Yes | Reach-in (one wall) or walk-in (up to three walls) | |
| depth_inches | No | Unit depth in inches: 14 (standard), 16 or 22 | |
| width_inches | No | Reach-in: back wall width in inches | |
| special_color | No | Special color (specialty matte colors, priced from the supplier's specialty level) | |
| wall_a_inches | No | Walk-in: wall A width in inches | |
| wall_b_inches | No | Walk-in: wall B width in inches | |
| wall_c_inches | No | Walk-in: wall C width in inches | |
| ceiling_height_inches | No | Ceiling height in inches (default 96) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is not read-only, is open-world, non-idempotent, and non-destructive. The description adds important context beyond annotations: it sends customer details to a third party, triggers designer follow-up, mirrors the pclosets.com/quote form, and requires explicit consent. It does not explain duplicate-submission behavior, but the idempotency annotation covers part of that.
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?
Three tight sentences, front-loaded with the action and purpose. The consent condition and required inputs follow logically, with no filler or repetition.
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 16-parameter form submission with no output schema, the description covers the key context an agent needs: the external recipient, consent requirement, required contact method, and that dimensions are needed. The schema handles detailed parameter semantics. Remaining gaps, such as what error or confirmation the caller receives, are minor given the rich input schema and annotations.
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 94%, so the schema already documents nearly all parameters in detail. The description summarizes the required inputs (`name`, US ZIP, email or phone, closet type, dimensions), but adds little syntax or conditional guidance beyond what the schema provides. Baseline 3 is appropriate when schema coverage is this high.
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 uses a specific verb and resource: it sends the customer's closet details to Paradise Closets for a designer quote. It also identifies the equivalent web form and clarifies that this is a lead/quote request rather than an instant price estimate, which helps distinguish it from the sibling `closet_price_estimate`.
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 gives a clear condition for use: only call when the customer asked to be contacted and agreed to share their details. It does not explicitly name alternatives such as `closet_price_estimate` or `how_to_measure`, but the consent gate and required details provide strong usage context.
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.
closet_price_estimate1 field changedInput schema / properties / package / descriptionPrevious value: -"Premium (luxury materials & hardware) or Standard (quality at great value)"New value: +"Premium: dovetail drawers with soft-close, plus crown and base molding. Standard: standard drawers, no crown or base molding."request_quote1 field changedInput schema / properties / package / descriptionPrevious value: -"Premium (luxury materials & hardware) or Standard (quality at great value)"New value: +"Premium: dovetail drawers with soft-close, plus crown and base molding. Standard: standard drawers, no crown or base molding."closet_price_estimate2 fields changedInput schema / properties / depth_inchesAdded value: +{
+ "default": 14,
+ "description": "Unit depth in inches: 14 (standard), 16 or 22",
+ "enum": [
+ 14,
+ 16,
+ 22
+ ],
+ "type": "integer"
+}Input schema / properties / special_color / descriptionPrevious value: -"Special color (+30%)"New value: +"Special color (specialty matte colors, priced from the supplier's specialty level)"request_quote2 fields changedInput schema / properties / depth_inchesAdded value: +{
+ "default": 14,
+ "description": "Unit depth in inches: 14 (standard), 16 or 22",
+ "enum": [
+ 14,
+ 16,
+ 22
+ ],
+ "type": "integer"
+}Input schema / properties / special_color / descriptionPrevious value: -"Special color (+30%)"New value: +"Special color (specialty matte colors, priced from the supplier's specialty level)"closet_price_estimate1 field changedInput schema / properties / zip_codeAdded value: +{
+ "description": "Optional ship-to US ZIP code (e.g. 08701) for a live freight estimate",
+ "type": "string"
+}business_infocloset_price_estimatehow_to_measurerequest_quoteCustom t-shirts and apparel, printed and shipped in the US on your deadline.
Get 3D printing and manufacturing quoted by a person, shipped anywhere in the US.
Quote, price and order custom 3D prints (PLA) shipped anywhere in the US.
Instant pricing, 111 named sets and draft orders for custom index tabs and binder dividers.
Add one secure layer between your agents and this server.
