Calculate and compare indicative UK building-work budgets from supplied scope using Proper Job.
Use this when a user asks how much UK building work could cost, needs a renovation budget, or wants to recalculate a supplied scope. Calculate an indicative GBP range for supported work such as extensions, loft conversions, kitchens, bathrooms and refurbishment using Proper Job's pricing engine. Use only conversation-supplied scope, area in square metres and outward postcode. Missing details return needs_input; ask the user rather than guessing. Returns a rich budget card with VAT, assumptions and exclusions. Not for property valuations, mortgages, non-UK work, fixed contractor quotes, private project lookup or drawing extraction.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| jobType | No | ||
| postcodeArea | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| status | Yes | |
| requestId | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description discloses that missing details return 'needs_input' and that the tool returns a 'rich budget card with VAT, assumptions and exclusions'. It also states it uses only conversation-supplied data, providing extra behavioral context without contradicting 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 concise and front-loaded with usage conditions. It covers purpose, supported work, constraints, output, and exclusions in five sentences without unnecessary detail, making it easy to parse and act on.
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 includes explicit exclusions that help route away from non-applicable requests, and it summarizes the output format and error behavior. However, it does not explicitly reference sibling tools like 'compare_guide_scenarios' or 'get_estimate_requirements', so some differentiation relies on inference. The output schema is indicated but not shown, so the description's summary is sufficient but not exhaustive.
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 description mentions 'scope, area in square metres and outward postcode', giving a partial hint about inputs, but it does not explicitly explain the 'jobType' top-level enum parameter. The nested scope object contains many fields with limited descriptions, so the parameter semantics are not fully addressed. The note about 'needs_input' mitigates some ambiguity, but the description could be more precise about which parameters are required for different job types.
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 when to use the tool ('when a user asks how much UK building work could cost...'), what it calculates ('an indicative GBP range'), and lists supported work types. It also explicitly distinguishes from excluded use cases ('Not for property valuations, mortgages, non-UK work...'), making the purpose unambiguous.
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?
Provides explicit when-to-use ('Use this when...') and when-not-to-use ('Not for...') guidance. It also instructs the agent to ask the user rather than guessing when details are missing, which is a clear behavioral directive for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a baseline and up to three user-supplied scope alternatives on the same pricing policy, including server-calculated price differences. Supply baseline inputs from the conversation; saved estimates cannot be retrieved.
| Name | Required | Description | Default |
|---|---|---|---|
| baseline | Yes | ||
| scenarios | Yes |
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| status | Yes | |
| requestId | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by stating that price differences are server-calculated and that saved estimates cannot be retrieved, meaning inputs must be supplied from the conversation. This aligns with the readOnlyHint and idempotentHint annotations without contradicting them.
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, directly addresses the core function, and contains no redundant or extraneous information. It is well-structured and easy to parse.
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?
While the description does not explain the output format, an output schema is provided, so that omission is acceptable. It adequately conveys the inputs (baseline from conversation, up to three alternatives) and the core functionality. It could be slightly more explicit about the number of scenarios, but the schema already constrains that.
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 schema has no descriptions for the many parameters (coverage 0%), and the tool description only mentions 'baseline' and 'scope alternatives' without explaining their structure or any individual fields. Since the schema is highly complex and the description does not compensate, parameter semantics are severely lacking.
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 purpose: calculating a baseline and up to three scope alternatives on the same pricing policy, including server-calculated price differences. It specifies the verb 'Calculate' and the resource (baseline and alternatives), and it distinguishes this from a single-price tool by emphasizing comparison and price differences.
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 the tool (when you have a baseline from the conversation and want to compare alternatives), but it does not explicitly mention sibling tools like calculate_guide_price or get_estimate_requirements, nor does it state conditions when not to use this tool. Guidance is present but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a conversation about a UK extension, loft, kitchen, bathroom or refurbishment budget. Returns supported scope choices, missing inputs and useful questions. No account or saved project required.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| jobType | No | ||
| postcodeArea | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| status | Yes | |
| requestId | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds behavioral context beyond the annotations by specifying that the tool returns scope choices, missing inputs, and questions, and that it requires no account or saved project. This is useful supplementary context.
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, concise and front-loaded with the primary action ('Start a conversation...'). It avoids unnecessary detail and is easy to scan.
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 complexity (3 top-level parameters, a large nested scope object with over 80 fields, and an output schema), the description is far too brief. It does not explain the shape of the return value, how to map user inputs into the nested object, or what 'supported scope choices' means in practice. This leaves significant gaps for an agent trying to use the tool correctly.
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 effectively zero (only approximateSize has a brief description). The tool description does not compensate by explaining the parameters (jobType, postcodeArea, scope) or how to populate the nested scope object. Parameter names and enum values give some clues, but the description adds no semantic guidance for a complex input structure.
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 purpose: starting a conversation to gather estimate requirements and returning supported scope choices, missing inputs, and questions. It does not explicitly name sibling tools (calculate_guide_price, compare_guide_scenarios) to differentiate, but the focus on gathering inputs rather than calculating or comparing makes the intended use evident.
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 usage for initial requirements clarification ('Start a conversation about... budget') but does not explicitly state when to use this tool versus the sibling tools (calculate_guide_price, compare_guide_scenarios) or provide conditions for when it is not appropriate. No alternative guidance is given.
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. Dates show when Glama detected each change.
calculate_guide_pricecompare_guide_scenariosget_estimate_requirementsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Parametric estimating engine: CESMM4/NRM2/SMM7/MMHW Bills of Quantities for civils assemblies.
AI-powered job cost estimator for skilled trades with material and labor breakdowns
An MCP server that audits the fairness of construction and renovation estimates in Japan. Provides fair-price ranges, overcharge detection, and verifiable unit-cost data based on JCCDB (65,520 items across 402 categories, CC BY 4.0, DOI-backed).
Independent pre-transaction audit for construction estimates. Free, and every verdict recomputes.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: calculate a single price, compare scenarios, and gather requirements. There is no meaningful overlap that would cause an agent to select the wrong tool.
All names follow a clear verb_noun pattern (calculate_guide_price, compare_guide_scenarios, get_estimate_requirements). Minor inconsistency exists between 'guide_' and 'estimate_' prefixes, but the pattern remains predictable.
With three tools, the set is compact and well-suited to the domain of guide pricing. Each tool serves a necessary step in the user journey without redundancy.
The tool set covers requirements gathering, single price calculation, and scenario comparison, which are the core operations for this pricing assistant. No obvious missing functionality is needed for the stated use cases.