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., "@LeadClaw MCP Book 3 sales appointments next Tuesday in Dallas with AI startup CEOs"
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.
Demo MCP server for LeadClaw — a service for booking confirmed sales appointments through Claude. Human freelance SDRs handle the outbound; AI handles matching, quality, billing, and reporting. Customers pay only per BANT-qualified meeting that lands on their calendar.
This server is the showcase implementation used for the demo video and concept pitch. It returns realistic fake data so Claude Desktop calls feel live without any real SDR plumbing behind them yet.
In Claude Desktop you can say:
Book 3 sales appointments next Tuesday in Dallas with AI startup CEOs. Budget $450.
…and Claude will:
Call book_appointments on this server.
Get back a request_id and an ETA.
Poll check_status (immediately or later) and see appointments populate.
Pull full BANT briefings with get_appointment_details.
Nothing real happens on the SDR side — but the customer experience is identical to what the real product will feel like.
Related MCP server: Calendly MCP Server
Tool | Purpose |
| Submit a request for N confirmed appointments. Returns a |
| Poll a request; returns confirmed appointments so far and current phase. |
| Full briefing for one appointment: contact, company, BANT, SDR notes, meeting link. |
Status advances based on wall-clock time since the request was created — no background workers needed:
Elapsed | Phase | Confirmed |
0–5s |
| 0 |
5–15s |
| 0 |
15s |
| 1 |
+30s each |
| +1 |
All seats filled |
| N |
So a 3-seat request is fully completed ~75 seconds after book_appointments. Tunable in src/tools/status.ts.
Requirements: Node.js 18+ (this repo was developed against Node 24).
npm install
npm run buildThe compiled server entrypoint is dist/index.js. Data persists to data/store.json (auto-created).
Edit your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"leadclaw": {
"command": "node",
"args": ["C:\\absolute\\path\\to\\leadclaw-mcp\\dist\\index.js"]
}
}
}Replace the path with the absolute path to your built dist/index.js. On macOS/Linux use forward slashes.
Restart Claude Desktop. The three LeadClaw tools should appear in the tool list.
node dist/index.jsThen paste the following on stdin (one JSON object per line):
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"smoke","version":"1.0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}You should see three tools advertised.
leadclaw-mcp/
├── src/
│ ├── index.ts MCP server entrypoint (stdio transport)
│ ├── tools/
│ │ ├── book.ts book_appointments
│ │ ├── status.ts check_status (time-based phase simulation)
│ │ └── details.ts get_appointment_details
│ ├── mock/
│ │ ├── companies.ts fake AI/SaaS company pool
│ │ ├── people.ts fake names + default role pool
│ │ └── generator.ts appointment + BANT + meeting-time synthesis
│ └── db/
│ └── store.ts JSON file persistence
├── data/
│ └── store.json auto-generated on first request (gitignored)
└── dist/ build outputRestart Claude Desktop with the MCP config in place.
In a fresh chat, paste:
Book 3 sales appointments next Tuesday in Dallas with AI startup CEOs. Budget $450.
Claude calls book_appointments → you see the tool call card.
Ask: "check status" → Claude calls check_status. First call (within ~15s) shows processing/matching; wait ~75s and call again to see all 3 confirmed.
Optional: "give me the full briefing on the first one" → Claude calls get_appointment_details.
For the 30-second video cut, edit out the wait between calls.
Real SDR matching / phone integration
Stripe / billing
OAuth (stdio is local-only)
Web dashboard
Anthropic Connectors Directory submission
These come after the concept lands.
Request confirmed sales appointments delivered to your calendar. Human SDRs handle outbound; you pay only per confirmed, BANT-qualified meeting. Use when the user wants to book meetings, generate pipeline, get demos, or set up sales calls — but does not want to do the outreach themselves. Returns a request_id; poll check_status to see confirmed appointments populate.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Geographic target, e.g. "Dallas, TX", "San Francisco Bay Area", "remote-US". | |
| count | Yes | How many confirmed appointments to deliver (1-10). | |
| industry | No | Target industry vertical, e.g. "AI startups", "healthcare SaaS". | |
| target_role | No | Target buyer role, e.g. "CEO", "VP Sales", "CTO". | |
| date_range | No | Preferred meeting window in natural language, e.g. "next week", "May 20-25". | |
| budget_per_appointment | No | Budget cap per confirmed appointment in USD. Defaults to 100. | |
| notes | No | Free-form qualifying notes, e.g. 'Series A or later only'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses human SDRs handle outbound, pay-per-meeting model, BANT qualification, and returns request_id. Lacks timing 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?
Three sentences front-loaded with core function, business model, and usage guidance. No superfluous 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?
Covers workflow, return value, and sibling tool link. No output schema, but explanation of polling suffices. Minor gaps on error handling.
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% with all parameters described. Description adds high-level context but no additional detail beyond schema, meeting baseline.
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 requests confirmed sales appointments, differentiating it from siblings check_status and get_appointment_details by explicitly mentioning polling for results.
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 says when to use: when user wants meetings but not outreach; implies alternatives (do outreach yourself). Also directs to poll check_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the progress of a LeadClaw appointment request. Returns current phase (processing / matching / in_progress / completed) and any confirmed appointments so far. Call this after book_appointments and re-poll as needed until status is completed.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The request_id returned from book_appointments. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It transparently states the return values (current phase and confirmed appointments) and polling nature. No side effects or constraints are mentioned, but for a read operation it is adequate.
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. Information is front-loaded and 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?
Given the simplicity of the tool (one param, no output schema), the description adequately explains return values and usage. Could be slightly more detailed on error states, but overall complete for a polling tool.
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% with one parameter fully described. The description adds usage context (calling after book_appointments) but does not add new semantic meaning beyond the schema, so 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 verb 'check' and the resource 'progress of a LeadClaw appointment request', listing return values. While it distinguishes from book_appointments, it does not explicitly differentiate from sibling get_appointment_details, though the purpose is specific enough.
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 explicit usage context: 'Call this after book_appointments and re-poll as needed until status is completed.' It gives clear when-to-use but lacks when-not-to-use or alternatives for get_appointment_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull full briefing on a specific confirmed appointment: contact info, company context, full BANT breakdown, SDR call notes, and meeting link. Use when the user wants to prep for a specific meeting.
| Name | Required | Description | Default |
|---|---|---|---|
| appointment_id | Yes | The appointment_id returned from check_status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description conveys it is a read operation fetching details of a confirmed appointment, but does not disclose additional traits like permissions, side effects, or error scenarios. It adds value over no description but lacks depth.
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 capability, no filler. Second sentence provides usage guidance. 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?
For a simple tool with one parameter and no output schema, the description lists the returned data and usage context. It is adequate, though it could mention error cases or confirm the appointment must be 'confirmed'.
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% with a good description for appointment_id. The tool description adds minimal extra meaning, reinforcing the parameter's source. Baseline 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 explicitly states 'Pull full briefing on a specific confirmed appointment' and lists the data returned (contact info, BANT, etc.). It clearly distinguishes from siblings 'book_appointments' and 'check_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 says 'Use when the user wants to prep for a specific meeting,' which is a clear when-to-use. It does not explicitly mention alternatives, but the sibling context provides that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct purpose: booking appointments, checking status, and retrieving details. There is no ambiguity between them.
All tools follow the verb_noun pattern with snake_case (book_appointments, check_status, get_appointment_details), providing a predictable naming scheme.
Three tools is slightly minimal for the domain but covers the core workflow of booking, tracking, and reviewing appointments. It is reasonable for the service's scope.
The tool set covers the primary lifecycle (book, monitor, view details). Minor gaps like cancellation or rescheduling exist but are not critical for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/no39pikko/leadclaw-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
