Skip to main content
Glama

Workeey Quote Links

Price book: a starting price for each job

price_check
Read-onlyIdempotent

A starting price for a job, from Workeey's price book (plumbing, electrical, hvac, handyman, house cleaning, landscaping), for a US place. Give the job in words and where ("toilet repair", "Brooklyn, NY"): it answers with the one matching job, priced as labor (hours × an hourly rate) + parts (with markup) + optional travel, what the job includes, its parts with the product pages they were priced from, the place it priced for, and draft_link: a Quote Links address that opens the quote form already filled in with that job and price. Or give a trade (no job) for every job of the trade. You can give your own rate, markup, travel, and hours or parts cost. The rate starts from government data on what employees are paid and what employers pay on top (BLS), turned into a self-employed rate by our hourly rate calculator's math; parts are retailers' online shelf prices we checked by hand on November 6, 2026, each with its link (a price from Ace Hardware or Menards is one store's online price, not a national one); the two we could not check say "not checked"; job hours are starting guesses, so set your own. This is not what others charge. With no BLS figure for a place, it uses the state's or the national one and says so (place.fallback). Every checked figure carries its source and the day it was checked. From Workeey's data, read-only, no AI.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "price_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobNoThe job in words, as the customer or tradesperson said it ("fix a running toilet", "install a ceiling fan"). Answers with the one matching job; a near tie or no match says so and lists the closest.
jobsNoWithout job: per job of the trade, by its id, your own hours or parts cost in dollars. The answer lists every job's id.
rateNoYour own hourly rate in dollars. Leave it out to use the suggested rate.
hoursNoWith job: your own hours for it. Leave it out for the book's starting hours.
metroNoA BLS metropolitan area code inside that state (a wrong one lists the state's areas). Leave it out for the state's figure. Not with where.
partsNoWith job: your own parts cost for it, in dollars, before markup. Leave it out for the checked retail midpoint.
stateNoA state's two-letter code (DC for Washington, DC). Leave it out for the national figure. Not with where.
tradeNoThe trade. plumbing: Plumbing; electrical: Electrical; hvac: HVAC; handyman: Handyman; cleaning: House cleaning; landscaping: Landscaping. With job, it narrows the search; without job, the answer is every job of the trade.
whereNoWhere the job is, in words: "City, ST" ("Austin, TX"), a state, or a New York City borough. Instead of state and metro.
markupNoYour markup on parts, in percent. Leave it out for 20%.
travelNoTravel added to every job: on, the miles and the minutes of a trip (miles at the IRS rate, minutes at your rate). Off unless on is true; 20 miles and 30 minutes when not given.
businessNoThe business name, if known ("Rivera Plumbing"): when two trades have the same job, its trade wins.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description adds substantial behavior beyond them: how the rate is derived (BLS employee pay plus employer costs, converted to a self-employed rate), how parts prices were sourced and hand-checked on a stated date, the place.fallback rule when no BLS figure exists, and the 'not checked' marker for unverified prices.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first clause, but the text is a long run-on with repeated provenance claims ('every checked figure carries its source and the day it was checked' restates the November check date) and several parenthetical asides that could be trimmed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 12 parameters, nested objects and no output schema, the description carries the return-value burden and does so: it enumerates the one matching job, the labor/parts/travel price composition, what the job includes, sourced parts links, the priced place, and the draft_link quote form URL.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description still adds meaning by spelling out the pricing formula (hours × rate + parts with markup + optional travel) and by clarifying the mutual exclusivity of 'where' versus 'state'/'metro' and the role of 'business' in resolving cross-trade name collisions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns a starting price for a named job from Workeey's price book for a US place. It also names the trades covered and the exact answer shape (labor + parts + travel, includes, parts sources, place, draft_link), which clearly separates it from siblings like create_quote_link or job_check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives strong in-tool branching rules — supply 'job' for one priced job, supply only 'trade' for every job of the trade, override rate/markup/travel/hours/parts as needed — but it never states when to prefer this over the sibling alternatives such as job_check or create_quote_link.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources