Searches for companies on Indeed job board to find potential job opportunities.
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., "@Job Outreach MCP Server search for companies matching 'Stripe'"
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.
An MCP server for automated job outreach that helps you find companies, discover contacts, generate personalized emails with AI, and track your outreach campaigns.
Tool | Description |
| Find companies from job boards (Indeed) or add manually |
| Add contacts with automatic email pattern generation and SMTP verification |
| Scrape company websites for personalization data using AI |
| Track specific job postings you're applying to |
| AI-powered personalized email generation using Claude |
| Smart scheduling for optimal delivery times (Tue-Thu, 9-11am) |
| Monitor opens, clicks, and replies |
| Automatic follow-up email generation |
| Overview of all your outreach campaigns |
Related MCP server: Cold Email Assistant
Install dependencies:
npm installConfigure settings:
cp data/config.example.json data/config.jsonEdit data/config.json with your credentials.
Build:
npm run buildEdit data/config.json:
{
"smtp": {
"host": "smtp.your-server.com",
"port": 587,
"user": "your-username",
"password": "your-password",
"from_email": "you@example.com"
},
"anthropic_api_key": "sk-ant-...",
"user_profile": {
"name": "Your Name",
"title": "Software Engineer",
"resume_summary": "Your background...",
"linkedin_url": "https://linkedin.com/in/you",
"highlights": ["5+ years experience", "TypeScript expert"]
},
"smart_schedule": {
"timezone": "America/Los_Angeles",
"preferred_days": [2, 3, 4],
"preferred_hours": [9, 10, 11]
},
"followup": {
"enabled": true,
"days_between": 5,
"max_followups": 2
},
"tracking_server": {
"port": 3847,
"base_url": "http://your-server:3847"
}
}Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on Mac):
{
"mcpServers": {
"job-outreach": {
"command": "node",
"args": ["/path/to/auto-job-application/dist/index.js"]
}
}
}The email processor sends scheduled emails and handles tracking:
npm run processorRun this in the background to automatically send emails at their scheduled times.
Add a company:
search_companies({ query: "Stripe", source: "manual" })Add a contact:
find_contacts({
company_id: 1,
contacts: [{ name: "Jane Doe", title: "Recruiter" }]
})Research the company:
research_company({ company_id: 1 })Add job posting (optional):
add_job_posting({
company_id: 1,
title: "Senior Engineer",
url: "https://stripe.com/jobs/123"
})Generate personalized email:
generate_email({ contact_id: 1, job_posting_id: 1 })Schedule delivery:
schedule_email({ email_id: 1, smart_schedule: true })Check status:
check_tracking({ company_id: 1 })Schedule follow-up (if no reply):
schedule_followup({ email_id: 1 })src/
├── index.ts # MCP server entry point
├── processor.ts # Background email processor
├── types.ts # TypeScript types
├── tools/ # MCP tool implementations
│ ├── search-companies.ts
│ ├── find-contacts.ts
│ ├── research-company.ts
│ ├── generate-email.ts
│ ├── schedule-email.ts
│ ├── check-tracking.ts
│ ├── schedule-followup.ts
│ ├── list-campaigns.ts
│ └── add-job-posting.ts
├── services/ # Core services
│ ├── database.ts # SQLite operations
│ ├── config.ts # Configuration loader
│ ├── scraper.ts # Web scraping with Puppeteer
│ ├── email-patterns.ts # Email generation & SMTP verification
│ ├── llm.ts # Claude API integration
│ ├── scheduler.ts # Smart scheduling logic
│ └── smtp.ts # Email sending
└── tracking/
└── server.ts # Open/click tracking webhook serverThe tracking server provides:
Open tracking: 1x1 pixel embedded in emails
Click tracking: Link wrapping with redirect
Reply webhooks: Endpoint for email provider callbacks
For tracking to work, the tracking server must be accessible from the internet (use ngrok for testing or deploy the processor).
LinkedIn scraping is not implemented (requires authentication and is against ToS)
Email SMTP verification may be blocked by some mail servers
Smart scheduling picks optimal send times: Tuesday-Thursday, 9-11am recipient timezone
The background processor must be running for scheduled emails to be sent
MIT
Add a job posting for a company. Use this to track specific roles you're applying to.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to the job posting | |
| title | Yes | Job title | |
| company_id | Yes | ID of the company | |
| description | No | Job description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action of adding a posting without mentioning side effects, required prior data (e.g., company existence), or what the result is. This is minimal disclosure 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?
The description is two short sentences, with the action stated upfront and the purpose clarified next. No filler or redundant 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?
The tool has a simple create action with self-describing schema, but there is no output schema or annotations, and the description does not explain what the response will be or any prerequisites. It's adequate for a straightforward add operation but leaves some gaps about the effect and the required company context.
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?
All four parameters have schema descriptions (100% coverage), so the description is not required to elaborate. It does add a connection to 'company' and 'roles', but this is already implied by company_id and title. The description does not add syntax or details beyond the schema, so a 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 ('Add') and resource ('a job posting for a company'), and the second sentence explains the intended use for tracking application roles, distinguishing it from sibling tools like search_companies or generate_email.
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 provides a reason to use the tool ('Use this to track specific roles you're applying to') but does not explicitly compare with alternatives or state when not to use it. The use case is implied rather than explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check email tracking status. View opens, clicks, and replies for your outreach emails.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status (draft, scheduled, sent, opened, clicked, replied) | |
| email_id | No | Filter by specific email ID | |
| company_id | No | Filter by company ID | |
| contact_id | No | Filter by contact ID |
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 read-only nature ('Check', 'View') and the specific data returned (opens, clicks, replies), which is helpful. It does not mention output format, authentication, rate limits, or any other behavioral traits, but for a simple read tool this is acceptable.
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 short sentences, front-loaded with the action, and every word adds value. There is no redundancy or unnecessary detail.
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 lack of an output schema and annotations, the description does not fully specify what the returned data looks like, how filters combine, or any prerequisites (e.g., emails must be sent). It is adequate for understanding the tool's purpose but not fully complete for an agent needing to predict behavior.
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%, so the schema already documents all four filter parameters. The description adds no new meaning about the parameters; it merely confirms the tool surfaces tracking metrics. Thus a baseline 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 action ('Check') and the resource ('email tracking status'), then specifics what it returns: opens, clicks, and replies. This distinguishes it from sibling tools focused on companies, contacts, and email generation/scheduling.
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 'for your outreach emails' gives some context for when to use the tool, implying it is for reviewing engagement on sent emails. However, it does not explicitly state when to prefer this over alternatives nor provide exclusions, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find or add contacts at a company. Provide contacts manually with names and titles, and the tool will generate and validate email addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| roles | No | Job titles/roles to search for | |
| contacts | No | Manually provide contacts to add | |
| company_id | Yes | ID of the company to find contacts for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions that manually provided contacts will generate and validate email addresses, but it does not explain how the 'find' behavior works (e.g., using roles), whether it writes data (e.g., adds contacts to a CRM), or what the return value looks like. This is a significant transparency gap.
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 long and front-loaded with the main purpose. The second sentence provides a concrete example of usage without unnecessary detail. Every word earns its place, and there is no 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 tool has no output schema and no annotations, yet the description only scratches the surface. It does not explain the search-by-roles functionality, the relationship between creating contacts and finding them, or what the tool returns. The description is incomplete for a tool with 3 parameters and no output schema.
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 the baseline is 3. The description adds minimal value beyond the schema, only restating that contacts are provided manually with names and titles. It does not elaborate on roles, contacts structure, or company_id beyond what schema descriptions already provide.
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: finding or adding contacts at a company. It also mentions the unique feature of generating and validating email addresses, distinguishing it from sibling tools like search_companies or generate_email. The verb 'find or add' and resource 'contacts at a company' are specific.
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. It does not mention scenarios, exclusions, or why to choose it over other sibling tools. The only implied usage is that you must provide a company_id, but no explicit directions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a personalized outreach email using AI. Creates a draft email based on contact info, company research, and your profile.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | Email tone | formal |
| contact_id | Yes | ID of the contact to email | |
| job_posting_id | No | ID of the job posting (if applying to specific role) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It adds that the tool uses AI and bases output on contact info, company research, and profile, which provides some context. However, it does not disclose side effects (e.g., external API calls, potential latency, output format, or whether it requires prior research). This is adequate but not fully transparent for an AI-agent selecting the 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 sentences, front-loaded with the core purpose, and no redundant information. The description is concise and earns each word.
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 is relatively simple (3 params, 1 required, no output schema). The description explains the main function and inputs but does not explicitly state the return format (draft email content) or any prerequisites (e.g., must have company research completed). It is largely complete for a generation tool, but a bit more detail on output and workflow would improve 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?
Schema coverage is 100% with each parameter having a description, so the baseline is 3. The description adds context by mentioning 'contact info, company research, and your profile,' which loosely relates to contact_id and job_posting_id, but it does not add specific meaning beyond the schema for tone or job_posting_id. Marginal added 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?
The description uses a specific verb ('Generate') and resource ('outreach email'), clearly stating the tool creates a personalized AI-generated draft. This distinguishes it from sibling tools like schedule_email (sending) and schedule_followup (follow-up), as it explicitly says 'draft email'.
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 the tool is for generating outreach emails based on contact info and company research, but it does not explicitly state when to use it versus alternatives (e.g., schedule_email, research_company). No exclusions or recommended workflow are provided, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all outreach campaigns with their status. Shows companies, contacts, and email threads.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum campaigns to return | |
| status | No | Filter by email status | |
| company_id | No | Filter by company ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return content ('Shows companies, contacts, and email threads') but does not reveal safety profile, pagination behavior, or any operational constraints. A simple read operation is implied but not explicit.
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 short sentences deliver the core purpose and return content without redundancy. Every sentence adds value, and the structure is 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?
For a simple list tool with three optional parameters, the description is adequate but incomplete. It omits pagination behavior (e.g., default limit of 50) and does not explain the range of status values, though the schema covers parameter meanings. It is a minimal viable description for a straightforward 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 description coverage is 100%, so the schema already documents limit, status, and company_id. The description adds no additional parameter detail, making the baseline 3 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 uses a specific verb 'List' with the resource 'outreach campaigns' and adds scope with 'with their status'. It is clear and distinguishable from sibling tools like search_companies and find_contacts, though it does not explicitly differentiate.
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 is given on when to use this tool versus alternatives. It only states what it does, leaving the agent to infer appropriate usage. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape a company's website and extract mission, products, culture, tech stack, and recent news using AI.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Specific URL to scrape (defaults to company domain) | |
| company_id | Yes | ID of the company to research |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to rely on, so the description must disclose behavioral traits. It mentions 'using AI' but omits potential limitations such as scraping failures, website accessibility issues, time delays, or data quality variability. This is a significant gap for a web scraping 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 a single sentence that is front-loaded with the action, resource, and output. Every word is necessary, with no redundancy or filler. It is highly concise and efficient.
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 there is no output schema, the description should provide enough detail about return values and edge cases. It lists the extracted data (mission, products, culture, tech stack, news) but does not specify how results are returned, handling of missing websites, or interaction between url and company_id. This makes it minimally viable but with clear 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?
The input schema covers all parameters (company_id required, url optional) with clear descriptions, so the baseline is 3. The description adds no extra parameter-level semantics but does inform about the output fields, which indirectly clarifies intent. It neither strengthens nor weakens the schema's clarity.
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 a specific verb ('scrape') and resource ('a company's website') and enumerates the extracted data types. It is distinct from sibling tools like search_companies or generate_email, establishing a unique purpose.
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 when needing company information scraped from a website. It does not explicitly contrast with alternatives, but the sibling tool names and context make the intended use case clear. It lacks an explicit 'when not to use' but still provides adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule an email for delivery. Uses smart scheduling by default to pick optimal send times (Tue-Thu, 9-11am).
| Name | Required | Description | Default |
|---|---|---|---|
| send_at | No | ISO datetime to send (e.g., 2024-01-15T09:00:00Z) | |
| email_id | Yes | ID of the email to schedule | |
| smart_schedule | No | Use smart scheduling to pick optimal time (ignored if send_at is provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does disclose the default smart scheduling behavior and the optimal time window (Tue-Thu, 9-11am). However, it does not mention whether delivery is guaranteed, cancellation options, or any side effects beyond scheduling.
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. The first states the core purpose, and the second adds a key behavioral detail. Every word earns its place, with no redundancy or filler.
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 a simple parameter set and no output schema, so completeness is adequate. However, given the presence of a similar sibling (schedule_followup), the description lacks differentiation. It also omits any mention of return values or confirmation behavior, which are relevant for scheduling tools.
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 the baseline is 3. The description adds context about smart_schedule's default behavior, which aligns with the schema. It does not add additional meaning for send_at or email_id beyond what the schema already provides.
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 function: 'Schedule an email for delivery.' This is a specific verb+resource pairing. It distinguishes from generate_email (creation) and check_tracking (monitoring), though it does not explicitly differentiate from the sibling schedule_followup.
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 is provided on when to use this tool versus alternatives like generate_email or schedule_followup. The schema implies it operates on an existing email_id, but the description does not mention this prerequisite or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a follow-up email for an outreach that hasn't received a reply. Automatically generates a contextual follow-up message.
| Name | Required | Description | Default |
|---|---|---|---|
| email_id | Yes | ID of the original email to follow up on | |
| days_after | No | Days after original email to send followup (default from config) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds value by revealing that the tool 'automatically generates a contextual follow-up message,' which is non-obvious. However, it does not disclose other important behaviors such as whether the email is sent immediately, if it can be edited before sending, or what happens if a reply arrives before the scheduled send. This is a partial disclosure.
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 that are front-loaded with the primary action and context. Every word earns its place, with no filler or duplication of schema 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?
The description is sufficient for a simple scheduling tool with clear parameters and no output schema. It explains what the tool does, when to use it, and a key side effect (auto-generating the message). However, it does not mention return values or post-scheduling behavior, which is a minor gap given the absence of an output schema.
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 already provides 100% coverage for both parameters, including 'ID of the original email to follow up on' and 'Days after original email to send followup'. The description adds no additional meaning to the parameters, so the baseline score of 3 applies.
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 ('Schedule'), resource ('follow-up email'), and specific context ('for an outreach that hasn't received a reply'). It distinguishes from sibling tools like 'schedule_email' by specifying the follow-up on non-replied outreach, and from 'generate_email' by the scheduling aspect.
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 'for an outreach that hasn't received a reply' provides clear usage context, implying when this tool should be used. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5 but is still effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for companies on job boards or add manually. Use source='manual' to add a specific company by name, or source='indeed' to search job postings.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of companies to return | |
| query | Yes | Company name or job search query | |
| source | No | Source to search: manual (add directly), linkedin, or indeed | manual |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that manual addition is possible (a potential write operation) but does not disclose side effects, persistence behavior, or read-only guarantees. No information about rate limits, auth, or return format is provided.
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, front-loaded with the main purpose and immediately providing actionable source-specific instructions. Every word adds value 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?
The tool has three parameters and no output schema, and the description covers the core purpose and main usage paths. It omits mention of the 'linkedin' source (present in the schema) and does not specify return values, but the description is sufficient for typical use cases.
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%, giving a baseline of 3. The description adds meaningful nuance by explaining that 'query' can be a company name or job search term and clarifies the intent of the 'source' enum values (manual = add directly, indeed = search postings), surpassing the schema's generic 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 the tool's function: searching for companies on job boards or adding them manually. It explicitly differentiates between manual addition and searching Indeed, distinguishing it from sibling tools like research_company or add_job_posting.
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 clear context on when to use each source: 'Use source=\'manual\' to add a specific company by name, or source=\'indeed\' to search job postings.' It lacks explicit exclusion statements or comparisons to sibling tools, but gives practical usage direction.
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.
v1.0.0add_job_postingcheck_trackingfind_contactsgenerate_emaillist_campaignsresearch_companyschedule_emailschedule_followupsearch_companiesScored across 9 tools
Each tool targets a distinct stage in the outreach workflow: company discovery, contact finding, research, job tracking, email generation, scheduling, tracking, follow-up, and campaign overview. Even schedule_email and schedule_followup are clearly differentiated by their descriptions.
All tool names follow a consistent verb_noun pattern in lowercase snake_case (e.g., search_companies, schedule_followup). The pattern is predictable and makes the purpose of each tool immediately clear.
Nine tools is well within the ideal range for a focused domain. Each tool serves a clear function and there is no unnecessary bloat or vague utility.
The set covers the core outreach lifecycle: find companies/contacts, research, track opportunities, generate/schedule emails, monitor responses, and follow up. Minor gaps exist (e.g., no explicit contact update/delete), but the essential workflow is complete.
AI-powered email outreach platform — send campaigns with deliverability tracking.
Run LinkedIn outreach from your AI chat: find leads, launch campaigns, send, and reply.
LinkedIn + cold email outreach: find leads, launch personalized campaigns, manage replies.
Auto-apply to jobs: matches your CV, tailors a fresh CV per posting, and applies for you.
