Evolved is an MCP server that acts as a complete business operating system for a field-services (abrasive-blasting) company, enabling an AI agent to manage the full business lifecycle from lead to payment.
Quoting & Pricing
Price jobs using a learned rate engine ($/sqft by blast depth, surface type, site access) with profitability checks including media, labor, fuel, overhead, break-even rate, and margin verdict
Create formal, auto-numbered quotes with below-break-even flagging; accepting a quote auto-opens a job
Render branded dark-theme HTML quote documents ready to print/send as PDF
Manage quote lifecycle (Draft → Sent → Accepted/Declined/Expired) and view all quotes filtered by status
Train the pricing engine by recording job outcomes so future quotes for the same surface/depth get smarter
Financial Management
Ingest receipts through a tiered OCR pipeline (auto-escalation on low confidence, duplicate guarding, job matching, automatic categorization)
Generate expense reports by category and vendor for any month, including reclaimable GST
Create and render branded invoices with deposit applied, GST computed, and net-14 balance due
Run P&L reports (monthly or all-time): revenue, expenses, per-job margins, win rate, average $/sqft, and margin scorecard
Sales Pipeline & Dispatch
Capture leads with enforced next-action and date; advance them through the funnel (New → Contacted → Site Visit → Quoted → Won/Lost)
View the full sales pipeline — open leads by stage, quotes with age, and jobs by dispatch status
Schedule and dispatch jobs with weather-gated blast-day verdicts
Complete jobs by recording actuals (hours, crew, materials, fuel) to compute real profit, margin, and verdict
List the customer book with contact details and associated quotes/jobs
Safety & Compliance
Open Field-Level Hazard Assessments (FLHAs) auto-drafted from job scope with per-hazard mitigations, standard PPE, and muster point
Sign off FLHAs at end of day with crew signatures and incident status recorded permanently
View the safety log — open assessments needing sign-off, signed records, and incident flags
Autonomous Operations & Monitoring
Generate a morning digest: top priority, today's jobs/crews, money pulse, stale leads, auto-raised action items, 5-day weather verdicts, and system health
Scan for dropped balls: unscheduled deposits, unpaid invoices (7+ days), unanswered/expiring quotes, uninvoiced completed jobs, and stale leads
Resolve action items to clear them from the open list
Check blast-day weather for up to 14 days with go/marginal/no-go verdicts
Get a business snapshot — funnel counts, money position, open safety items, and action items on one screen
Reset the demo dataset to its seeded synthetic state for repeatable demonstrations
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Evolved show me the morning digest"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
One agent takes any service business from a texted photo to a paid, on-chain invoice. Free, open source (MIT), and adaptable to any trade in one call — proven on a real Alberta company. 85 tools, live as an MCP service, with on-chain settlement on OKX X Layer testnet.
A complete business operating system — free, open source, for any company. Not just an MCP server: four surfaces around one source of truth — the MCP brain, the crew field app (its hands), the workbook spine, and the owner dashboard (its eyes). Blasting is only the proving ground;
franchise_spinupmakes it any service business in one call. Pick your trade, generate your workbook, connect the app: docs/ONBOARDING.md.
▶ TRY IT LIVE — the browser playground — no install, no keys: run voice commands, photo-quote a driveway, drive the autonomous lifecycle through its two human money gates, and watch the x402 402 → proof → receipt flow, all against the real endpoint.
🎬 The 90-second film — every figure captured live from the endpoint (notes + license):
https://github.com/user-attachments/assets/ca858ecb-cf70-40d5-a1ac-54efef74f971
▶ Plays inline right here · also streaming at www.evolvedmcp.cloud/demo.mp4 · full-quality file
Judge tour · Why this wins · The lifecycle · On-chain · Frontier · 85 tools · Docs
Try it now, nothing to install: open the live playground at www.evolvedmcp.cloud and click Judge Mode.
Run the MCP yourself (prerequisites: Node 20+ and git — nothing else, no keys, no accounts):
git clone https://github.com/kr8tiv-ai/evolved.git && cd evolved
npm install && npm run build && npm run demo # the business loop, narratedWire it into your agent — hosted (nothing to install) via the mcp-remote bridge:
{ "mcpServers": { "evolved": { "command": "npx", "args": ["-y", "mcp-remote", "https://www.evolvedmcp.cloud/mcp"] } } }Then ask it: "Run the morning digest — what am I about to drop?" Full client configs (Claude Desktop, Cursor, local stdio): docs/CONNECT.md. Make it your business in one call, then stand up the whole system (workbook, field app, dashboard): docs/STAND-UP-YOUR-OWN.md — an afternoon for the MCP + workbook, a weekend for all four surfaces.
Related MCP server: Metrx MCP Server
The service is live. You can verify every headline claim from your terminal before reading another word.
# 1 · It exists, and it is an MCP service (10 seconds)
curl https://www.evolvedmcp.cloud/health
# 2 · It monetizes as an ASP — x402 pay-per-call (the 402 challenge, scheme "exact", eip155:1952)
curl -i -X POST https://www.evolvedmcp.cloud/mcp-paid \
-H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"judge","version":"1"}}}'
# 3 · Pay the challenge, get the service (settlement receipt in the X-PAYMENT-RESPONSE header)
# (header is base64 of {"simulated":true} — quote-safe on every shell, incl. PowerShell)
curl -i -X POST https://www.evolvedmcp.cloud/mcp-paid \
-H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
-H 'X-PAYMENT: eyJzaW11bGF0ZWQiOnRydWV9' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"judge","version":"1"}}}'
# 4 · The revenue scoreboard (paid calls + settlements, survives demo resets)
curl https://www.evolvedmcp.cloud/statsThen run the whole company locally — no keys, no accounts, no funds:
git clone https://github.com/kr8tiv-ai/evolved.git && cd evolved
npm install && npm run build
npm test # 52 tests — including a LIVE X Layer testnet probe
npm run demo # the business loop, narrated in your terminalEvery "AI for business" demo is a chatbot wearing a suit. Evolved is a complete company operating system any service business can spin up in one call — and it is built from the operating system of a real one. franchise_spinup { tradePack: "pressure-washing" } hands the whole machine to another trade in seconds; the credibility comes from Evolve Eco Blasting, the working Alberta abrasive-blasting company whose rates, GST and deposit policy, safety practice, and ball-drop rules run the demo — reimplemented, extended, and tested here. The demo dataset is synthetic; the math is not, and neither is the trade.
Any business, in one call. franchise_spinup re-seeds the whole OS for a new trade with its own rate card, hazards, pricing unit (sqft / hour / unit / vehicle / flat), currency, and tax label (GST / VAT / Sales Tax) — a US or EU shop never touches the code. Proven on blasting; built for everyone.
Both OKX rails — and the paid one is opt-in. Customer invoices settle in OKB on X Layer via EIP-681 requests verified by read-only RPC. The x402 pay-per-call tier is a built-in rail any adopter can switch on for their own deployment — off by default, never gating the free system. The on-chain integration judges score, without a toll on the open promise.
Autonomy with judgment. One agent runs lead → e-sign → weather-gated booking → FLHA safety → books → invoice → on-chain settlement → review — and holds at exactly two human gates, both about money. Agentic where it should be, accountable where it must be.
It learns — and never stops. Won jobs teach the rate engine (driveways converged to ~$9/sqft from outcome history), and every logged outcome now lifts a live confidence score and tightens the suggested quote range — more data, sharper quotes, on real or synthetic history alike. Each learned rate is benchmarked against the market band it derives from the trade's own card (market_benchmark, pricing_learning_status), so a quote is never blind; the books re-audit themselves daily; insight rankings train on the owner's feedback.
It is hardened, not vibed. A documented adversarial review pass produced 29 confirmed findings — including on-chain replay protection and e-sign decline finality — every one fixed and regression-tested in f6acd80. A second security pass followed: the replay claim is now atomic under concurrency (a test drives the race), the rate limiter resolves the client IP through trusted-proxy hops instead of a spoofable header, workbook_create link-shares read-only by default, and the two dataset-replacing tools are fenced off the shared public endpoint. 52 tests pass, one live against X Layer testnet. Full model: SECURITY.md.
Your books live in a real workbook. The whole OS renders as an operations workbook — every collection a tab. workbook_create builds and syncs an actual Google Sheets workbook (service-account JWT, no SDK, no keys stored); workbook_export writes the identical 25 tabs as CSV with zero credentials. The spine the production company runs on, available to every adapted business.
It scales past one company. franchise_spinup re-seeds the entire OS for any trade with a custom rate card in one call — franchise_preview window-shops it safely, brand_configure makes the rendered quotes feel like your company. Business management in a box is the product, not the tagline.
Evolved isn't just an MCP server — it's a complete, free, open-source operating system any service business can run, with four surfaces around a single source of truth:
🧠 The MCP — the brain (this repo). 85 tools that hold the business logic: pricing, safety, books, dispatch, on-chain settlement. It doesn't just execute — it watches and advises: a proactive morning digest and a business_intelligence tool that flag rising supplier prices, inventory running down, spend trends, and margin anomalies before they cost you. Every other surface is a client of it. Clone, npm install, npm run build, zero credentials.
✋ The field app — the crew's hands — kr8tiv-ai/evolve-field-app (MIT). A worker taps one button in the truck — photo, receipt, FLHA sign-off, hazard, note — and it lands in the App Inbox for the brain to file. $0/month on Google Apps Script. Deployed and in daily production use, which is what makes the tool surface a description of real work rather than a design exercise. Everything queues except safety: hazard_report escalates immediately, and an uncleared stop-work outranks every money flag on the dispatch board. (how it plugs in)
📊 The workbook — the spine — the whole operation as a 25-tab Google Sheets workbook, created and synced by workbook_create or exported to CSV with zero credentials. One shared source of truth for the humans and the agent. (generate your own)
📈 The dashboard — the owner's eyes, the administration surface. A login-protected, mobile-responsive web app reading the same workbook — live at ops.evolveecoblasting.com (behind auth), source open-sourcing to kr8tiv-ai/evolve-dashboard (MIT): a finance dashboard with interactive charts (spend proportion, revenue and margin trends, job-profitability comparison); job P&Ls, quotes, invoices, and receivables with every entity clickable through to its document; filterable receipts with pop-up images; an insights page (last month's revenue, where the money went, margin trends, outstanding receivables); a safety page (FLHAs, mitigations, worker sign-offs — audit-ready); a maintenance page (servicing, wear items, overdue work); and a company inventory page tied to a materials price tracker. Same dark aurora branding. Read-only onto the spine — it shows, the brain does. (how it plugs in)
flowchart LR
FA["Field app — the crew's hands"] --> INBOX["App Inbox"]
INBOX --> MCP["Evolved MCP — the brain, 85 tools"]
MCP --> WB["Workbook spine — Google Sheets, 25 tabs"]
MCP --> CHAIN["On-chain settlement — X Layer testnet"]
WB -.->|source of truth| MCP
WB --> DASH["Owner dashboard — the owner's eyes"]Stand up the whole thing for your own company — your workbook, your router, your field app, your dashboard, your MCP, nothing of Evolve's: docs/STAND-UP-YOUR-OWN.md. The MCP + workbook is an afternoon; adding the crew and owner surfaces is a weekend. Every piece is MIT, free, and optional.
Open source, all MIT — the system reads as one thing from whichever repo you land on first. How the four surfaces actually integrate (the shared workbook spine, the two auth paths, and an honest verified-vs-aspirational status): docs/INTEGRATION.md.
Repo / surface | Role | Link |
evolved | 🧠 The MCP brain — 85 tools, the workbook spine, the on-chain rail, the trade packs (this repo) | |
evolve-field-app | ✋ The crew's hands — tap-once field capture, $0/month on Apps Script | |
evolve-ops-workbook | 📊 The spine — a 25-tab workbook template + the secret-gated Apps Script router the human surfaces read through (generate your own secret) | kr8tiv-ai/evolve-ops-workbook · in-repo: |
evolve-dashboard | 📈 The owner's eyes — login-protected finance/ops dashboard (runs credential-free in demo mode), live at ops.evolveecoblasting.com | |
evolvedmcp-cloud | 🌐 The landing page + zero-install Judge-Mode playground (the site at www.evolvedmcp.cloud) |
Related Evolve-brand repos: kr8tiv-io/Evolve-Rebrand (the identity system) and kr8tiv-io/evolve-lifestyle (the apparel arm) — the brand this operating system runs under.
Full guide with commands and effort estimates: docs/STAND-UP-YOUR-OWN.md. In short:
Your ops workbook (required, ~10 min) — node scripts/make-workbook-template.mjs <trade> "My Company" → import the 20 CSV tabs into a Google Sheet.
Your MCP (required, ~20 min) — clone this repo, point any MCP client at it (CONNECT.md), and franchise_spinup your trade. You now have an agent-run business.
Your router (optional, ~30 min) — deploy the Apps Script router from evolve-ops-workbook (router.gs) as a web app with your own generated secret; the field app and dashboard read through it.
Your field app (optional, ~20 min) — deploy evolve-field-app, point it at your router.
Your dashboard (optional, ~30 min) — deploy evolve-dashboard (it runs credential-free in demo mode first — npm install && npm start), then point it at your router and set your own login.
The MCP + workbook is an afternoon; adding the crew and owner surfaces is a weekend. Everything is optional and independent — stop after any step.
Four surfaces, one loop, all open source and free — and it begins at the MCP. The brain runs the company; the field app, the workbook, and the dashboard are how real people touch the same system. Blasting is just the proving ground — franchise_spinup makes it any service business in one call.
flowchart LR
A["Lead — typed, voice, or photo"] --> B["Priced quote — learning rates + profitability check"]
B --> G1{{"HUMAN GATE: approve the quote"}}
G1 --> C["E-sign — HMAC token, declines are final"]
C --> D["Booked on the first good blast day — weather-gated"]
D --> E["FLHA drafted — hazards + mitigations from scope"]
E --> F["Work done — actuals, inventory burn-down, receipts"]
F --> H["Invoice — deposit applied"]
H --> I["On-chain payment — EIP-681 on X Layer testnet, replay-protected"]
I --> G2{{"HUMAN GATE: confirm settlement"}}
G2 --> J["Review request + rate engine taught"]
J -.->|smarter pricing| BEvery step lands in an audit log. Try it through any MCP client: lifecycle_start, then lifecycle_advance { approveQuote: true, esignSigner: "..." }, then lifecycle_advance { simulatePayment: true } — or hand it a real X Layer testnet txHash and watch the read-only RPC verification confirm it.
A blasting crew buys media and fuel before the first grain hits the driveway. A trades business lives or dies on cash flow and finality, and that is exactly what on-chain settlement fixes:
Instant. The deposit clears in seconds — not a 3-day e-transfer hold or a 30-day net invoice. The abrasive and fuel get funded today, so the agent can book the crew now.
Final. No chargebacks. A card can reverse weeks later, after the media is already blasted onto someone's concrete and the cost is sunk. On-chain, paid is paid.
Programmable. The 25% deposit is enforced in code and encoded into the EIP-681 request (invoice_payment_request { split: "deposit" }) — not a number a human has to remember to collect.
Self-verifying. The agent confirms the money landed itself via read-only RPC before it commits the crew — no waiting on a person to check the bank.
For a cash-tight trade, that is not a feature. It is the difference between taking the job and turning it down.
TESTNET ONLY — and Evolved never holds keys, never signs, never broadcasts. It issues payment requests and verifies settlement with read-only RPC; funds can only move from the payer's own wallet, and replay protection guarantees one transaction settles exactly one thing.
Rail | What happens |
SMB invoices settle on-chain |
|
Built-in x402 rail (opt-in) | A rail any adopter can switch on for their own deployment: |
Simulated mode is the default so judges can run everything offline, and every simulated settlement says so; EVOLVED_X402_MODE=live fails closed and demands real testnet transactions. Full protocol detail: docs/ONCHAIN.md. Pinning your own real testnet settlements is a two-command runbook: docs/GO-LIVE-ONCHAIN.md.
📸 Photo-to-quote | A customer texts a photo; |
🎙️ Voice field commands | "Used four bags of crushed glass on the Kowalczyk job" burns down inventory against that job's P&L. "Open the FLHA" drafts the day's hazard assessment. "Next stop?" reads the dispatch board. Unmatched job hints refuse rather than guess, and unrecognized speech is captured to the inbox — nothing is lost, nothing is misfiled. |
📈 Agentic CFO |
|
📦 Franchise spin-up |
|
The company is swappable — and not just its name. franchise_spinup { tradePack: "pressure-washing", confirm: true } re-seeds the entire OS for another trade: its own rate card in the quoting engine, its own hazards in every FLHA the system drafts, its pricing unit (sqft / hour / unit / vehicle / flat — a detailer prices per vehicle, not "per 100 sqft of car"), its currency and tax label (GST / VAT / HST / Sales Tax — a US or EU shop never forks the code), and its own policy notes (no blasting boilerplate leaks in). Three packs ship today (pressure-washing, line-painting, mobile-detailing); add yours as one entry in src/trades.ts — or pass a whole customPack (labels + hazards) inline in one call, no fork. Full turnkey path: docs/ONBOARDING.md. And the server speaks the whole MCP spec, not just tools: resources (evolved://rate-table, evolved://hazard-library, evolved://trade-packs) and prompts (morning-briefing, quote-a-job, run-the-lifecycle) come built in, so any MCP client gets one-line entry points. The 10-minute adaptation guide: docs/ADAPT.md. Security posture and threat model: SECURITY.md.
Everything the live field app and ops workbook do, as first-class tools: inventory control (par levels, reorder suggestions priced from real COD receipts, per-job burn-down, supplier price-spike watch), contacts/CRM (customers with balances, suppliers with pricebooks, crew with certifications), the ops-sheet engine (the data spine rendered as the operations workbook — the field App Inbox with a deterministic filing engine), accounting depth (tiered-OCR receipts with vendor canonicalization and duplicate guards, discrepancy reports, escalating receivables reminders, P&L with reclaimable GST), the workbook spine (a real Google Sheets workbook created and synced from the database, or the same 25 tabs as CSV with zero credentials), field operations (before/after photo albums with gap detection, voice and text field notes that never get lost, a crew time clock that feeds real labor cost into Job P&L, and hazard assessments authored ON-SITE by the crew — auto-drafts are only starting points), and growth (review requests with a tracked response rate, the reputation ledger and testimonial bank, the Job P&L scorecard with win rate and overall margin, and the live dispatch board).
A reader should finish this knowing exactly what the system runs, not a teaser. All 85 tools, grouped by what they do for a business:
Quoting intelligence — price any job with a rate engine that learns: a $/unit rate per tier that converges toward what actually wins work at healthy margins, a confidence score and a suggested price range that tightens with data, a market-band benchmark so a quote is never blind, and a full profitability check (media, labour, fuel, overhead, break-even rate, margin verdict). Create the quote, render the branded document, track its status, and teach the engine from the outcome.
Photo-to-quote — a customer texts a photo; the system estimates surface, area, condition, and tier, then returns a confidence-banded price range grounded in comparable jobs already in the books, a market benchmark, and the site factors that could move it — before booking a branded draft with a measure-to-confirm clause.
Invoicing & receivables — turn a job into an invoice with the deposit applied, render it, chase it: escalating reminders, receivables aging, and a running balance-due per customer.
Receipts → books — ingest a receipt through tiered OCR (escalates the hard ones), reconcile subtotal + tax = total, categorise it, canonicalise the vendor, guard against duplicates, and roll it into expenses, per-job cost, and the P&L (with reclaimable tax broken out).
Job & lead tracking — a full pipeline (lead → contacted → quoted → won/lost), a dispatch board bucketed by real job statuses with today's work and unscheduled-but-paid flags, and job scheduling/completion with actuals capture.
Inventory control — media, coatings, PPE, and consumables on hand with par levels and reorder points, per-job burn-down, receive-against-receipt, reorder suggestions priced from real purchase history, and a supplier price-spike watch.
Contacts / CRM — customers with balances, suppliers with pricebooks, and crew with certifications and hourly rates.
Safety & FLHA — draft the day's field-level hazard assessment from the job scope with per-hazard mitigations and standard PPE, capture it on-site, sign it off per worker, and escalate a hazard immediately — an uncleared stop-work outranks every money flag on the board. Audit-ready records.
Proactive alerts & the daily loop — a morning digest that reads like the real 6 AM email: the one thing not to drop, today's jobs and the next few days' schedule, money pulse, deposits gating work (money in but unscheduled, accepted work awaiting a deposit), quotes out, leads, top to-dos, and low-inventory reorder alerts — backed by an action-item "ball-drop" scanner (deposit unscheduled, invoice unpaid, quote expiring, job done but not invoiced), a weather-gated booking check, and a live snapshot. The brain surfaces what needs you before you go looking.
Business intelligence — proactive, computed insights, not records: inventory drawdown (days of runway until each item hits its reorder point at current burn) and low-stock alerts; spend by category with month-over-month trend and the biggest cost driver; rising supplier prices from the materials price tracker (which materials are creeping up, and where a bulk buy locks the lower rate before the next big job); and job-margin anomalies below the healthy floor — each with a ranked, concrete recommendation. It runs the business, it doesn't just log it.
CFO forecasting — model add-a-truck (capex, utilisation ramp, break-even month), rate changes with price elasticity, and demand shocks over a 12-month cash table grounded in the books and weather-gated seasonality; plus a financial-health one-pager (receivables aging, customer-concentration risk, run-rate).
Field operations — before/after photo albums with gap detection, voice and text field notes that never get lost, a crew time clock that feeds real labour cost into Job P&L, and JHAs authored on-site.
Voice commands — "used four bags of crushed glass on the Kowalczyk job" burns down inventory against that job; "open the FLHA" drafts the hazard assessment; "next stop?" reads the dispatch board. Unmatched job hints refuse rather than guess.
Growth — post-job review requests with a tracked response rate, a reputation ledger and testimonial bank, and a Job P&L scorecard (quoted vs actual, win rate, overall margin, average $/unit).
On-chain settlement — turn an invoice into an EIP-681 payment request in test OKB on OKX X Layer, verify settlement with read-only RPC (replay-protected, never holds keys), and monetise the agent itself with an opt-in x402 pay-per-call rail.
The workbook spine — render the whole operation as a real Google Sheets workbook (created and synced via service account) or the identical 25 tabs as a zero-credential CSV bundle.
Business-in-a-box & trade packs — franchise_spinup re-seeds the entire OS for any trade in one call (rate card, hazards, pricing unit, currency, tax label, policy notes), franchise_preview window-shops a pack safely, brand_configure makes rendered documents feel like your company, and daily insights train on the owner's feedback. Backups, activity feed, and demo reset round it out.
Named-tool reference below; full parameter-level docs (generated from the live server so they can't drift): docs/TOOLS.md.
Domain | Tools |
Quoting intelligence |
|
Money |
|
Pipeline |
|
Safety (FLHA) |
|
Autonomous ops |
|
Inventory control |
|
Contacts / CRM |
|
Ops-sheet engine |
|
Accounting depth |
|
On-chain (X Layer testnet) |
|
Autonomous lifecycle |
|
Frontier |
|
Business-in-a-box |
|
Workbook spine |
|
Field ops |
|
Growth |
|
Parameter-level reference, generated from the live server so it cannot drift: docs/TOOLS.md.
Three layers, dependencies pointing one way: tools validate and delegate, engines compute, the store persists. Swap the trade pack and every layer follows.
src/
├── index.ts stdio entry — plug into Claude Desktop / any MCP client
├── http.ts · app.ts Streamable HTTP: /mcp (free) · /mcp-paid (x402) · /health · /stats
├── server.ts assembles all 85 tools + 4 MCP resources + 3 prompts
├── playground.ts the zero-install browser playground (Judge Mode lives here)
├── tools/ 16 domains — thin, zod-validated handlers (quoting, money, pipeline,
│ safety, inventory, contacts, sheet, accounting, payments, lifecycle,
│ vision, voice, cfo, ops, opsplus, workbook, field, growth)
├── engine/ pure business logic — pricing + learning loop, OCR, safety/FLHA,
│ weather gating, digest, actions (ball-drop rules), CFO, NLU (voice),
│ vision, x402/X Layer payments, brand rendering, and the Google
│ Sheets workbook spine (service-account JWT via node:crypto, no SDK)
├── trades.ts trade packs — the one file you touch to adapt Evolved to your trade
├── seed.ts · store.ts synthetic workbook-shaped data spine (JSON, git-ignored at runtime)
└── test/ 52 tests — engines, E2E lifecycle, x402 over HTTP, live testnet probeHosted, nothing to install — point any MCP client at the live server through the mcp-remote bridge:
{ "mcpServers": { "evolved": { "command": "npx", "args": ["-y", "mcp-remote", "https://www.evolvedmcp.cloud/mcp"] } } }Local, fully offline (after git clone … && npm install && npm run build):
{ "mcpServers": { "evolved": { "command": "node", "args": ["<path-to>/evolved/dist/index.js"] } } }Works with Claude Desktop, Claude Code, Cursor, OpenClaw, Hermes, Codex — anything that speaks MCP. Every tool ships MCP annotations (readOnlyHint / destructiveHint / openWorldHint) so your client knows what's safe to call before it calls it. Full copy-paste guide for each client: docs/CONNECT.md. HTTP mode (npm run start:http) serves the free tier at POST /mcp, the x402 tier at POST /mcp-paid, and GET /health. Optional live upgrades: ANTHROPIC_API_KEY (real vision and OCR escalation), EVOLVED_LIVE_WEATHER=1 (real forecasts), EVOLVED_X402_MODE=live (require real testnet transactions), EVOLVED_PAYTO=0x… (your testnet receiving address).
Then ask it things a business owner would:
"Run the morning digest. What am I about to drop?" "A property manager wants a 2,100 sqft parkade level profiled, tight access — price it, and if the margin is healthy, create the quote and render the document." "Should I buy a second truck this fall?"
npm test
# ✔ pricing: learning loop pulls driveway medium toward ~$9/sqft, never below base
# ✔ ocr: comma thousands-separator regression (the production P0 bug)
# ✔ autonomous lifecycle: lead → e-sign → weather booking → FLHA → invoice → on-chain settle → review → learning
# ✔ x402 over real HTTP: 402 challenge, then simulated proof unlocks the MCP surface
# ✔ X Layer testnet RPC: live read-only probe (chainId 1952 asserted)
# ✔ review fixes: replay protection, declined e-sign is final, custom price break-even flag
# ✔ franchise spin-up re-seeds the OS for a new trade
# ✔ pricing: confidence rises with data, quote range tightens, market benchmark flags under/over
# ✔ workbook: 25 tabs cover the whole OS; CSV export writes real files; no-creds create falls back
# ✔ field ops: photo album gaps, note routing to the inbox, time clock feeds Job P&L labor
# ✔ safety: the JHA is authored on-site — field capture creates or upgrades the day's FLHA
# ✔ growth: review loop, reputation ledger, dispatch board flags, brand config, pack preview
# ✔ security: replay claim is atomic under concurrency; destructive tools fenced off the shared endpoint
# ✔ adaptability: an inline trade pack spins up a new trade; an adapted trade quotes in its own unit (per vehicle, not sqft)
# ✔ workbook drives the admin dashboard: 25 tabs, all 17 dashboard entities verified end-to-end
# ✔ resilience: bounded mkdir cannot busy-loop; digest surfaces to-dos; sheet engine mirrors all 25 tabs
# ✔ proactive alerts + business intelligence: rising prices, spend MoM, inventory drawdown — real computed insight
# … 52 passingThe battle scars are real and documented: the production receipt parser once read a $1,250 media invoice as $1.25 — that comma bug is fixed here and pinned by regression tests, along with 28 other adversarial-review findings shipped in f6acd80 (replay protection, decline finality, break-even flagging, and the long tail). Architecture, data model, and production lineage: docs/ARCHITECTURE.md.
Matt Haynes — Operations & Marketing Manager at Evolve Eco Blasting and founder of KR8TIV AI (Edmonton, Alberta). Not a lab researcher — a real-world operator who runs the back office of a mobile abrasive-blasting crew and builds the AI that runs it. Evolved is the portable, open-source form of that system: after a live field app (kr8tiv-ai/evolve-field-app), an ops workbook, and a full rebrand, reimagined as an MCP service any trade can install in one call.
"You give to get. You work something out, and you leave the gate open for the next person."
That conviction is why Evolved is MIT and free. On the roadmap: stronger back-office systems, robotics to make the hardest jobsite work safer, and manufacturing beyond.
With Todd — owner-operator of Evolve Eco Blasting — whose real company, real rates, real safety practice, and real ball-drop rules are the production truth the entire demo runs on. Evolved isn't a hypothetical; it's the software a working crew uses, made portable for everyone.
github.com/Matt-Aurora-Ventures · linkedin.com/in/matthaynes88 · kr8tiv.io · Edmonton, Alberta 🇨🇦
Built for the OKX AI Genesis Hackathon by Matt Haynes (KR8TIV AI) from the live operations system of Evolve Eco Blasting, July 2026.
Try it live | www.evolvedmcp.cloud — browser playground, zero install |
Stand up your own | docs/STAND-UP-YOUR-OWN.md — the whole system for your company (afternoon → weekend) · quick path: ONBOARDING.md |
The four surfaces | 🧠 MCP (this repo) · ✋ field app (docs) · 📊 workbook + router template · 📈 dashboard (ops.evolveecoblasting.com, docs) |
Connect your agent | docs/CONNECT.md — copy-paste config for Claude Desktop, Claude Code, Cursor (hosted or local) |
Live endpoint |
|
Listing | A2MCP ASP with an implemented x402 paid tier — docs/OKX-LISTING.md |
Demo script | Two-act 90-second cut — docs/DEMO.md |
Demo video | submission/evolved-demo.mp4 — 90s, 1080p, on-brand, captioned, royalty-free funk soundtrack (notes) — streams from the live deployment at /demo.mp4 |
Categories | Best Product · Revenue Rocket · Software Utility · Finance Copilot |
MIT licensed. Synthetic data only; testnet only; no secrets anywhere in this repository. Evolved never holds keys and cannot move funds — by construction.
Mark an action item handled. It leaves the digest and the open list.
| Name | Required | Description | Default |
|---|---|---|---|
| resolution | No | ||
| actionItemId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one behavioral trait: it leaves the digest and open list unchanged. However, with no annotations, more detail about side effects, reversibility, or permissions would be helpful. The tool is a mutation, but the description provides minimal behavioral transparency beyond the stated effect.
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 extremely concise with two sentences, no wasted words, and front-loaded purpose. It is well-structured and easily parsed by an AI agent.
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?
Lacks information on return values, preconditions (e.g., action item must exist), error states, or confirmation of success. Given the simplicity of the tool, some additional context on outcomes would improve completeness.
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 0%, and the description does not mention any parameters. The two parameters (actionItemId, resolution) have no explanation in the description, leaving the agent to infer meaning solely from the schema names, which may be ambiguous.
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 'Mark an action item handled' with a specific verb and resource. The additional phrase 'It leaves the digest and the open list' adds context about the tool's effect, distinguishing it from sibling tools like action_items_scan.
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?
No guidance on when to use this tool versus alternatives (e.g., when to not use it, prerequisites, or related tools like action_items_scan). The description only states what the tool does without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the ball-drop catcher across the books. Auto-raises items for: deposit in but unscheduled, invoice unpaid 7+ days, quote unanswered 7 days, quote expiring within 7 days, job complete but not invoiced, and open leads with stale next actions. Deduplicates against items already open.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that the tool auto-raises items (mutational behavior) and deduplicates against already open items. With no annotations, this provides essential behavioral context. However, it does not mention permissions, rate limits, or whether multiple runs cause duplicate items.
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 efficiently convey the tool's function and conditions. The list of trigger conditions is well-structured and easy to parse. No unnecessary words 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?
While the description explains what the tool detects and deduplicates, it omits any mention of return values or results. Given no output schema, describing the output (e.g., list of raised items or confirmation) would improve completeness.
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?
No parameters exist, so the description does not need to add parameter semantics. The baseline score of 4 applies as the schema coverage is 100%.
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 identifies the tool's purpose as scanning for 'dropped balls' (action items) and specifies exactly which conditions trigger automatic raising of items. It distinguishes from sibling tools like action_item_resolve by focusing on detection rather than resolution.
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 proactive identification of overdue or stale items but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. Sibling tool action_item_resolve suggests complementary use, but no guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything on one screen: funnel counts, money position, open safety items, and open action items. The health check an investor or owner asks for first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. The description suggests this is a read-only overview with no side effects, but it does not explicitly confirm read-only behavior or disclose any potential side effects, leaving some ambiguity.
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 extremely concise with two sentences. It front-loads the key contents in the first sentence and adds context in the second. Every word serves a purpose, with no redundancy.
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 no output schema and zero parameters, the description adequately explains what the tool returns (aggregate counts and items). However, it could be more complete by mentioning data freshness or refresh behavior, but for a snapshot tool this is sufficient.
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 has zero parameters and 100% schema coverage (empty schema). The description adds no parameter information, but with no parameters, the baseline of 4 is appropriate as there is nothing further to clarify.
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 what the tool does: it provides a snapshot including funnel counts, money position, open safety items, and open action items. It also gives context as a health check for investors or owners, effectively distinguishing it from sibling tools that focus on individual lists or actions.
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 as a starting point ('the health check an investor or owner asks for first'), but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Customer book with contact details and their quotes/jobs at a glance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral details such as pagination, sorting, or whether the tool is read-only. For a tool with no annotations, the description should carry more burden.
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?
Single sentence, front-loaded, no unnecessary words. Efficient and to the point.
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 simple list tool with no parameters and no output schema, the description adequately conveys the content. Minor gaps exist around pagination or filtering, but overall sufficient.
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?
No parameters exist, and schema coverage is 100%. The description adds value by explaining the output includes contact details and quotes/jobs, going beyond the empty 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?
The description clearly states it provides a customer book with contact details and associated quotes/jobs, reinforcing the name and title. However, 'customer book' is slightly vague and does not differentiate from sibling tools like quote_list, though the focus on customers is unique.
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?
No guidance on when to use this tool vs alternatives like quote_list or pipeline_view. The description only states what it does without any context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore the synthetic demo dataset to its seeded state (all names, numbers, and dollar figures are invented). Useful between demo runs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a destructive action (restoring to seeded state) but does not explicitly state that current data is overwritten or lost. The mention that data is synthetic adds context but not behavioral detail. A more explicit warning about data loss would improve transparency.
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 with no wasted words. The action is front-loaded in the first sentence, and the usage context is provided in the second. Every sentence serves a purpose.
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 zero-parameter tool with no output schema, the description fully covers what the tool does and when to use it. It explains the synthetic nature of the data, which is useful context. No additional information is required for an AI agent to select and invoke this 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?
The input schema has zero parameters and 100% coverage. With no parameters to describe, the baseline score of 4 applies. The description adds no parameter information, as none is 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 clearly states the action: 'Restore the synthetic demo dataset to its seeded state'. It specifies the resource (synthetic demo dataset) and the verb (restore). The sibling tools are business-oriented (e.g., invoice_create, lead_capture), making this tool distinct as a demo reset.
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 includes explicit usage context: 'Useful between demo runs.' This tells when to use it. No exclusions or alternatives are mentioned, but given the tool's simplicity and uniqueness among siblings, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expense breakdown by category and vendor for a month (YYYY-MM, default current). Shows OCR provenance and reclaimable GST — the bookkeeping view an accountant actually wants.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does not explicitly state that the tool is read-only, non-destructive, or what permissions are required. While the output characteristics are described, behavioral traits like safety or side effects are missing.
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, well-structured sentence that front-loads the purpose and immediately provides key details. No redundant or irrelevant information is present.
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 absence of an output schema, the description adequately explains the return contents (breakdown by category/vendor, OCR provenance, reclaimable GST) and default behavior. It is sufficient for an agent to understand the tool's output, though some minor specifics like total amounts might be inferred.
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 only parameter 'month' has 0% schema description coverage, but the description compensates by specifying the format (YYYY-MM) and default behavior ('default current'). This adds meaningful guidance beyond the raw 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?
The description clearly states the tool returns an 'expense breakdown by category and vendor' with specific details like OCR provenance and reclaimable GST. It uses a specific verb ('breakdown') and resource ('expense report'), and distinguishes itself from sibling tools by targeting a bookkeeping perspective.
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 viewing expenses in a monthly breakdown, but does not explicitly state when to use this tool versus alternatives like invoice_create or quote_list. No when-not conditions or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the day's FLHA for a job before work starts. Drafts the hazard list automatically from the job scope using the abrasive-blasting hazard library — each hazard comes with specific mitigations, not boilerplate — plus standard PPE and a muster point. Crew adds site-specific hazards on top. No FLHA, no blasting.
| Name | Required | Description | Default |
|---|---|---|---|
| crew | Yes | ||
| jobId | Yes | ||
| openedBy | Yes | ||
| musterPoint | No | ||
| extraHazards | No | Site-specific hazards the crew identified | |
| siteConditions | Yes | Weather, ground, traffic, occupancy — what the crew sees on arrival |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses auto-drafting of hazards, inclusion of PPE and muster point, and crew add-ons. Missing details: return value (e.g., FLHA ID), error handling (e.g., duplicate FLHA), and what happens if job scope is unavailable.
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 four sentences with zero waste. Each sentence provides unique information: opening action, auto-drafting, crew additions, and necessity. Front-loaded with the main action.
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 6-parameter tool without output schema, the description covers the workflow well but omits the return value (likely an FLHA ID) and does not address idempotency or error conditions. Not fully complete for confident agent 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 low (33%), so description must compensate. It explains that extraHazards are 'site-specific hazards' and implies siteConditions describes on-site factors. However, required fields like jobId, crew, and openedBy are not elaborated beyond schema types, so added value is moderate.
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 opens the day's FLHA for a job before work starts, automatically drafting hazards from a specific library. It distinguishes from siblings like flha_signoff by focusing on the opening step.
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 says to use it 'before work starts' and emphasizes necessity with 'No FLHA, no blasting.' However, it does not explicitly exclude cases when not to use it or mention alternatives, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the day's FLHA: every crew member signs, incident status is recorded, and the assessment becomes part of the job's permanent safety record. Flags any crew member who has not signed.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| flhaId | Yes | ||
| signedBy | Yes | ||
| incidentFree | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: mandatory crew sign-off, incident status recording, permanent storage, and flagging of unsigned members. With no annotations, this provides sufficient transparency for a write operation.
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 succinct sentences with no extraneous text. Front-loaded with verb 'Close' and resource. Every sentence 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?
Covers core purpose and behavior, but lacks details on flhaId (required), notes, and output/return behavior. No output schema provided, so description should fill gaps more thoroughly.
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?
Adds meaning for signedBy (crew sign-off) and incidentFree (incident status), but flhaId and notes are not described. Schema has 0% coverage, so partial compensation.
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?
Description clearly states it closes the day's FLHA, includes signing, incident recording, and permanent safety record. Distinguishes from sibling tools like flha_open by specifying end-of-day closure and flagging unsigned crew members.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., safety_log). Does not specify prerequisites like requiring an open FLHA or when to avoid use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoice a completed job: pulls the quote lines, applies the deposit already collected, computes 5% GST and the balance due (net 14). Marks the job Invoiced.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| extraLines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool writes data (marks job as Invoiced) but lacks details on idempotency, side effects, permissions, or return value.
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 concise sentences with no wasted words. Front-loaded with the primary action.
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 simple tool with 2 params and no output schema, the description covers most key aspects but omits extraLines explanation and return value. Adequate but not complete.
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 has 0% description coverage; the description explains jobId implicitly but fails to mention the extraLines parameter, its purpose, or how to use 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 clearly states the action (create invoice from completed job) and specific details: pulls quote lines, applies deposit, computes GST and balance due, and marks job as invoiced. It differentiates from siblings like invoice_render and job_complete.
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 after job completion but does not explicitly state prerequisites or when not to use. No alternative tools are mentioned despite many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an invoice in the company's dark brand as a self-contained HTML document ready to print to PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (HTML) and intent (print to PDF), but fails to mention whether the tool is read-only, requires specific permissions, modifies state, or handles errors. Important behavioral aspects like side effects or auth needs are omitted.
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 sentence of 20 words that conveys the core purpose and output format concisely. No redundant information or filler. It front-loads the key action and resource, earning its place efficiently.
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 simplicity of the tool (1 param, no output schema), the description should address prerequisites (invoice existence), error behavior, and output structure. It does not mention what happens if the invoice is missing, if rendering requires certain state, or how the HTML is returned. The agent lacks sufficient context for robust use.
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 single parameter 'invoiceId' has no description in the schema (0% coverage). The tool description does not explain what this parameter represents, expected format, or constraints. The parameter name is self-explanatory but the description should clarify it, e.g., 'The unique identifier of the invoice to render.' This omission forces the agent to guess.
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 verb 'Render', resource 'invoice', and output format 'self-contained HTML document ready to print to PDF'. While specific, it does not explicitly distinguish this tool from the sibling 'quote_render', which likely serves an analogous purpose for quotes. The purpose is strong but lacks sibling differentiation for a perfect score.
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 provides no guidance on when to use this tool versus alternatives (e.g., 'invoice_create', 'quote_render'). There is no mention of prerequisites, suitable contexts, or when not to use the tool. The agent is left to infer usage from the bare description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close out a job with real numbers: hours, crew size, materials, fuel. Computes wages from the loaded crew rate, total cost, profit, margin, and a verdict — then feeds the per-job P&L. Follow with pricing_record_outcome to teach the quoting engine, and invoice_create to get paid.
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | Yes | ||
| jobId | Yes | ||
| revenue | Yes | Job revenue before GST (usually the quote subtotal) | |
| crewSize | Yes | ||
| materials | Yes | ||
| hoursWorked | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool computes wages, cost, profit, margin, and verdict, and feeds the P&L. However, it does not specify side effects like status changes or idempotency, which are relevant for a completion action.
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, front-loaded with the core action. The second sentence adds computational context and workflow guidance. No wasted words.
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 has 6 required parameters, no output schema, and no annotations, the description adequately explains the process and outcomes. It lacks details on prerequisites or error handling, but it is fairly complete for the complexity level.
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 only 17%, so the description should compensate. It lists 'hours, crew size, materials, fuel' as the parameters but does not detail them individually (e.g., units, constraints). Revenue is mentioned but not explained in the description (schema has a description for it). JobId is omitted entirely. The description adds some but not enough context.
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 verb 'Close out a job' and specifies the resource (job) with the real numbers used. It distinguishes from siblings by mentioning the follow-up steps (pricing_record_outcome, invoice_create), which are separate tools.
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 explicitly says when to use this tool (to close out a job with real numbers) and provides follow-up actions. It does not list alternatives or when not to use, but the sibling list suggests no other tool serves the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book a job onto the dispatch board: date, crew, deposit status. Moves it along Awaiting acceptance → Booked → Confirmed → In progress. Checks the blast-day weather verdict for the chosen date.
| Name | Required | Description | Default |
|---|---|---|---|
| crew | No | ||
| jobId | Yes | ||
| status | No | ||
| depositPaid | No | ||
| scheduledDate | Yes | YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses status transitions and weather checks but does not mention side effects, permissions, or error conditions.
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 convey key actions without unnecessary fluff, but the second sentence could be more precise about the status transitions.
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?
Lacks details on output/return values and does not specify behavior when weather check fails or when scheduling conflicts occur.
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 adds meaning by mentioning date, crew, and deposit status, but relies heavily on the schema. Schema coverage is only 20%, and the description does not fully explain all parameters or the workflow around the status enum.
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 it schedules a job by setting date, crew, and deposit status, moves through specific statuses, and checks weather. This distinguishes it from siblings like job_complete and weather_check.
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 scheduling but does not explicitly state when to use this tool over alternatives like weather_check for weather checks or job_complete for completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a new lead into the sales funnel (New → Contacted → Site visit → Quoted → Won/Lost). Creates the customer record if needed. Company rule: every open lead carries a NEXT ACTION with a date — this tool enforces it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Customer or company name | |
| No | |||
| phone | No | ||
| source | Yes | Where the lead came from (referral, website, phone, ...) | |
| address | No | ||
| summary | Yes | What they want, in one line | |
| nextAction | Yes | The concrete next step | |
| nextActionDate | No | YYYY-MM-DD, default tomorrow |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions creating customer record and enforcing next action rule, but lacks details on error handling, idempotency, or duplicate handling.
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 front-load purpose and key rules; no unnecessary words.
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?
Adequately describes core function and rule for an 8-parameter tool with no output schema, but could benefit from mentioning return value or handling of duplicates.
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 63%. Description adds context for summary and nextAction but does not cover email, phone, or address parameters beyond their 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?
Description clearly states 'Log a new lead into the sales funnel' with a specific stage progression and distinguishes from siblings like lead_update.
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?
Implies use for initial lead capture and enforces a company rule about next action; does not explicitly state when not to use or name alternatives, but lead_update is a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a lead through the funnel and refresh its next action. Won/Lost closes it out.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| stage | No | ||
| leadId | Yes | ||
| nextAction | No | ||
| nextActionDate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses key behaviors: moving through stages, refreshing next action, and terminal states (Won/Lost). However, it does not address the effects on notes or nextActionDate, or whether changes are reversible. Adequate but not comprehensive.
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, front-loaded with the primary action. No extraneous words. Every sentence serves a purpose: stating the core function and highlighting terminal behavior.
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 5 parameters, no output schema, and no annotations, the description covers the main workflow (stage progression, next action) but omits notes and nextActionDate context. It is adequate for basic use but leaves gaps for a new agent unfamiliar with CRM concepts.
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 0%, so the description must add meaning. It explains stage (funnel movement, close-out) and nextAction (refresh). But it does not explain notes or nextActionDate, leaving some parameters underspecified. The description adds some value beyond schema names but is incomplete.
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 purpose: 'Move a lead through the funnel and refresh its next action. Won/Lost closes it out.' It uses a specific verb ('move,' 'advance') and resource ('lead'), and distinguishes from sibling tools like lead_capture (creating leads) and pipeline_view (viewing).
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 (to advance a lead stage, refresh next action, or close via Won/Lost). While it does not explicitly exclude scenarios or name alternatives, the context is clear given sibling tool names (e.g., lead_capture for new leads).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 6:30 AM owner briefing, on demand: the one thing not to drop today, today's jobs with crews, money pulse (month revenue, expenses, receivables), quotes out with age, leads needing a touch, auto-raised action items, five-day blast-day weather verdicts, and system health. One call, whole business.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It thoroughly lists what the tool returns, indicating it is read-only and aggregate. No destructive or side effects are mentioned, which is appropriate for a read-only tool.
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 key concept 'The 6:30 AM owner briefing, on demand' and then bulletizes content. Slightly verbose but every sentence 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?
Given no output schema, the description must cover return values, which it does exhaustively. For a no-parameter, no-output-schema tool, the description is fully complete.
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 has no parameters, so the description serves as the sole explanation of what the tool does. It fully compensates by enumerating all aspects of the digest. Baseline for 0 params is 4.
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 it's an on-demand owner briefing tool that returns a comprehensive set of business metrics and alerts. The verb 'morning_digest' combined with the list of contents makes the purpose unmistakable.
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 it is the primary tool for a daily business overview but does not explicitly state when to use it versus alternatives. No exclusion criteria or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The whole funnel at a glance: open leads by stage with next actions, quotes out with age, and jobs by dispatch status. The first tool to reach for when asked 'where's the business at?'
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It describes a read-only view with specific data points, which is transparent. However, it doesn't mention data freshness, permissions, or aggregation details.
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 concise sentences front-load the key information without any wasted words.
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 zero-parameter, no-output-schema read-only tool, the description is completely adequate. It explains the view and when to use 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?
Zero parameters, so baseline is 4. Description adds no parameter info, but none is 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?
Description clearly states it shows the funnel overview with specific details (leads by stage, quotes age, jobs by dispatch status). It also positions itself as the go-to tool for a common business query, differentiating it from siblings.
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?
Explicitly states it's the first tool for 'where's the business at?' but does not provide when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profit & loss for a month or the whole book: revenue from paid invoices, expenses from the receipt ledger, per-job margins from recorded actuals, and the business scorecard (win rate, average $/sqft, overall margin).
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | YYYY-MM; omit for all-time |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It lists data sources (paid invoices, receipt ledger, actuals) and output components, but does not clarify whether data is real-time, cached, or if there are any limitations (e.g., only completed jobs). Some transparency is present, but gaps remain.
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 core purpose. Every phrase adds value without redundancy or fluff.
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 names key output components but does not specify the structure or format. Given no output schema, more detail (e.g., whether results are aggregated, grouped, or returned per job) would help completeness. It is adequate but not thorough.
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 only parameter 'month' has full schema coverage with a clear description. The description adds no extra meaning beyond the schema (e.g., format or default behavior), so the baseline score of 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 clearly states the tool returns profit & loss data, including revenue, expenses, per-job margins, and a business scorecard. It specifies the scope can be a single month or all-time, distinguishing it from siblings like expense_report which likely focus on expenses only.
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 the tool does but does not provide explicit guidance on when to use it versus siblings such as business_snapshot or pipeline_view. The agent must infer usage from the purpose, but no when-not or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the live rate table: base market rates by blast depth, the learned effective rates by surface (driven by real job outcomes at healthy margins), access factors, and the mobilization fee. This is the quoting engine's brain.
| Name | Required | Description | Default |
|---|---|---|---|
| surface | No | Show the learned rate for a specific surface |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It suggests a read-only operation ('Show the live rate table') but does not explicitly confirm that no modifications occur, nor does it disclose any side effects, permissions, or rate limits.
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 concise sentences with no wasted words. It is front-loaded with the main action and lists components clearly.
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 simple one-parameter read tool with no output schema, the description provides sufficient information about what the tool returns and its purpose. It covers the key components of the rate table.
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% (the only parameter 'surface' has a description explaining it shows the learned rate for a specific surface). The description adds context about the overall table but does not add significant meaning beyond the schema for the parameter.
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 it shows the live rate table including base market rates, learned effective rates, access factors, and mobilization fee. It uses specific verb 'Show' and resource 'live rate table', and implies it is the quoting engine's brain, distinguishing it from sibling tools like quote_price or pricing_record_outcome.
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 this tool is fundamental ('the quoting engine's brain') but does not explicitly state when to use it versus alternatives, nor does it provide exclusions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a job outcome (won/lost, quoted rate, actual cost per sqft, margin) into the pricing learning loop. Wins at healthy margins pull future quotes for that surface+depth toward what actually works — every job makes the next quote smarter.
| Name | Required | Description | Default |
|---|---|---|---|
| won | Yes | ||
| sqft | Yes | ||
| depth | Yes | ||
| jobId | Yes | ||
| surface | Yes | ||
| quotedRate | Yes | $/sqft quoted | |
| actualCostPerSqft | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explains that recorded outcomes influence future quotes via 'pricing learning loop', but does not disclose side effects (e.g., overwriting, need for authorization) or potential destructive actions. Still, the learning effect is transparently communicated.
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 — compact, front-loaded purpose, no wasted words. Efficiently conveys both action and motivational context.
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 7 required parameters, no output schema, and no annotations, description explains high-level purpose and learning impact but lacks details like return format, error conditions, or handling of duplicate records. Adequate for straightforward use but gaps remain.
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 low (14%) — only 'quotedRate' has a description. Description adds context (e.g., 'won/lost' maps to 'won' boolean, 'actual cost per sqft' maps to 'actualCostPerSqft') but omits 'margin' (calculated, not a parameter) and does not fully explain all enums. Adds meaning beyond schema for purpose but not for individual parameters.
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?
Description clearly states it records job outcomes (won/lost, quoted rate, actual cost per sqft, margin) into a learning loop. Title 'Teach the pricing engine' reinforces purpose. Distinguishes from siblings like 'pricing_rates' (which likely returns rates) and 'quote_create' (which creates quotes).
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?
Description implies usage after a job outcome is known, tying to a learning loop. Does not explicitly state when not to use or compare to siblings like 'job_complete', but context is clear for a feedback tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a formal quote in the books (auto-numbered ECO-Q-MMDDYY-NN, valid 30 days) for a customer, from one or more priced lines. Runs the profitability check and stores the verdict. If a custom price is below break-even it is honoured but flagged — never silently raised.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | ||
| notes | No | ||
| leadId | No | ||
| customerId | Yes | Existing customer id (see pipeline tools to create one) | |
| siteAddress | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses auto-numbering, 30-day validity, profitability check, and behavior for custom prices below break-even, providing comprehensive behavioral details.
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 efficiently convey key information with no wasted words, front-loaded with the core purpose.
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 covers numbering, validity, profitability, and custom pricing behavior, but does not specify what the tool returns (e.g., quote ID, status). Given no output schema, this is a minor gap.
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 20%, and the description adds minimal parameter-specific information beyond mentioning 'priced lines' for the lines array. It does not compensate for the low coverage.
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 creates a formal quote with auto-numbering and validity, and it distinguishes itself from sibling tools like quote_list and quote_update_status.
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 specifies it is for creating a quote for a customer from one or more priced lines, but does not explicitly mention when not to use or alternatives, though context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List quotes, optionally filtered by status. Includes totals, validity, and profitability verdicts.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes read-only listing with included details (totals, validity, verdicts), but provides no information on default status filter, pagination, ordering, or authentication. With no annotations, more detail would improve transparency.
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?
Single sentence that is clear, efficient, and front-loaded with essential information. No redundant words.
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 simple list tool with one parameter and no output schema, the description covers purpose, optional filtering, and key output fields. Lacks details on ordering or limits, but is adequate given the tool's simplicity.
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 0%, but description adds meaning by stating 'optionally filtered by status', clarifying the parameter's optional nature and role. The enum values are documented in the schema, so this is sufficient.
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?
Clearly states 'List quotes' with optional status filtering and mentions output includes totals, validity, and profitability verdicts. Distinguishes from siblings like quote_create and quote_update_status, but could better differentiate from other list tools like pipeline_view.
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?
Implies usage for listing quotes with optional status filter, but lacks explicit guidance on when to use this tool versus alternatives like quote_price or quote_render.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price an abrasive-blasting job with the company rate engine: learned $/sqft rates by blast depth and surface, access factor, mobilization, 5% GST, 25% deposit — plus a full profitability check (media, labor, fuel, overhead, break-even rate, margin verdict). Use this before creating any quote.
| Name | Required | Description | Default |
|---|---|---|---|
| sqft | Yes | Square footage of the work area | |
| depth | Yes | Blast depth required | |
| access | No | Site access difficulty (default easy) | |
| surface | No | Surface type (drives learned pricing) | |
| mobilization | No | Include the mobilization fee (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains the pricing components (rates, tax, deposit, profitability check) but does not disclose whether the tool has side effects (e.g., saving or caching). It implies read-only by saying 'Use this before creating any quote.'
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 at ~70 words, front-loads the purpose, and includes a critical usage instruction. It could be slightly more structured (e.g., bullet points), but it is efficient and 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?
The description explains inputs and the pricing logic well, but since there is no output schema, it fails to explicitly describe the return value (e.g., price breakdown, margin verdict). The mention of 'margin verdict' hints at output but does not confirm format.
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 baseline is 3. The description adds value by explaining how parameters drive the pricing engine (e.g., 'learned $/sqft rates by blast depth and surface', 'access factor'), enhancing understanding beyond the schema's descriptions.
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 'Price an abrasive-blasting job' with a specific verb and resource, and distinguishes from siblings like 'quote_create' by adding 'Use this before creating any 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?
The description provides a clear usage context ('Use this before creating any quote'), but does not explicitly exclude alternative tools like 'pricing_rates' or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a quote as a polished, dark-brand HTML document (Boreal Void page, Cyber Lime underline, Aurora Neon labels, diamond bullets, payment schedule with the big green total) ready to print to PDF and send. Returns the file path and the HTML.
| Name | Required | Description | Default |
|---|---|---|---|
| quoteId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the return values (file path and HTML) but lacks details on side effects (e.g., file storage location, overwrite behavior), authentication needs, rate limits, or what happens if the quote does not exist.
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 (one sentence) and front-loads the purpose. However, it includes very specific styling details (Boreal Void, Cyber Lime, etc.) that may be unnecessary for an AI agent deciding tool invocation, slightly reducing efficiency.
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 tool with one parameter and no output schema or annotations, the description is moderately complete. It indicates the output (file path and HTML) but lacks information on error handling, prerequisites, and potential side effects. The return value structure is vague.
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?
Only one parameter (quoteId) with 0% schema description coverage. The description does not explain the parameter beyond its name; it does not provide format, constraints, or examples, leaving the agent to infer its purpose from context.
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 action (Render a quote), the specific output (polished, dark-brand HTML document with detailed styling, returns file path and HTML), and distinguishes from sibling tools like invoice_render by specifying the brand styling.
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 rendering quotes but does not explicitly state when to use it versus alternatives (e.g., quote_create, quote_list) or when not to use it. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a quote through its lifecycle: Draft → Sent → Accepted/Declined/Expired. Accepting a quote automatically opens a job in the dispatch pipeline and marks the lead Won.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| quoteId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions that accepting opens a job and marks lead Won, but omits other status change side effects (e.g., notifications, lead updates for Decline/Expire), error handling, idempotency, or permissions. This leaves significant gaps.
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 consists of two concise sentences. The first sentence states the primary action and lifecycle path. The second adds a critical behavioral note. No redundant words.
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?
Tool is simple with 2 required parameters and no output schema. The description covers the main action and a key side effect, but lacks details on required parameters, valid transitions, error scenarios, and any constraints. Sufficient for basic understanding but incomplete for a robust agent selection.
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 0%, so the description should explain both parameters (quoteId and status). It does not mention quoteId at all and only implies status via the lifecycle but does not explicitly state that the 'status' parameter is the new value. The enum values are listed in the schema but not clarified in the description.
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 it updates the quote status through a lifecycle, and specifies valid transitions (Draft → Sent → Accepted/Declined/Expired). It distinguishes from sibling tools like quote_create, quote_list, etc., by focusing on status transitions.
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 advancing quote status, which is clear from the lifecycle mention. However, it lacks explicit guidance on when not to use it, prerequisites (e.g., quote must exist), or valid transition constraints (e.g., reverse transitions possibly not allowed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a receipt through the tiered extraction pipeline: fast model first, automatic escalation to a stronger model when confidence is low or the math does not reconcile. The result is categorized (media, fuel, equipment, safety gear, ...), optionally matched to a job for per-job P&L, duplicate-guarded, and posted straight to the expense ledger. Paper to books in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Raw receipt text (from a photo OCR or typed) | |
| jobId | No | Job to attribute this cost to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: tiered extraction, automatic escalation to a stronger model, categorization, job matching, duplicate guarding, and posting to the expense ledger. This is comprehensive.
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, front-loaded with the main action, and every phrase adds value. No wasted words.
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 no output schema and no annotations, the description provides a complete picture of what happens from input to output, including pipeline stages and side effects like duplicate guarding and ledger posting.
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%, and the description adds context by explaining that 'text' is raw receipt text and 'jobId' is for job attribution, tying them to the pipeline behavior. It does not add entirely new semantics but reinforces usage.
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: 'Run a receipt through the tiered extraction pipeline... Paper to books in one call.' It uses specific verbs and resources, and the tool is distinct from all sibling tools.
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 use for processing receipts and mentions key behaviors like automatic escalation, but it does not explicitly state when not to use it or compare to alternatives. However, no sibling tool offers similar functionality, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The FLHA history: open assessments needing sign-off, signed records, and incident flags across all jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It implies a read operation ('history') but does not explicitly state it is non-destructive, nor does it mention auth requirements, rate limits, or other side effects. This leaves agents uncertain about safety.
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, compact sentence with no redundancy. It efficiently conveys the main purpose, though minor additional detail could be added without harming conciseness.
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 simple tool with one optional parameter and no output schema, the description covers the return content adequately. However, it is incomplete regarding parameter behavior and usage context, leaving gaps for an agent to infer 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?
The single parameter 'jobId' lacks schema descriptions (0% coverage) and the tool description adds no explanation of its meaning, format, or impact. The phrase 'across all jobs' hints at filtering but is insufficient for correct usage.
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 identifies the tool as 'FLHA history' and lists its contents (open assessments, signed records, incident flags), distinguishing it from siblings like flha_open and flha_signoff. However, it does not mention the optional jobId parameter for filtering, slightly reducing clarity.
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?
No guidance on when to use this tool versus alternatives. The description implies usage for viewing history, but does not specify contexts or exclusions. Sibling tools suggest related actions, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Five-day forecast with blast-day verdicts (Good blast day / Marginal / No-go) using the company's gating thresholds: no blasting at precip ≥50%, wind >40 km/h, or highs below 3°C.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the gating thresholds (precip, wind, temp) that determine verdicts, and implies a read-only operation. It does not cover authentication or side effects, but the core behavior is transparent.
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, well-structured sentence that front-loads the purpose and includes key details (thresholds). Every part earns its place with no wasted words.
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 a simple tool with one parameter and no output schema, the description covers the output (forecast with verdicts) and thresholds. It does not detail the return format or verdict values, but overall it is sufficiently complete for the complexity.
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 says 'Five-day forecast' but the input schema allows 1-14 days via the 'days' parameter, creating confusion. The parameter is not explained in the description, and schema coverage is 0%, so the description must compensate but instead contradicts 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?
The description clearly states it provides a five-day forecast with blast-day verdicts using company thresholds. It specifies the resource (weather for blasting) and action (forecast + verdict), distinguishing it from sibling tools like morning_digest.
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 assessing blast-day suitability via verdicts and thresholds. It does not explicitly state when not to use or provide alternatives, but the context is reasonably clear given the tool's specificity.
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.
v1.0.0action_item_resolveaction_items_scanbusiness_snapshotcustomer_listdemo_resetexpense_reportflha_openflha_signoffinvoice_createinvoice_renderjob_completejob_schedulelead_capturelead_updatemorning_digestpipeline_viewpnl_reportpricing_ratespricing_record_outcomequote_createquote_listquote_pricequote_renderquote_update_statusreceipt_ingestsafety_logweather_checkMost tools have distinct purposes (leads, quotes, jobs, financial, safety), but there is some overlap between pipeline_view/quote_list and morning_digest/action_items_scan. Descriptions help differentiate, but ambiguity could occur.
Naming is mostly consistent with noun_verb or noun_noun pattern (e.g., action_item_resolve, lead_capture, pnl_report). A few exceptions like business_snapshot and morning_digest are noun_noun, but the pattern is clear.
27 tools is on the high side for a single server, covering many aspects of a business. While each tool serves a purpose, the count could be reduced by consolidating related functions.
Covers the main lifecycle (leads, quotes, jobs, invoicing, financials, safety, weather). Missing some CRUD operations (e.g., no update/delete for customers or jobs), but core workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A hosted MCP server for planning, scheduling, media, analytics, and social publishing.
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Corporate travel booking and expense management for TripGain, exposed as an MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kr8tiv-ai/evolved'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
