Coresignal

The official MCP server for Coresignal — bring fresh B2B data on 895M+ employees, 70M+ companies, and 468M+ job postings straight into your AI assistant.

От сообществаРаботаетБез входаГлобальныйБесплатноМожет изменять данные

Что умеет

  • Artifact Read: Read rows back out of an already-delivered artifact. FREE — 0 credits. The records were billed when entity_fetch / email_enrich collected them, and they live in the artifact store. This
  • Entity Search: Search employees / companies / jobs by natural language (dynamic fields). Parses the NL query into an ES DSL search via /fast (20 credits) and caches it under a returned ``cache_id``, t
  • Entity Fields: Find the field names most relevant to ``keywords`` (FREE, offline). Returns only a ranked subset of an entity's fields — not the full 285-340 name vocabulary — to keep the client's cont

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

The official MCP server for Coresignal — bring fresh B2B data on 895M+ employees, 70M+ companies, and 468M+ job postings straight into your AI assistant.

Как подключить

Как подключить Coresignal к Claude

Адрес сервера, который нужно вставить в настройках Claude:

https://coresignal--coresignal.run.tools

  1. Откройте Claude (сайт claude.ai или приложение для компьютера).
  2. Перейдите в Настройки → Коннекторы (в английском интерфейсе: Settings → Connectors).
  3. Нажмите Добавить пользовательский коннектор (Add custom connector).
  4. Вставьте адрес сервера, скопированный ниже, в поле URL удалённого MCP-сервера и нажмите Добавить.
  5. В чате нажмите + → Коннекторы и включите новый коннектор.

Пользовательские коннекторы доступны на тарифах Free, Pro, Max, Team и Enterprise. На Free можно добавить только один. В Team и Enterprise коннектор сначала добавляет владелец организации в Настройки организации → Коннекторы.

Авторизация

После нажатия Добавить откроется окно входа в сервис. Войдите под своим аккаунтом и подтвердите доступ. Пароль Claude не видит.

Как подключить Coresignal к ChatGPT

Адрес сервера, который нужно вставить в настройках ChatGPT:

https://coresignal--coresignal.run.tools

  1. Откройте ChatGPT в браузере (chatgpt.com). Нужен тариф Plus, Pro, Business, Enterprise или Edu.
  2. Один раз включите режим разработчика: Настройки → Приложения → Дополнительные настройки → Режим разработчика (Settings → Apps → Advanced settings → Developer mode).
  3. Откройте Настройки → Коннекторы и нажмите Создать (Create).
  4. Заполните форму: Название (любое), Описание (одна фраза, что делает сервис), URL MCP-сервера (скопируйте ниже).
  5. В поле Аутентификация выберите OAuth, если сервис требует вход, иначе Нет. Нажмите Создать.
  6. В новом чате откройте + → Приложения/Коннекторы и включите коннектор.

Название раздела у OpenAI менялось (Connectors → Apps/Plugins). Если пункт называется иначе, ищите «режим разработчика» в настройках. В рабочих пространствах Business/Enterprise администратор должен разрешить пользовательские коннекторы.

Авторизация

При первом использовании ChatGPT откроет окно входа в сервис. Войдите и подтвердите доступ.

Как подключить Coresignal к Cursor

Адрес сервера, который нужно вставить в настройках Cursor:

https://coresignal--coresignal.run.tools

Быстрый способ: нажмите кнопку Открыть в Cursor ниже, Cursor сам предложит добавить сервер.

Вручную:

  1. В Cursor откройте Settings → Cursor Settings → MCP и нажмите Add new global MCP server.
  2. Вставьте JSON, скопированный ниже, в открывшийся файл ~/.cursor/mcp.json (для одного проекта: .cursor/mcp.json в корне проекта).
  3. Сохраните файл. Сервер появится в списке MCP; при необходимости пройдите авторизацию по кнопке рядом с ним.

Авторизация

Если сервис требует вход, рядом с сервером в списке MCP появится кнопка авторизации.

Список инструментов сервера (5)

Технические названия из tools/list. Нужны только разработчикам.

artifact_readRead rows back out of an already-delivered artifact. FREE — 0 credits. The records were billed when entity_fetch / email_enrich collected them, and they live in the artifact store. This reads that file over the authenticated MCP session, so a client with NO shell and NO filesystem (Claude Desktop, chat clients) can still get at data that was delivered as a url. Re-calling entity_fetch to "recover" a url result pays the full per-record price again for records you already own — call this instead. Args: artifact_name: 'artifact_name' from the url-delivery response. offset: first row, 0-based. limit: how many rows. Returns: str: JSON {artifact_name, count, total_rows, offset, next_offset, rows, credits_consumed: 0}. ``rows`` are parsed objects for .jsonl and raw lines for .csv. ``next_offset`` is null on the last page. Errors -> "Error: <message>".
entity_searchSearch employees / companies / jobs by natural language (dynamic fields). Parses the NL query into an ES DSL search via /fast (20 credits) and caches it under a returned ``cache_id``, then runs that query against the internal Elasticsearch index and reshapes each hit into a "dynamic" record so you can judge WHY it matched. The search itself is not Coresignal-billed, so EVERY call costs a flat 20 credits and ALWAYS returns ``total_count`` (the exact number of records the query matched) and the ``cache_id``. ``total_count`` tells you how many results exist beyond the returned page, and therefore how many entity_fetch chunks a full collection would take (1000 records each). ``limit`` only caps how many result rows come back: 0 = none (just total_count + cache_id), 1..20 = that many rows. Each row has three layers: (1) the preview floor (the fields the old preview returned, always present); (2) the root fields the query filtered on (raw names — the evidence preview omitted); (3) the query-matched nested entries (e.g. the specific experience / funding_round / job_source that matched), each carrying always-on context fields plus the queried sub-fields. Long text values are truncated (full text is available via entity_fetch); entity/id fields and housekeeping flags are never returned. Ids are never returned. To pull records, pass the ``cache_id`` to entity_fetch (which collects the matched records directly), or hand-pick cosi ids from the result rows and pass those to entity_fetch. Args: entity_type: 'employee' | 'company' | 'job'. query: natural-language query. limit: result rows to return, 0..20 (default 20; 0 = total_count + cache_id, no rows). Returns: str: JSON {entity_type, cache_id, total_count, count, results, credits_consumed}. ``count`` is the number of rows in THIS response (0 when limit=0); ``total_count`` is the exact total the query matched; ``results`` is the row list (empty when limit=0). Errors -> "Error: <message>".
entity_fieldsFind the field names most relevant to ``keywords`` (FREE, offline). Returns only a ranked subset of an entity's fields — not the full 285-340 name vocabulary — to keep the client's context small. Matching is semantic (model2vec embeddings over the field names), so 'salary' surfaces the compensation fields even though none is literally named "salary". The match is intentionally LOOSE: the result is a candidate set, not a curated one, so re-evaluate the returned names and pass only the ones you actually need to entity_fetch — the client never has to see (or send) the whole field list. The returned strings are exactly the tokens ``entity_fetch.fields`` accepts: flat scalars plus dotted paths for nested fields (e.g. 'experience.position_title'). Broaden ``keywords`` or raise ``top_k`` if you need more; an empty result means nothing cleared the relevance floor. Args: entity_type: 'employee' | 'company' | 'job'. keywords: free-text description of the wanted fields. top_k: max names to return (default/cap from config). Returns: str: JSON array of ranked field-name strings, e.g. ["experience.position_title", "active_experience_title", ...].
entity_fetchCollect full/projected records (20 credits each; jobs 1). Two ways to choose what to fetch (exactly one): * ``ids`` — 1..20 specific cosi ids you hand-picked from result rows. * ``cache_id`` — a handle from entity_search; its cached query is resolved to up to ``limit`` matched ids server-side (the resolve is free) and those records are collected. Ids never reach the client. CONFIRM the count with the user before a large cache_id fetch (cost + ~40s for 1000). Field scope is chosen via ``field_mode`` and is confirmed BEFORE any spend. Because every mode bills the same per record, the default ``field_mode='ask'`` never silently picks a scope: when the client supports MCP elicitation the server asks the user full/custom inline; when it does not, the call hard-stops with 0 credits and returns a message telling the caller to ask the user and re-call with an explicit ``field_mode``. Passing ``fields`` (names, or ``["*"]`` for the full record) is itself an explicit choice and skips the prompt. Cost-smart scope+delivery: a fetch bills the same per record for ANY scope, so re-fetching later just to add a field pays again. Prefer the FULL record when you might need more than a few fields — and choose delivery by what the client can do with files: if it can read local files, ``field_mode='full'`` + ``delivery='url'`` captures every field in one paid fetch without flooding the chat; if it cannot, use ``field_mode='custom'`` with only the fields you need, kept inline. (To decide WHICH custom fields matter, read the dynamic evidence rows from entity_search, then resolve names via entity_fields.) All records are collected via a single paced /collect fan-out. A small id/identity floor is always present; custom ``fields`` add to it. The type-appropriate id is always present. Not-found / stale ids are skipped (not billed) — diff returned ids vs requested to find misses. ``field_mode`` is a token lever, not a cost lever (cost is driven by id count). Args: entity_type: 'employee' | 'company' | 'job'. ids: 1..20 cosi ids (XOR cache_id). cache_id: handle from entity_search (XOR ids). limit: cache_id path record cap, 1..1000 (default 20). field_mode: 'ask' (default) | 'full' | 'custom'. fields: field names for field_mode='custom' (added to the id/identity floor), or ["*"] as a shortcut for the full record. delivery: 'inline' | 'url'. Returns: str: JSON. inline -> {delivery:"inline", entity_type, count, fields, records, credits_consumed}. url -> {delivery:"url", url, count, fields, reason, credits_consumed} (no sample — the records are in the file). On the cache_id path both shapes also carry ``total_count`` (how many the query matched upstream) and ``truncated`` (true when this call returned fewer than matched), plus ``next_cache_id`` when more chunks remain — pass it back as ``cache_id`` to collect the next one. Its absence means this was the last chunk. Errors -> "Error: <message>".
email_enrichEnrich employee member_ids to business contact emails (10 credits/email found). Synchronous batch (server fans out ~25 req/s internally). Billed per email FOUND; ids with no email (NOT_FOUND) or EEA/UK ids (NOT_ACCESSIBLE, GDPR) are free and omitted — diff returned member_ids vs sent to find misses. The whole batch always runs to completion: a per-id miss never aborts it (only account-level failures like a bad key or zero credits stop early). Verified vs in-data emails: every employee record already carries a ``primary_professional_email`` field (fetch it via entity_fetch) — that one is usually UNVERIFIED. This tool is the reliable path: it verifies the email is correct and deliverable. If you just need a cheap best-guess and can tolerate unverified addresses, read ``primary_professional_email`` from the record instead (no extra credits) and skip this call. Args: member_ids: employee cosi ids (<=1000). delivery: 'inline' | 'url'. Returns: str: JSON. inline -> {delivery:"inline", requested, count, results: [{member_id, email, email_status, email_confidence}], credits_consumed}. url -> {delivery:"url", url, count, total_count, truncated, fields, reason, credits_consumed} (no sample — the rows are in the file), where total_count is the ids SENT and count the emails FOUND. Errors -> "Error: <message>".
Coresignal: подключить к Claude, ChatGPT, Cursor · Connectors.fun