MCP server for lead generation, prospect enrichment, and outreach campaign management. Integrates with job search APIs (jsearch, active_jobs_db) and provides tools for profile management, lead retrieval, contact enrichment, and message generation.
Server has 9 tools with mixed quality. Most tools have descriptions (8/9) and explicit schemas visible in the source, but several critical issues emerge: (1) Parameter descriptions are present but some are terse or incomplete (e.g., 'Lead source' for 'type' in get_leads lacks detail about valid enum values); (2) Output schemas are not documented, no indication of what fields are returned or their structure, making it difficult for LLMs to plan downstream operations; (3) Error handling guidance is minimal, no indication of retryability, recovery steps, or user-fixable vs fatal errors; (4) Tool composition issues, get_leads and insert_leads do similar work but descriptions don't clearly distinguish when to use each (description says 'ALWAYS USE THIS FIRST' for get_leads, but this is imperative guidance that should be in system instructions, not tool description); (5) The reset_data tool lacks confirmation or dry-run pattern despite being destructive. Tool naming is generally verb-first and clear, which is a strength. Schemas are syntactically present (JSON Schema format visible) but lack detail about response structures.
Generate prospecting messages for contacts without existing messages. Creates a campaign by generating personalized messages for each uncontacted contact. Only contacts without existing messages will be processed (each contact gets one message ever). Returns campaign statistics including total contacts, successful and failed message generations.
ALWAYS USE THIS FIRST to retrieve existing data from the database before searching for new opportunities. Returns companies, jobs, contacts or leads that are already stored in the database. This endpoint is paginated: use the 'offset' parameter to paginate through results. Offset begins at 0. Pagination size: 5 for companies, 10 for contacts, 3 for jobs. Use this tool when the user wants to see existing leads, companies, jobs, or contacts. Only use the insert/leads endpoint when the user specifically asks for new opportunities or when no relevant data is found in the database. The parameter 'type' can be: 'companies', 'jobs', 'contacts', or 'leads'. Example: GET /get/leads/companies/0 to get the first 5 companies, /get/leads/companies/5 for the next 5, /get/leads/contacts/0 for the first 10 contacts, /get/leads/jobs/0 for the first 3 jobs, etc.
ALWAYS USE THIS FIRST to get the user profile from the database. This must be called before using any other endpoints (upsert profile, get leads, insert leads) to understand the user's context, job preferences, and location. If no profile exists or profile is incomplete, then use upsert to create/update it.
Check the status and progress of a background task by its unique ID. Essential for monitoring long-running operations like lead insertion, enrichment, or data processing. Returns current status ('processing', 'completed', 'failed'), progress information, and any error details. Use the task_id returned from operations like '/insert/leads' to track their execution. Completed or failed tasks are automatically cleaned up after status retrieval. Example: After starting lead insertion, use this to monitor when new leads are ready in the database.
Output schemas completely undocumented for 8/9 tools. No indication of response structure, field names, data types, or pagination. LLMs cannot plan downstream operations without knowing what fields to expect.
Parameter descriptions lack formal constraints (enums, min/max, patterns). 'type' in get_leads described as 'Lead source' but valid values ('companies', 'jobs', 'contacts', 'leads') only mentioned in the long tool description, not as parameter-level enum or constraint.
Error handling guidance is absent or minimal. No indication of which errors are retryable, user-fixable, or fatal. Missing recovery guidance like 'If source fails, try another source' in structured form.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Get all currently running tasks. Returns tasks with status 'processing' and their progress information.
Use this ONLY when the user asks for NEW opportunities/leads or when get/leads returns insufficient data. This tool searches external sources and inserts NEW leads into the database. Sources available: 'jsearch', 'active_jobs_db'. If a source does not work or returns no data, try another one. Requires location (country code) and job titles as technologies or job titles (e.g., 'Python', 'AI', 'RAG', 'LLM', 'Tech lead', 'Software Engineer'). Focus on technologies found on profile. IMPORTANT: Before using this, check the user profile or ask to update it if missing. Example JSON: {"source": "jsearch", "location": "FR", "job_params": ["Python", "AI", "RAG", "LLM", "Tech lead", "Software Engineer"]}
Delete all user data including profile, contacts, jobs, and companies. This action is irreversible.
Upload a PDF resume to extract profile information automatically. Returns extracted profile data and raw text from the resume.
Insert or update the user profile into the database. Use this AFTER calling get/profile when the profile doesn't exist or needs updates. You can ask for missing fields if the user hasn't provided them, or save partial data if user prefers. Example JSON: {"job_title": "Software Developer", "location": "FR", "bio": "Passionate developer", "work_experience": [{"company": "TechCorp", "position": "Developer", "start_date": "2020-01", "end_date": "2023-12", "description": "Full-stack development"}], "technos": ["Python", "FastAPI"]}
Destructive tool 'reset_data' lacks confirmation pattern. No dry-run, no confirmation step, no undo capability documented. LLM could invoke irreversibly without user approval.
Operational guidance mixed into tool descriptions. 'ALWAYS USE THIS FIRST' for get_leads and get_profile should be in system instructions or agent prompt, not tool description. Tool descriptions should answer WHAT, WHEN, and WHY, not dictate orchestration order.
Example JSON in upsert_profile description risks literal reuse by LLM. Example values should be replaced with formal constraints (enums, patterns, min/max).
File upload semantics unclear. 'upload_resume' accepts 'file' as string type, is this base64? multipart form data? file path? Lack of clarity invites LLM misuse and failed uploads.