de en es ja ko ru zh

trykittai-mcp-server

Name: trykittai-mcp-server
Author: avivshafir

by avivshafir

Overview Schema Source Related Servers Discussions Admin

Python

Remote

TryKitt.ai mcp 서버

TryKitt.ai API를 사용하여 이메일 확인 및 검색 기능을 제공하는 FastMCP(Model Context Protocol) 서버입니다. 이 서버를 통해 AI 비서가 높은 정확도와 낮은 반송률로 B2B 이메일 주소를 찾고 검증할 수 있습니다.

특징

이메일 확인 : 고급 SMTP 및 Catchall 확인을 통해 이메일 주소를 확인합니다.
이메일 찾기 : 이름과 회사 도메인을 사용하여 개인의 이메일 주소를 찾습니다.
작업 관리 : 이메일 확인/작업 찾기 추적 및 모니터링
실시간 처리 : 이메일 작업에 대한 즉각적인 결과를 얻으세요
높은 정확도 : <0.1%의 반송률을 제공하는 TryKitt.ai의 고급 검증 알고리즘을 활용합니다.

Related MCP server: ones-wiki-mcp-server

설치

이 저장소를 복제하세요:

지엑스피1

uv를 사용하여 새로운 Python 환경을 초기화합니다.

# Initialize a new uv project (if starting fresh)
uv init

# Or create a virtual environment
uv venv

# Activate the virtual environment
source .venv/bin/activate  # On macOS/Linux

uv를 사용하여 종속성을 설치합니다.

# Using uv (recommended)
uv sync

설정

TryKitt.ai API 키를 받으세요:
- TryKitt.ai를 방문하세요
- 계정에 가입하세요
- API 설정으로 이동하여 API 키를 받으세요.
API 키를 환경 변수로 설정하세요.

export TRYKITT_API_KEY="your_api_key_here"

또는 프로젝트 루트에 .env 파일을 만듭니다.

TRYKITT_API_KEY=your_api_key_here

용법

서버 실행

FastMCP 서버를 시작합니다.

python server.py

서버가 시작되고 MCP 연결을 사용할 수 있게 됩니다.

MCP 클라이언트에 추가

이 서버를 MCP 호환 클라이언트와 함께 사용하려면 클라이언트가 이 서버에 연결되도록 구성해야 합니다.

클로드 데스크탑

Claude Desktop 구성 파일에 다음 구성을 추가하세요.

macOS : ~/Library/Application Support/Claude/claude_desktop_config.json Windows : %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "trykittai": {
      "command": "python",
      "args": ["/path/to/your/trykittai-mcp-server/server.py"],
      "env": {
        "TRYKITT_API_KEY": "your_api_key_here"
      }
    }
  }
}

다른 MCP 클라이언트

다른 MCP 호환 클라이언트의 경우 다음에 연결하도록 구성하세요.

명령어 : python
인수 : ["/path/to/your/trykittai-mcp-server/server.py"]
환경 변수 : TRYKITT_API_KEY=your_api_key_here

uv와 함께 사용

uv를 사용하는 경우 다음을 사용하여 서버를 실행할 수도 있습니다.

{
  "mcpServers": {
    "trykittai": {
      "command": "uv",
      "args": ["run", "python", "server.py"],
      "cwd": "/path/to/your/trykittai-mcp-server",
      "env": {
        "TRYKITT_API_KEY": "your_api_key_here"
      }
    }
  }
}

참고 : /path/to/your/trykittai-mcp-server 프로젝트 디렉토리의 실제 절대 경로로 바꾸고, your_api_key_here 실제 TryKitt.ai API 키로 바꾸세요.

사용 가능한 도구

1. 이메일 인증( `verify_email_send` )

이메일 주소가 유효하고 전달 가능한지 확인하세요.

매개변수:

email (필수): 확인할 이메일 주소
custom_data (선택 사항): 요청과 연결할 사용자 정의 데이터

예:

result = await verify_email_send("john.doe@example.com")

2. 이메일 찾기( `find_email` )

이름과 회사 도메인을 기반으로 해당 사람의 이메일 주소를 찾아보세요.

매개변수:

full_name (필수): 해당 사람의 전체 이름
domain (필수): 회사 도메인 또는 웹사이트
linkedin_url (선택 사항): 정확도를 높이기 위한 LinkedIn 프로필 URL
custom_data (선택 사항): 요청과 연결할 사용자 정의 데이터

예:

result = await find_email(
    full_name="John Doe",
    domain="example.com",
    linkedin_url="https://linkedin.com/in/johndoe"
)

3. 작업 상태( `get_job_status` )

이전에 제출한 작업의 상태를 확인합니다.

매개변수:

job_id (필수): 확인할 작업의 ID

예:

result = await get_job_status("job_123456")

4. 작업 목록( `list_jobs` )

모든 작업을 나열합니다(참고: 이 엔드포인트는 가용성이 제한될 수 있습니다).

예:

result = await list_jobs()

API 응답 형식

이메일 확인 성공

{
  "id": "job_123456",
  "status": "completed",
  "result": {
    "email": "john.doe@example.com",
    "valid": true,
    "deliverable": true,
    "confidence": 0.95,
    "verification_type": "smtp_catchall"
  }
}

성공적인 이메일 찾기

{
  "id": "job_789012",
  "status": "completed",
  "result": {
    "email": "john.doe@example.com",
    "confidence": 0.88,
    "sources": ["pattern_matching", "web_scraping"]
  }
}

오류 처리

서버는 다양한 오류 시나리오를 처리합니다.

잘못된 API 키
속도 제한
네트워크 시간 초과
잘못된 이메일 형식입니다
도메인 확인 실패

일반적인 오류 응답:

{
  "error": "Invalid API key",
  "code": 401
}

구성

환경 변수

TRYKITT_API_KEY : TryKitt.ai API 키(필수)

SSL 구성

서버는 TryKitt.ai의 API 엔드포인트와 작동하도록 구성되어 있습니다. 호환성을 위해 현재 SSL 검증은 비활성화되어 있습니다.

개발

프로젝트 구조

trykittai-mcp-server/
├── server.py          # Main FastMCP server implementation
├── pyproject.toml     # Project dependencies and configuration
├── uv.lock           # Dependency lock file
├── README.md         # This file
├── LICENSE           # MIT License
└── .venv/            # Virtual environment

종속성

fastmcp : MCP 서버 구축을 위한 FastMCP 프레임워크
httpx : API 요청을 위한 비동기 HTTP 클라이언트
pydantic : 데이터 검증 및 설정 관리

TryKitt.ai 소개

TryKitt.ai는 다음과 같은 기능을 갖춘 고급 이메일 확인 및 찾기 서비스입니다.

개별 사용자에게 무제한 무료 이메일 검증을 제공합니다.
고급 검증을 통해 0.1% 미만의 반송률 달성
대체 솔루션보다 2~5배 더 빠르게 작동합니다.
포괄적인 검증을 위해 엔터프라이즈 ID 서버를 사용합니다.
작업 변경 사항을 감지하고 실제 시스템과 비교하여 검증합니다.

자세한 내용은 https://trykitt.ai/ 에서 확인하세요.

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

기여하다

저장소를 포크하세요
기능 브랜치 생성
변경 사항을 만드세요
해당되는 경우 테스트를 추가하세요
풀 리퀘스트 제출

지원하다

다음과 관련된 문제:

이 MCP 서버: 이 저장소에서 문제를 엽니다.
TryKitt.ai API: TryKitt.ai 지원팀에 문의하세요
FastMCP 프레임워크: FastMCP 설명서 확인

변경 사항

v1.0.0

이메일 확인 및 검색 기능을 갖춘 초기 릴리스
작업 상태 추적
실시간 처리 지원
FastMCP 통합

Available Tools

4 tools

find_emailC

Find an email address for a person.

Args:
    full_name: The full name of the person
    domain: The company domain or website
    linkedin_url: Optional LinkedIn profile URL
    custom_data: Optional custom data to associate with the request

ParametersJSON Schema

Name	Required	Description	Default
`full_name`	Yes
`domain`	Yes
`linkedin_url`	No
`custom_data`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'finds' an email address, implying a read-only operation, but does not specify accuracy, data sources, rate limits, or authentication needs. For a tool with no annotations and potential privacy implications, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the purpose, followed by parameter details. It uses a clear structure with bullet points for args. However, the parameter explanations are very brief and could be more informative, slightly reducing efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of finding email addresses, no annotations, no output schema, and low parameter coverage, the description is incomplete. It lacks details on return values, error handling, data sources, and accuracy, which are crucial for effective tool use. The description does not adequately compensate for the missing structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal semantics beyond the input schema. It lists parameters with brief explanations (e.g., 'full_name: The full name of the person'), but with 0% schema description coverage, it does not fully compensate. The explanations are basic and do not provide format details or usage examples, leaving gaps for the required parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Find an email address for a person.' It specifies the verb ('find') and resource ('email address'), but does not distinguish it from sibling tools like 'verify_email_send', which might have overlapping functionality. The purpose is specific but lacks sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 sibling tools like 'verify_email_send' or specify contexts where this tool is preferred. Usage is implied only through the parameter descriptions, but no explicit when/when-not instructions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_job_statusB

Get the status of a job.

Args:
    job_id: The ID of the job to check

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] the status of a job,' implying a read-only operation, but doesn't clarify aspects like whether it requires authentication, has rate limits, returns specific status formats (e.g., pending, completed), or handles errors. This leaves significant gaps for an agent to understand how to use it effectively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise and well-structured. It starts with a clear purpose statement, followed by a brief 'Args' section that lists the parameter with a simple explanation. There's no unnecessary information, and every sentence serves a functional role in guiding usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, error handling, or what the status output looks like (e.g., string values, timestamps). For a tool that likely returns critical operational data, this leaves the agent without enough context to use it reliably in complex scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaningful context for the single parameter: 'job_id: The ID of the job to check.' This clarifies that 'job_id' is an identifier used to retrieve status, which is helpful since schema description coverage is 0% (the schema only provides a title and type without explanation). With one parameter, the baseline is 4, and the description compensates well by explaining its purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the status of a job.' It uses a specific verb ('Get') and resource ('status of a job'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'list_jobs', which might provide a broader overview rather than specific status checks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 doesn't mention sibling tools like 'list_jobs' for listing multiple jobs or other tools for related operations. There's no context about prerequisites, such as needing a job ID from another operation, or when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_jobsD

List jobs

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1.8/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. 'List jobs' doesn't indicate whether this is a read-only operation, whether it requires authentication, what format results are returned in, if there are rate limits, or any other behavioral characteristics. The description fails to provide any operational context beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While technically concise with just two words, this description represents under-specification rather than effective brevity. The single phrase 'List jobs' fails to provide necessary context that would help an agent understand when and how to use this tool. Conciseness should not come at the expense of clarity and completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description 'List jobs' is completely inadequate. It doesn't explain what constitutes a 'job' in this context, what information is returned, whether results are paginated, or any other operational details. The description fails to provide the minimal context needed for effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the input schema has 100% description coverage (though empty). With no parameters to document, the description doesn't need to compensate for schema gaps. The baseline for zero-parameter tools is 4, as there's no parameter semantics burden on the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List jobs' is a tautology that merely restates the tool name without adding meaningful context. It specifies the verb ('list') and resource ('jobs'), but provides no differentiation from sibling tools like 'get_job_status' or additional scope information. This minimal description fails to clarify what type of jobs are being listed or under what conditions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides absolutely no guidance on when to use this tool versus alternatives like 'get_job_status' or other sibling tools. There's no mention of appropriate contexts, prerequisites, or exclusions. Users must infer usage patterns from the tool name alone, which is insufficient for effective tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_email_sendC

verify an email using trykitt.

Args:
    email: The email address to verify
    custom_data: Optional custom data to associate with the request

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes
`custom_data`	No

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'verify an email using trykitt' but fails to explain key traits like whether this is a read-only or mutative operation, what the expected outcome is (e.g., sends an email, returns a status), or any rate limits or authentication needs. This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the main purpose, followed by parameter details in a structured 'Args:' section. It avoids unnecessary elaboration, but the lack of context and behavioral details means it could be more informative without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (2 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'verify' means in practice, what happens after invocation (e.g., sends an email, returns a job ID), or how it relates to sibling tools, leaving the agent with insufficient context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description lists parameters ('email' and 'custom_data') and notes that 'custom_data' is optional, adding basic semantics beyond the input schema. However, with 0% schema description coverage, it doesn't fully compensate by explaining parameter formats (e.g., email validation rules, custom_data structure), leaving the agent with incomplete information for proper usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'verify an email using trykitt' which provides a basic verb+resource combination, but it's vague about what verification entails (e.g., sending a verification email, checking validity). It doesn't distinguish from siblings like 'find_email' or 'get_job_status', leaving ambiguity about the specific action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 'find_email' or 'get_job_status'. The description lacks context about prerequisites, such as whether this initiates a verification process or checks an existing one, leaving the agent without clear usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesAug 15, 2025
- First observedfind_email
- First observedget_job_status
- First observedlist_jobs
- First observedverify_email_send

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0

Scored 2026-04-18 10:00 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: find_email locates email addresses, get_job_status checks job status, list_jobs enumerates jobs, and verify_email_send validates emails. The descriptions clearly differentiate their functions, eliminating any potential for agent misselection.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern (find_email, get_job_status, list_jobs, verify_email_send), with all tools using snake_case. The minor deviation is 'verify_email_send' which includes an extra verb 'send', but overall the pattern is predictable and readable.

Tool Count5/5

With 4 tools, this server is well-scoped for its purpose of email and job management. Each tool earns its place by covering distinct aspects: email discovery, job tracking, and email verification, without being overly sparse or bloated.

Completeness3/5

The tool surface covers core operations like finding and verifying emails, and managing jobs, but has notable gaps. For example, there are no tools to create or delete jobs, or to handle email sending beyond verification, which could limit agent workflows in this domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Second server!
com.fenetresurciel.verylongmcp
A non functional MCP server (yet)
Developer Tools
2
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2
PortOAuth
io.port
Port.io mcp server
Developer Tools CI/CD & DevOps Cloud Platforms
214
mattest4-qyroac
ai.fugentic
Fugentic MCP server for mattest4-qyroac
Developer Tools
1

Related MCP Servers

mcp-server-cloudbrowser
Browser Automation Web Scraping
clpublic
F
license
Not graded
quality
D
maintenance
mcp-server-cloudbrowser
Updated a year ago (2025-04-26 06:28 UTC)
2
-
ones-wiki-mcp-server
Content Management Systems Developer Tools Documentation Access
brianxiadong
F
license
Not graded
quality
D
maintenance
ones-wiki-mcp-server
Updated a year ago (2025-05-29 03:59 UTC)
7
-
mcp-server-test
Vector Databases Blockchain
JussCubs
F
license
A
quality
D
maintenance
mcp-server-test
Updated a year ago (2025-04-04 22:28 UTC)
4
-
buildkite-mcp-server
CI/CD & DevOps Developer Tools Code Execution
buildkite
A
license
Not graded
quality
A
maintenance
Official MCP Server for Buildkite.
Updated a day ago (2026-09-11 20:39 UTC)
54
MIT

Appeared in Searches

Search for 'tc34jqkh7w'

TryKitt.ai mcp 서버

특징

설치

설정

용법

서버 실행

MCP 클라이언트에 추가

클로드 데스크탑

다른 MCP 클라이언트

uv와 함께 사용

사용 가능한 도구

1. 이메일 인증( verify_email_send )

2. 이메일 찾기( find_email )

3. 작업 상태( get_job_status )

4. 작업 목록( list_jobs )

API 응답 형식

이메일 확인 성공

성공적인 이메일 찾기

오류 처리

구성

환경 변수

SSL 구성

개발

프로젝트 구조

종속성

TryKitt.ai 소개

특허

기여하다

지원하다

변경 사항

v1.0.0

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

1. 이메일 인증( `verify_email_send` )

2. 이메일 찾기( `find_email` )

3. 작업 상태( `get_job_status` )

4. 작업 목록( `list_jobs` )