Um servidor Model Context Protocol (MCP) que expõe a Harvest API do Greenhouse como ferramentas majoritariamente de leitura para Claude Desktop / Claude Code / qualquer cliente compatível com MCP. Seis ferramentas de leitura cobrem as perguntas diárias do recrutador (“quais candidatos estão parados na fase X por >Y dias?”, “qual é o funil para esta vaga?”, “mostre o histórico deste candidato”), uma ferramenta de escrita cautelosa destaca candidatos parados para o recrutador agir. Projetado para o recrutador que vive no Claude e quer o estado do ATS sem troca de contexto, e para o recruiting engineer construindo workflows agênticos que precisam de acesso de leitura ao ATS.
O scaffold é entregue como um pacote Python importável a partir do disco. Ele NÃO foi testado em runtime contra um tenant ao vivo do Greenhouse — o aviso é repetido no README e no topo de server.py. O uso em produção requer que o recruiting engineer conecte as credenciais, limite o rate, e verifique as chamadas disparadas contra um ambiente não-produção do Greenhouse primeiro.
Quando usar
- O recrutador ou recruiting engineer quer o estado do ATS disponível em conversas do Claude e está disposto a instalar um servidor MCP (baixo atrito no Claude Desktop e Claude Code, mais setup em clientes MCP personalizados).
- A equipe tem acesso à Harvest API do Greenhouse (Harvest é a API de leitura-escrita; Job Board é a de somente-leitura pública — este servidor usa a Harvest).
- Acesso majoritariamente de leitura se encaixa no caso de uso. As escritas do servidor são limitadas a uma ferramenta cautelosa (
note_stage_stuck) que adiciona uma nota interna; nenhuma mutação do estado do candidato é exposta por padrão. - A engenharia de recrutamento ou TI tem a postura de segurança para lidar com uma API key com escopo Harvest. O log de auditoria do servidor é o log de auditoria.
Quando NÃO usar
- Setup pronto para produção e testado em runtime necessário hoje. Este é um scaffold. Os READMEs dizem isso; os docstrings dizem isso. Use-o como ponto de partida, não como deploy finalizado.
- Uso em SaaS multi-tenant. O modelo de autenticação do servidor é single-tenant (uma API key, uma instância do Greenhouse). Multi-tenant requer reestruturação não trivial.
- Workflows pesados em escrita. O servidor é intencionalmente majoritariamente de leitura. Se o caso de uso precisa mover candidatos entre fases, publicar em quadros de vagas ou enviar comunicações a candidatos, essas precisam de revisão de segurança separada por ferramenta e justificativa explícita por ferramenta conforme o guidance do recruiting cursor-rule.
- Armazenar dados de candidatos fora do Greenhouse. O servidor retorna dados de candidatos para a sessão Claude chamante; a postura de tratamento de dados da sessão é responsabilidade do recrutador. Não registre nomes brutos de candidatos ou PII na sua própria tabela de auditoria — o log de auditoria captura apenas
candidate_id. - Contornar a postura de consentimento do candidato. Os dados do Greenhouse são consented pelo candidato para fins de contratação. Puxá-los para workflows agênticos não estende esse consentimento. Permaneça dentro dos propósitos de processamento divulgados.
Setup
- Instale o pacote. A partir de
apps/web/public/artifacts/mcp-server-greenhouse-recruiting/:
O pacote é estruturado como um projeto Python instalável via uv/pip compip install -e .pyproject.toml. - Defina as credenciais. Duas variáveis de ambiente:
GREENHOUSE_API_KEY(Harvest API key do Greenhouse → Configure → Dev Center → API Credential Management; escolha permissões de leitura em cada verbo Harvest que você não precisa escrever) eGREENHOUSE_USER_ID_FOR_ON_BEHALF_OF(o ID do usuário que o Greenhouse vai atribuir as escritas, necessário paranote_stage_stuck). - Registre com o cliente MCP. Para o Claude Desktop, adicione ao
claude_desktop_config.json:
Para o Claude Code, o equivalente vai no bloco MCP do{ "mcpServers": { "greenhouse-recruiting": { "command": "uv", "args": ["run", "greenhouse-recruiting-mcp"], "env": { "GREENHOUSE_API_KEY": "...", "GREENHOUSE_USER_ID_FOR_ON_BEHALF_OF": "..." } } } }.claude/settings.jsondo projeto. - Verificação de sanidade contra staging. O Greenhouse oferece um ambiente de staging separado para clientes pagantes. Conecte o servidor ao staging primeiro. Execute o comando
python -m greenhouse_recruiting_mcp.smokeincluído (uma verificação não testada em runtime incluída no bundle que verifica se as credenciais se autenticam e os headers de rate-limit são analisados). - Mudança para produção. Somente após a validação em staging, troque as variáveis de ambiente para a API key de produção. O servidor roda localmente para o cliente MCP; nenhum deploy separado é necessário para uso de recrutador único. Para uso da equipe, rode em um container compartilhado com um gateway MCP por recrutador.
O que o servidor expõe
Sete ferramentas. Seis são de leitura; uma é a escrita cautelosa. Por orientação do recruiting cursor-rule, escritas precisam de justificativa explícita por ferramenta — note_stage_stuck a tem documentada no docstring de server.py.
Ferramentas de leitura
list_candidates_in_stage— dado um ID de vaga e um nome de fase, retorna os candidatos atualmente nessa fase com seu timestamp de último-toque. Útil para consultas “quem está parado no debrief do on-site?”.get_candidate_history— dado um ID de candidato, retorna seu histórico de fase (entradas, saídas, timestamps, quem os moveu). Útil para carregamento de contexto antes de uma triagem do recrutador.list_jobs_open— lista todas as vagas abertas com equipe, hiring manager, opened_at, target_close_date. Útil para a visão geral “no que estamos trabalhando” do líder de recrutamento.get_funnel_for_job— dado um ID de vaga, retorna a contagem de candidatos por fase. Útil para verificações de saúde do funil.list_jobs_stalled— lista vagas onde nenhum candidato avançou em N dias (padrão 7). Útil para capturar reqs parados antes que o hiring manager perceba.search_candidates_by_attribute— dado um nome de campo personalizado e um valor, retorna candidatos correspondentes. Útil para filtragem ad-hoc que a interface do Greenhouse não expõe.
Ferramenta de escrita
note_stage_stuck— dado um ID de candidato e uma nota de texto livre, adiciona uma nota interna ao registro do candidato. Usado para registrar “Claude sinalizou este candidato como parado na fase por >14 dias” para que a ação seja visível na trilha de auditoria e não silenciosa. Por normas de recruiting-engineer: toda escrita produz uma entrada no log de auditoria atribuída via o headerOn-Behalf-Of.
Custo real
- Quota de API do Greenhouse — a Harvest API tem rate-limit de 50 req/10s por API key por IP. O servidor inclui um rate limiter de token-bucket (configurável, padrão 40 req/10s) que limita antes do teto. Bursts acima disso recebem 429s sem header
Retry-After(comportamento documentado do Greenhouse); a lógica de backoff do servidor lida com isso. - Tokens de LLM — dependem inteiramente do que a sessão Claude chamante faz com os dados. O servidor em si retorna JSON estruturado; o orçamento de prompt da sessão Claude é o custo.
- Custo de hospedagem do servidor — roda localmente para o cliente MCP. Custo contínuo zero para uso de recrutador único. Deploy em equipe em um container compartilhado é no máximo uma VM pequena ($5-15/mês).
- Tempo de setup — 60 minutos incluindo a verificação de sanidade em staging e o registro do cliente MCP. O tempo do recruiting engineer é o custo determinante.
Métrica de sucesso
Difícil de medir diretamente. A métrica honesta:
- Contagem de sessões Claude/semana usando o MCP — quantas vezes por semana o recrutador ou recruiting engineer usou uma sessão Claude que chamou o MCP. Se for menos de 5 por semana após um mês, o caso de uso não está lá.
- Tempo médio de troca de contexto economizado por sessão Claude — qualitativo; a própria avaliação do recrutador de “quanto tempo teria levado essa pergunta sem o MCP, na interface do Greenhouse?” O MCP ganha seu custo de setup quando a resposta é regularmente >2 minutos por pergunta.
vs alternativas
- vs interface do Greenhouse diretamente. A interface é a escolha certa quando o recrutador já está no Greenhouse por outros motivos. O MCP ganha seu custo de setup quando o recrutador está no Claude por outros motivos (redigindo outreach, resumindo notas, construindo consultas Boolean) e obter o estado do ATS seria uma troca de contexto.
- vs integrações de chatbot nativas do Greenhouse. O Greenhouse oferece integrações com Slack e outras superfícies que expõem o estado do ATS. Escolha essas se a equipe vive no Slack. Escolha o MCP se a equipe vive no Claude.
- vs script Python DIY contra a Harvest. Mesmos dados, mas o MCP disponibiliza os dados para QUALQUER cliente MCP (Claude Desktop, Claude Code, Cursor, outros conforme a adoção do MCP cresce), não apenas para o script.
- vs consulta direta pela API do Greenhouse. Possível para usuários técnicos, mas cada consulta é um ciclo de curl-e-parse. O MCP envolve isso em forma de tool-call para o Claude.
Pontos de atenção
- Não testado em runtime contra um tenant ao vivo. Proteção: explicitamente avisado no README e no docstring do módulo
server.py. O deploy em produção requer que o recruiting engineer verifique cada ferramenta contra um tenant de staging primeiro. O smoke test incluído é uma verificação de credenciais/rate-limit, NÃO uma validação ferramenta por ferramenta. - Esgotamento do rate limit. Proteção: rate limiter de token-bucket no servidor com padrão de 40 req/10s (abaixo do teto de 50 req/10s do Greenhouse). Configurável; diminua se outros sistemas compartilham a API key.
- Vazamento de PII de candidatos para o contexto do modelo de chat. Proteção: o servidor retorna os dados que a API retorna (incluindo nomes e e-mails) para a sessão Claude. A postura de tratamento de dados da sessão é responsabilidade do recrutador. O README diz explicitamente: não cole transcrições de sessão em canais Slack compartilhados.
- Deriva da ferramenta de escrita. Proteção: apenas
note_stage_stucké exposta como escrita. As outras seis ferramentas não têm caminhos de escrita. Se um recruiting engineer adicionar novas ferramentas de escrita, o template de revisão por ferramenta no README deve ser preenchido e o propósito da ferramenta documentado na seção de registrotools/deserver.py. - Expansão de escopo da API key. Proteção: o README documenta os verbos Harvest mínimos necessários (somente-leitura em
candidates,applications,jobs,users; escrita emcandidates.notesapenas). Keys com escopo mais amplo silenciosamente tornam o servidor uma superfície de maior impacto. - Deriva de configuração multi-tenant. Proteção: o servidor é single-tenant por design. Deploys multi-tenant requerem reestruturação não trivial; o README avisa sobre isso em vez de mascarar.
Stack
O bundle do artefato fica em apps/web/public/artifacts/mcp-server-greenhouse-recruiting/ e contém:
pyproject.toml— metadados do pacote, dependências, entrypointgreenhouse-recruiting-mcpREADME.md— instalação, variáveis de ambiente, registro do cliente MCP, procedimento de verificação de sanidade, modelo de segurança, limites conhecidossrc/greenhouse_recruiting_mcp/__init__.py— init do pacotesrc/greenhouse_recruiting_mcp/server.py— servidor MCP com sete definições de ferramenta e implementações de dispatch
Ferramentas que o workflow assume que você usa: Greenhouse (o ATS), Claude (o cliente MCP). Para o servidor MCP paralelo do Ashby, veja o MCP do Ashby. Para guardrails mais amplos de recruiting-engineer, veja o cursor rule de recruiting engineer.
Conceitos relacionados: ATS vs recruiting CRM, stack de tecnologia de recrutamento.