Exposes the full AI Ark API (company search, people search, reverse lookup, phone finder, personality analysis, email export, and more) as MCP tools. Supports OAuth 2.1 credential input with per-connection credentials.
AI Ark MCP exposes 8 tools with HTTP transport via FastMCP/Starlette. Tool naming is generally verb-first and clear (search_companies, search_people, export_people_with_email, get_export_results, reverse_people_lookup, find_mobile_phone, analyze_personality, oauth_authorize). Descriptions are present for all tools and are substantive (120 - 300+ chars), explaining what the tool does and common workflows. Parameter schemas are explicitly defined with types (object|string|null, integer) and descriptions for most fields. However, significant gaps exist: (1) Output schemas are NOT documented, responses are described informally in tool descriptions but no structured return type is specified. (2) Many parameters lack enums or format constraints (e.g., company_types and seniorities should be enums, but are described as comma-separated strings without formal validation). (3) Error handling guidance is minimal, no recovery suggestions or categorization of retryable vs. fatal errors. (4) oauth_authorize accepts credentials (username, password, access_token) as parameters, which violates secret-injection patterns; these should be environment-injected or stored server-side, not exposed in tool signatures. (5) No idempotency hints or confirmation patterns for destructive operations like export_people_with_email or oauth_authorize. (6) Parameter relationships (e.g., 'if filters_json is provided, all other params are ignored') are documented but not formalized. Overall, the server demonstrates competent tool design with good naming and descriptions, but lacks the rigor expected of production tools: no output schemas, weak validation, and security lapses in credential handling.
Analyze personality traits (DISC model) for a person by LinkedIn URL.
Export people WITH verified emails. Long-running operation returns immediately with a trackId; poll get_export_results(track_id) to retrieve results (typically 15-120 seconds). Use this for bulk people + email exports.
Find mobile phone number for a person by LinkedIn URL.
Poll the status of an export job (from export_people_with_email or other export tools). Returns "processing" while running, then the full contact + email data once ready (typically 15-120 seconds after export_people_with_email).
Start an OAuth 2.1 authorization flow. Requires passing your AI Ark API credentials (username and password, or pre-issued access token). Returns an authorization URL and registers a client for the callback.
Output schemas are not documented. Tool descriptions mention what fields are returned (name, domain, industry, etc. for companies; trackId for exports; etc.), but there is no formal JSON Schema specification of the response structure, types, or required fields. LLMs cannot plan downstream calls or extract data reliably without explicit output schemas.
Credentials (username, password, access_token) exposed as tool parameters in oauth_authorize. This violates secret-injection pattern, agent traces and logs will capture these secrets. Credentials should be injected server-side via environment variables or a secure vault, or passed through a separate authenticated channel (e.g., HTTP header middleware).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 73 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Reverse lookup: find a person by email, phone, or LinkedIn URL.
Search 69M+ enriched company profiles. Returns company data instantly (no polling needed). Results include: name, domain, industry, location, employee count, revenue, technologies, LinkedIn URL, logo, and description. Use the flat parameters for simple queries. For advanced nested filters, pass the full API body as filters_json (dict or JSON string).
Search 400M+ people without emails (instant results). Returns profiles with job titles, companies, locations, LinkedIn URLs, and more.
Enum constraints missing for multi-value parameters. Parameters like 'company_types' (lists SELF_EMPLOYED, SOLE_PROPRIETORSHIP, etc. in description) and 'seniorities' (C_LEVEL, VP, DIRECTOR, etc.) should be declared as enums in the schema, not loose comma-separated strings. Free-form strings invite hallucinated invalid values.
No error recovery guidance. Errors are returned as {"error": "...", "details": ...} but do not guide the agent on what to do next (retry, ask user, try a different tool). No categorization of retryable (network error) vs. user-fixable (invalid param) vs. fatal (auth failed) errors.
No confirmation or dry-run pattern for state-changing operations. export_people_with_email and oauth_authorize both modify state and trigger async operations but offer no 'confirm before execute' or 'dry-run' option. Agents can accidentally export large contact lists or authorize unintended sessions.
Parameter type ambiguity in schema definitions. Filters_json is declared as type 'object|string|null', which is valid but non-standard in JSON Schema (typically a oneOf array). More critically, integer parameters like 'page', 'size', 'founded_year_start', 'revenue_start' lack min/max constraints. An agent could pass page=999999 or size=1000000, breaking the service.
Long-running operations (export_people_with_email) return immediately with trackId and require polling via get_export_results, but no explicit timeout or SLA is documented. If polling exceeds 120 seconds (max stated), agents do not know whether to retry indefinitely or give up. No jitter or backoff guidance.
Pagination support is present (page, size params) but incomplete. No documentation of what 'size' defaults to, no 'total_count' or 'has_next' field guidance in output schema, and no next_cursor alternative for stable iteration. Large result sets risk context window overflow.