Setell-MCP server — drive quote-to-cash from Claude Code, Claude.ai, or any MCP-aware agent. Exposes a curated subset of Setell's Boxx capabilities as MCP tools, resources, and prompts.
Setell-MCP exhibits a mixed quality profile. Strengths: consistent verb-noun naming (get_*, set_*, find_*, send_*, etc.), well-structured API client, proper TypeScript typing, and thoughtful error handling patterns with actionable recovery paths. Weaknesses: tool descriptions are often terse (many under 100 chars), parameter schemas are not directly visible in the provided source excerpt (only tool names and file paths listed), output structures are not documented in the rubric details, and risk categorization hints are present but lack explicit tool annotation metadata in the schema. The 28-tool surface is well-designed conceptually (clear responsibilities, good composability), but documentation density falls short of production A-grade standards. Tools like setell_send_quote and setell_compose_quote properly distinguish write-vs-read and include safety patterns (confirmation tokens, pricing pre-checks), but parameter descriptions and return schemas are inferred rather than explicitly shown in the submission.
Tools (28)
setell_add_job_contextwriteauth50/100
walkthrough / site-visit / call notes → SCOPING_INPUT text artifact that feeds the next quote draft
Apply a Setell-curated trade playbook. Safe by construction: seeds structure-only starter templates (no prices) only if the operator has none, and never overwrites their data — surfaces already customized are skipped with a reason. Returns {applied, skipped, nextSteps}; relay skips honestly.
setell_cancel_scheduled_sendwriteauth50/100
clear pending scheduled send
setell_compose_quotewriteauth50/100
draft a quote + email message and mint a confirmation token for later send
setell_find_customerread onlyauth50/100
search customers by name, email, or company with fuzzy matching
Input schemas not fully documented in submission. 26 of 28 tools have no visible parameter descriptions or type constraints in the provided source. Per HARD SCORING RULE, tools with no visible schemas are capped at schema=0 for assessment purposes. Only setell_apply_playbook shows an explicit schema with enum constraint on 'slug' parameter.
Document full input schemas for all 28 tools, including parameter types, constraints (enums, min/max, regex patterns), and descriptions. Use Zod or JSON Schema explicitly in the tool registration to make schemas machine-readable and visible to MCP introspection clients.
Expand tool descriptions to 80 - 180 characters each, structured as: WHAT does the tool do + WHEN should the LLM call it + what does it return. Example: 'Find jobs by status, customer, or recency. Returns paginated results with job_id, customer_name, quote_amount, status. Use before scheduling sends or analyzing margins.' Current descriptions like 'filter jobs by status / customer email / limit' are too terse.
Add per-parameter descriptions to all tools. Use prose (not just schema) to clarify intent: e.g., 'status' → 'Job status to filter by (QUOTED, WON, LOST, PENDING). Omit to return all statuses.' Specify format, range, and allowed values inline.
Document output schemas with example JSON responses for each tool. Include which fields are IDs that can be passed to downstream tools (e.g., job_id returned by find_jobs can be passed to get_quote). This enables LLMs to chain calls without extra discovery.
Add tool annotation metadata (readOnlyHint, destructiveHint, idempotentHint) to the MCP schema to encode the Risk categories already present in the submission. This signals to clients which tools are safe to retry and which require confirmation.
Implement pagination for discovery tools: setell_find_jobs, setell_find_customer, setell_list_playbooks, setell_get_customer_memory. Accept limit (default 20, max 100) and offset/cursor parameters. Return total_count and next_cursor. Document in descriptions: 'Results are paginated to 20 per page. Use offset=20 to fetch the next page.'
Score history
Overall score trend
First recorded score · v2 rubric
38/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
F
38
2026-07-28+
v2
GOOD/BEST generated around the job's current quote; BETTER mirrors it verbatim. Stores options only.
setell_get_autonomyread onlyauth50/100
retrieve current per-action-class autonomy modes (WATCH / TRUST / AUTO)
setell_get_customer_baselineread onlyauth50/100
read learned-baseline data per customer (Vertical Moat read path)
setell_get_customer_memoryread onlyauth50/100
list every CustomerMemory row for a (operator, customer) pair so the calling agent can audit / decide what to overwrite
setell_get_healthread onlyauth50/100
health probe + plan tier + integration status
setell_get_job_marginread onlyauth50/100
what the operator ACTUALLY made on a job; marginPct withheld below the honesty floor. Operator-only data.
setell_get_learning_coverageread onlyauth50/100
surfaces the operator's vertical-moat metrics: total SIGNED quotes, distinct customers with learned baselines, jobType-narrowed baseline count, operator-wide baseline, and maturityTier
setell_get_margin_summaryread onlyauth50/100
margin across recent WON jobs vs the operator's target; worst jobs/types
setell_get_morning_briefread onlyauth50/100
retrieve morning brief with recent activity summary
setell_get_pricing_calibrationread onlyauth50/100
the pricing report card: every draft-time prediction joined to its real outcome (calibration, win curve, verdict×outcome)
setell_get_pricing_signalread onlyauth50/100
run Setell's pricing-analyst on a job; returns verdict (PASS/WARN/FLAG), reasoning, and recommended counter-amount
Tool descriptions are terse (average ~45 chars). Critical tools like setell_find_jobs ('filter jobs by status / customer email / limit') lack context on when to use them vs similar tools, expected result cardinality, pagination behavior, or error recovery guidance. Baseline for A-grade is 50-200 chars with explicit WHAT/WHEN/HOW structure.
Output schemas not documented. The submission lists tool names and file paths but does not include example responses or documented return structures. LLMs cannot plan downstream calls or extract chaining IDs (e.g., job_id for follow-up operations) without knowing what fields each tool returns.
Risk categorization (READ_ONLY, WRITE, IRREVERSIBLE) is present in the submission but does not appear to be encoded as tool annotation metadata in the MCP schema. Modern servers use readOnlyHint, destructiveHint, and idempotentHint in the tool definition to signal safety semantics to clients. This prevents LLMs from treating all tools equally and enables safer retry logic.
Parameter constraints not visible for most tools. setell_apply_playbook correctly defines an enum on 'slug' parameter with 6 allowed playbook types. Other tools (e.g., setell_find_jobs with 'status', setell_set_autonomy with autonomy mode values) likely have similar constraints but these are not documented in the submission. Without constraints, LLMs hallucinate invalid values; enums are self-documenting.
Pagination / result limiting not documented. Tools like setell_find_jobs and setell_find_customer are discovery/search tools that could return large result sets. Descriptions don't clarify whether results are paginated, what the default/max limit is, or how to fetch the next page.
Error handling guidance not visible. While the code comments hint at thoughtful error patterns (e.g., 'pricing-analyst pre-check + atomic QuoteSendConfirmation guard' for setell_send_quote), the actual error message guidance that LLMs see at runtime is not documented in the submission. Try search_users()' is actionable; a raw 401 or stack trace is not.
Parameter descriptions missing for all visible tools except setell_apply_playbook. A parameter named 'type' is ambiguous, the description disambiguates it for the LLM.' The submission lists tool names and brief descriptions but does not show per-parameter docstrings.
Add enumerated constraints to tools with known value sets. E.g., setell_find_jobs 'status' parameter should be an enum: QUOTED | WON | LOST | PENDING. Document in description: 'Job status filter. Must be one of: QUOTED, WON, LOST, PENDING. Omit for all statuses.'
Enhance error messages to guide LLM recovery. Instead of raw 401/404, return: 'Customer not found (email: [email protected]). Try setell_find_customer() with a partial name or company.' This enables self-correction without an extra discovery call.
For irreversible tools (setell_send_quote, setell_apply_playbook), implement confirmation-before-execute pattern. Return a confirmation token on first call ('dry-run mode'); LLM must call again with token to execute. This prevents accidental sends.
Add limit documentation to write tools that could have large side effects. E.g., setell_apply_playbook currently allows only 6 playbook slugs (good). Clarify in description: 'Safe by construction, only applies structure-only templates; never overwrites existing data.' This reassures agents.
Include chaining IDs in all response schemas. If setell_compose_quote returns a quote, it must also return job_id and customer_id so the agent can immediately call setell_send_quote(quote_id, job_id, customer_id) without a lookup.
Document rate limits, timeouts, and retry guidance for each tool. E.g., 'setell_get_pricing_signal may take 5-10 seconds. If timeout, retry with exponential backoff.' This prevents agent loops.
Add a 'before you start' helper prompt. The server's instructions are good but could guide agents toward common workflows. E.g., '/setell-triage-inbox → find_jobs(status=PENDING) → get_pricing_signal(job_id) → compose_quote(job_id) → send_quote(quote_id)'. Pre-planning saves agent reasoning cycles.