Integrates with Google Sheets as the lead pipeline store and Google Calendar for availability checks and appointment booking, enabling deduplication, scoring, stage transitions, and booking guardrails on data the business already owns.
Click on "Deploy 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., "@LeadPipe MCP capture a new lead for jane@acme.com and score it"
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.
LeadPipe MCP is an MCP server that gives small businesses without a CRM a scored, bookable lead pipeline on a Google Sheet and Calendar they already own. An AI assistant captures, deduplicates, scores and books leads through eight guardrailed tools, with approval-safe writes. It is not a CRM and sends nothing to anyone.
Related MCP server: MCP Calendar Assistant
Most small service businesses have no CRM. They run their pipeline in a spreadsheet and an inbox: 56% of US small businesses do not use a unified CRM, and of those, 39% track customers with spreadsheets and email (SMB Group survey for Bigin by Zoho CRM, 2023, vendor-commissioned, n>1,500). The US alone has 36.2 million small businesses (SBA Office of Advocacy, 2025), and response speed matters: firms that responded to web leads within an hour were about 7 times more likely to qualify them, while 23% never responded at all (Oldroyd, McElheran and Elkington, HBR, 2011).
When these businesses connect an AI assistant today, they get one of two bad options: a vendor MCP server that requires the paid CRM they do not own, or a generic spreadsheet MCP that exposes raw row CRUD, so the assistant can duplicate a lead, move a stage backwards, or double-book a slot with nothing stopping it.
LeadPipe does the pipeline job, with guardrails. It does not send messages, run campaigns, or replace a CRM for businesses that have outgrown a spreadsheet.
LeadPipe MCP | Paid-CRM MCP servers | Generic spreadsheet MCP servers | |
Cost | Free and open source (MIT); you bring your own Google account | The server is tied to a paid CRM subscription | Usually free, but raw access only |
Prerequisite | A Google Sheet and Calendar; no CRM needed | Owning and running that vendor's CRM | A spreadsheet, plus guardrails you build yourself |
Dedup and scoring safety | Built in: dedup on normalised email, then phone, before any write; the 0-100 score is computed server-side and never accepted from the caller | Whatever the CRM provides; scoring depends on the product and plan | None: raw row CRUD, so duplicate leads and invented score totals are possible |
Booking safety | Availability is re-checked at call time and an idempotency key returns the existing event instead of double-booking | Depends on the CRM's own booking features | None: nothing stops the assistant double-booking a slot |
Lock-in | Your pipeline stays in your Sheet; exporting it is copying a file | Pipeline history lives inside the vendor's system | Your data stays in your Sheet, and so does every risk above |
The demo walkthrough runs the whole product offline against an in-memory fake client (approval mode, so writes preview first). Real output, trimmed:
== 1. capture_lead (new lead) ==
{ "ok": true, "lead_id": "LP-2026-00013", "created": true,
"deduped": false, "stage": "NEW", "score_total": null, "band": null }
== 2. capture_lead again (same contact, deduped) ==
{ "ok": true, "lead_id": "LP-2026-00013", "created": false,
"deduped": true, "matched_on": "email", "stage": "NEW" }
== 3. score_lead (total computed server-side) ==
{ "ok": true, "lead_id": "LP-2026-00013", "score_total": 85,
"band": "HOT", "components": { "problem": 18, "fit": 19, ... } }
== 7. book_appointment with confirm=true ==
{ "ok": true, "appointment_id": "fake-event-0007", "created": true, ... }
== 8. book_appointment again (idempotent, no duplicate) ==
{ "ok": true, "appointment_id": "fake-event-0007", "created": false, ... }Prerequisites: Python 3.11 or newer. No Google account, no API keys, no paid services for the demo.
git clone https://github.com/techaurah/leadpipe-mcp.git
cd leadpipe-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e .
python examples/demo_walkthrough.pyExpected result: nine numbered steps print, ending with
Walkthrough complete. You have just captured, deduped, scored,
listed, checked, booked, re-booked (no duplicate) and summarised a
pipeline, all offline.
To use it inside an MCP client, register the demo server (Claude Desktop example, full guide in docs/client-config.md):
{
"mcpServers": {
"leadpipe": { "command": "leadpipe", "args": ["demo"], "env": {} }
}
}For real mode you need a Google Sheet, a calendar, and your own Google
service account key. Run leadpipe bootstrap once (it creates the
schema and refuses to touch a Sheet whose headers do not match), then
register the server with the env values from .env.example.
LeadPipe MCP exposes eight tools that cover the whole lead pipeline, from capture to booking, each with its guardrails enforced server-side:
capture_lead: records a lead and deduplicates on normalised email, then phone, before any write (schema)
get_lead: fetches one lead by ID, email or phone, with the score recomputed from components so a hand-edited Sheet cannot fake a total
list_hot_leads: HOT leads (80+) in attention order, booked ones excluded unless asked
score_lead: applies the deterministic 0-100 model; the total is computed server-side and never accepted from the caller (model)
update_stage: moves stages only along the validated transition map; WON is terminal, LOST reactivates only to NURTURE (map)
check_availability: free slots intersected with business hours; busy titles are never returned
book_appointment: re-checks availability at call time and uses an idempotency key, so a repeat call returns the existing event instead of double-booking
daily_pipeline_summary: counts by stage and band, hot unbooked leads, today's appointments, overdue next actions
Write modes: direct, dry-run and approval, with approval the default on real credentials (safety)
Demo mode: a fake Google client with a 12-lead seed dataset, so everything above runs with no credentials
Environment variables only; there is no config file to edit. The full
annotated list is in .env.example.
Variable | Required | Purpose |
| No |
|
| Real mode | The pipeline Sheet's ID |
| Real mode | Calendar to check and book ( |
| Real mode | Path to your own service account key file; contents are never logged or returned |
| No |
|
| No | IANA timezone for business hours and summaries (default UTC) |
| No | Default |
Example | What it shows | Time | Credentials |
All eight tools end to end on the fake client | About 1 minute | None | |
Claude Desktop and Cursor registration, demo and real mode | About 5 minutes | None for demo |
Now: v0.1.0, the eight tools, Sheets and Calendar store, demo mode.
Next (candidates, each needs its own issue): cancel and reschedule tools, CSV import through the same dedup path, a list_leads filter tool, per-weekday business hours.
Later (candidates): SQLite store behind the same protocol, attendee invitations behind approval mode, a follow-up due-date report.
LeadPipe MCP is free and open source under the MIT license. You run it yourself, so the only costs are your own: a Google account for the Sheet and Calendar it uses, and whatever AI client you connect it to. There is no subscription, no per-seat fee, and no paid tier.
No. LeadPipe MCP is built for businesses that do not have one. Your pipeline lives in a Google Sheet with a fixed three-tab schema (Leads, AuditLog, Meta), and bookings go on a Google Calendar you own. If you later outgrow a spreadsheet, your data is already in a Sheet you can export anywhere.
LeadPipe MCP runs locally on your machine as a stdio server. It talks only to the Google Sheets and Calendar APIs, using your own service account key, and to nothing else. It sends no messages, no emails and no calendar invitations to anyone, and credential contents are never logged or returned in tool results.
It does not send messages, run campaigns, or follow up with leads, and it is not a CRM: there is no user interface, no reporting suite, and no multi-user permissions. Version 0.1 also has no cancel or reschedule tool. It does one job, the pipeline operations, with guardrails, and leaves communication to other tools.
Open a GitHub Issue for bugs and feature requests, and use GitHub Discussions for questions, ideas, and show and tell. Security problems go through SECURITY.md, privately, never as a public issue. For commercial support or a done-for-you setup, TechAurah takes AI engineering engagements through techaurah.com.
Yes. The MIT license allows commercial use, including deploying it per client. Each client needs their own Google Sheet, Calendar and service account key, so client data stays inside accounts the client owns. Agencies can run one server instance per client with no licence cost, which is the deployment pattern it was designed for.
Any client that speaks the Model Context Protocol over stdio. The documented configurations in docs/client-config.md cover Claude Desktop and Cursor, in both demo and real mode. Because LeadPipe MCP is built on the official MCP Python SDK, other MCP clients should work the same way; report any problem as an issue.
Approval mode is the default with real credentials. When a tool wants to write, you first get a preview of what would change, and nothing is written until the call is repeated with confirm set to true. A per-call flag can only make a call safer than the configured mode, never upgrade it, so an assistant cannot bypass approval.
Read CONTRIBUTING.md, find a good first issue,
and send a PR that links its issue and passes CI. The easiest first
contributions need no Google account: a store backend behind the
existing protocol, a client-config example, or a test for a documented
edge case.
Channel | Best for |
GitHub Issues | Bugs and feature requests (actionable work) |
GitHub Discussions | Questions, ideas, show and tell |
Vulnerability reports (private, never a public issue) | |
Commercial support and AI engineering engagements |
MIT. See LICENSE.
LeadPipe MCP is one of six open-source projects from TechAurah:
ai-lead-automation: the open blueprint for AI lead automation in service businesses, covering architecture, qualification prompts, CRM field mapping and follow-up patterns.
n8n-audit: a production-readiness linter for n8n workflows, catching pasted secrets, missing error workflows and other known failure classes in CI.
qualbench: outcome regression testing for AI qualification and booking agents, with deterministic assertions and vertical scenario packs.
chasekit: the open-source invoice-chasing layer, with overdue detection, UK and EU statutory interest, and a four-stage tone ladder.
slotfill: no-show recovery for appointment businesses, with reminders and waitlist backfill on the calendar already in use.
TechAurah is an AI and software engineering company building AI products, agents and automation for service businesses, and publishing the reusable parts as open source. We are available for AI engineering projects: techaurah.com.
Follow TechAurah on LinkedIn.
Book a calendar appointment for a lead. Availability is re-checked at call time and repeat calls never duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| notes | No | ||
| start | Yes | ||
| title | No | ||
| confirm | No | ||
| dry_run | No | ||
| lead_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two valuable traits: availability is re-validated server-side and repeat calls are idempotent. It still omits permission requirements, conflict behavior, and the meaning of the confirm/dry_run safety flags, leaving meaningful gaps for a mutation 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?
Two tight sentences with no filler, and the idempotency guarantee is front-loaded alongside the core action. Every clause earns its place.
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?
A 7-parameter write tool with no annotations, no output schema, and 0% param coverage needs substantially more: dry_run/confirm semantics, conflict handling, and the response shape are all absent. What is present is accurate but insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, so the description must compensate, but it adds almost nothing: lead and timing are only implied, and confirm, dry_run, notes, and title are entirely unexplained. The two least obvious parameters (confirm and dry_run) are safety-critical and undocumented anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Book a calendar appointment for a lead'), which is clearly distinct from read/list siblings like get_lead or check_availability. It does not explicitly name an alternative, so it falls short of the sibling-differentiation bar for a 5.
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 note that 'availability is re-checked at call time' implies the agent need not call check_availability first, which is useful implied guidance. However, there is no explicit statement about when to use this vs check_availability, nor any guidance on when confirm or dry_run should be set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a new lead, deduplicating on email then phone before any write.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| No | |||
| phone | No | ||
| source | Yes | ||
| company | No | ||
| confirm | No | ||
| dry_run | No | ||
| location | No | ||
| problem_notes | No | ||
| service_interest | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one meaningful trait: dedup on email then phone happens before any write. However, it is silent on the two most consequential behavioral gates in the schema — `confirm` and `dry_run` — leaving the agent unable to tell whether a real write occurs by default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, and the dedup constraint is placed before the write implication. It is efficient but so terse that efficiency shades into under-specification for a 10-parameter mutation.
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?
No annotations, no output schema, 10 undocumented parameters, and no statement of what a duplicate produces or what success looks like. For a write tool with built-in confirmation flags, the description is materially incomplete.
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% across 10 parameters, so the description must compensate and does not. It only touches email and phone as dedup keys; name, source, company, location, problem_notes, service_interest, and critically confirm/dry_run are all unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Record a new lead") plus a distinguishing behavioral detail (dedup on email then phone). Implicitly distinct from siblings like get_lead/update_stage, but no sibling is named and the boundary with update_stage is left to inference.
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 call this versus update_stage (existing lead) or check_availability/book_appointment downstream. Nothing says when a record should not be created, or whether a duplicate match aborts or returns the existing lead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free slots on the business calendar, intersected with business hours. Busy times are returned without titles.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| slot_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful return behavior: availability is constrained by business hours and busy times are returned without titles. However, it omits timezone, auth requirements, and response formatting.
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 compact sentences with the key behavior front-loaded. There is no filler, and each sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 0% parameter description coverage, the description needed to clarify date formats, timezone, slot sizing, and return shape. It gives only high-level return behavior, which is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions start, end, or slot_minutes. An agent must infer all parameter meanings from names alone, so the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and outcome: free slots on the business calendar intersected with business hours. The purpose is clear, though it does not explicitly distinguish itself from sibling tools like book_appointment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied as a pre-booking availability check. There is no explicit guidance on when to use this versus book_appointment, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call summary: counts by stage and band, hot unbooked leads, today's appointments, overdue next actions.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It usefully discloses the aggregated contents of the summary, making clear this is a read-style aggregation rather than a mutation, but it does not explicitly state read-only behavior, permission requirements, rate limits, or how the 'date' parameter affects the scope.
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 front-loaded sentence with a compact list of inclusions. Every phrase adds information, and there is no redundant or filler text.
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?
Because there is no output schema, the description does a reasonable job of enumerating what the summary contains. However, it leaves the 'date' parameter unexplained and does not clarify whether counts are returned as numbers, whether lists are truncated, or what format the result takes.
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 optional 'date' parameter has 0% schema description coverage, and the tool description never mentions it. An agent cannot tell whether 'date' selects the day of the summary, defaults to today, uses UTC or local time, or how it interacts with phrases like 'today's appointments.'
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 gives a clear verb-and-resource combination ('One-call summary') and enumerates the exact content included: stage/band counts, hot unbooked leads, today's appointments, and overdue next actions. This distinguishes it from action-oriented siblings like score_lead or book_appointment, though it does not explicitly name those alternatives.
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 phrase 'One-call summary' implies the tool should be used when an agent wants a consolidated pipeline overview instead of making multiple calls. However, there is no explicit guidance about when to prefer this tool over siblings such as list_hot_leads or get_lead, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one lead by lead_id, email or phone (exactly one).
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| phone | No | ||
| lead_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. "Fetch" implies a read, but nothing states read-only semantics, what happens when no lead matches, or whether an ambiguous identifier errors out — all relevant for a lookup that accepts three optional keys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler, front-loading the resource and then the selection rule. Every clause earns its place.
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 single-record lookup the core is covered, but with no output schema and no annotations the description should say roughly what a lead record contains or how a miss is signalled. As written, an agent knows how to call it but not what it gets back.
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 must compensate, and it does name all three selectors (lead_id, email, phone) plus the critical mutual-exclusivity constraint that the schema cannot express since every field is nullable and optional. It omits format details (email syntax, lead_id shape) that would push it to a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Fetch one lead") and constrains scope to a single record, which cleanly separates it from siblings like list_hot_leads and capture_lead. It doesn't explicitly name a sibling, so it stops short of a 5.
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 "exactly one" rule tells the agent how to select an identifier, but there is no guidance on when to reach for this tool versus score_lead, list_hot_leads, or check_availability, and no prerequisites or failure conditions are given. Usage is implied by the name and verb rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List HOT leads (score 80+), highest score first, oldest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| include_booked | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose ordering behavior (highest score first, tie-broken by oldest first), which is genuine added context. It stops short of stating that this is a read-only operation, whether results are paginated or truncated, and what include_booked actually changes in the result set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with zero filler, and the most decision-relevant fact (the 80+ threshold) is front-loaded. It is arguably too terse for a tool with two completely undocumented parameters, but nothing in it is waste.
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?
No annotations, no output schema, and 0% schema coverage leave the description as the only information source, and it does not say what a lead record contains, whether booked leads are excluded by default, or how many results come back. For a two-parameter filtered-list tool this leaves meaningful gaps.
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 both parameters rely entirely on the description, and it says nothing about `limit` (default 20, but is it a max? a page size?) or `include_booked` (does including booked leads mean default excludes them?). The description's "score 80+" clarifies filtering but not either parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List HOT leads") and defines the filter threshold precisely as "score 80+", which an agent cannot infer from the name alone. It does not, however, differentiate itself from siblings like daily_pipeline_summary or get_lead, which surface overlapping lead data.
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 word "List" plus the score filter implies a browsing use case, but there is no explicit statement of when to pick this over score_lead, daily_pipeline_summary, or get_lead, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply the deterministic scoring model. The eight component judgements are supplied by the caller; the total is computed server-side and never accepted as an input.
| Name | Required | Description | Default |
|---|---|---|---|
| scores | Yes | ||
| confirm | No | ||
| dry_run | No | ||
| lead_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It usefully discloses that the total is computed server-side and not accepted as input, but it does not state whether scoring mutates the lead, what confirm or dry_run do, or what permissions or side effects are involved.
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 front-loaded sentences with no wasted wording. The key constraint—server-computed total—is stated directly.
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 tool has no annotations, no output schema, 0% schema description coverage, and a nested scores object. The description adds one important behavioral constraint, but it is not complete enough for an agent to confidently invoke the tool, especially regarding mutation, confirmation, dry-run behavior, and return value.
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 compensate for all four parameters. It clarifies that scores contains eight component judgements and that total is server-computed, but it does not explain lead_id, confirm, dry_run, or the structure and valid values of the scores object.
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 states a specific action: applying a deterministic scoring model, with caller-supplied component judgements and server-side total computation. The lead context comes from the name and lead_id rather than the prose, and it does not explicitly differentiate itself from the 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?
It explains how the score is calculated but gives no guidance on when to call this tool versus get_lead, update_stage, or other siblings. It also does not explain when to use confirm or dry_run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a lead to a new stage; illegal transitions are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| stage | Yes | ||
| confirm | No | ||
| dry_run | No | ||
| lead_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a mutating operation and that illegal stage transitions are rejected, which is useful. But it omits critical behavioral details: permissions required, side effects, reversibility, and the roles of the confirm and dry_run flags.
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 single sentence is front-loaded and wastes no words. However, conciseness comes at the cost of under-specification for a five-parameter mutation tool.
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 mutation tool with five parameters (two required, three optional including confirm and dry_run), no output schema, and no annotations, the description is far too thin. It fails to explain transition rules, dry-run behavior, or confirmation semantics that an agent would need to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only loosely implies lead_id and stage; it says nothing about note, confirm, or dry_run. The crucial confirm and dry_run parameters are completely unexplained in both schema and 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 states a specific verb and resource: 'Move a lead to a new stage.' This clearly distinguishes it from sibling read/query tools like get_lead or list_hot_leads. It does not explicitly name sibling alternatives, but the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Move a lead to a new stage' – use when advancing a lead through stages. However, there is no explicit guidance on when not to use it, what 'illegal transitions' mean, or how confirm/dry_run should be used. No alternatives are named.
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.
v0.1.0book_appointmentcapture_leadcheck_availabilitydaily_pipeline_summaryget_leadlist_hot_leadsscore_leadupdate_stageScored across 8 tools
Each tool maps to a distinct operation: capturing/getting/scoring/updating a lead, listing hot leads, summarizing the pipeline, checking availability, or booking an appointment. The only potential overlap is list_hot_leads versus daily_pipeline_summary's hot-unbooked section, but the descriptions clearly distinguish a focused list from an aggregate summary.
Seven of eight tools use a predictable snake_case verb_noun pattern such as score_lead, capture_lead, and book_appointment. daily_pipeline_summary is a noun phrase rather than a verb-led name, which is a minor deviation but still readable.
Eight tools fit the lead pipeline and appointment-booking scope well, with each tool earning its place. There is no obvious padding, and the count is comfortably within the ideal range.
The surface covers core lead capture, lookup, scoring, stage transitions, hot-lead listing, daily summaries, availability checking, and booking. However, there is no general update tool for lead contact fields/owner/notes, no search or list beyond hot leads, and no appointment cancellation/rescheduling, leaving notable lifecycle gaps.
Lets AI agents get leads on the phone: call, send SMS, and schedule callbacks for sales teams.
Scheduling for AI assistants: bookings, availability, meeting polls and routing forms.
AI-native scheduling and booking: check availability, book meetings, share links.
Run a service business from your AI agent: CRM, leads, scheduling, invoicing, jobs and more.
