# Aidenix MCP (remote · mcp.aidenix.com)

B2B people and company data: search, your own list, team tools, email checks, lead fit and drafts.

- Trust score: 36/100 (low)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `mcp.aidenix.com`: 36/100 (this document), [markdown](https://verifymcp.io/servers/com-aidenix-aidenix/mcp.md), [page](https://verifymcp.io/servers/com-aidenix-aidenix/mcp)

## Channel facts

- Endpoint: `https://mcp.aidenix.com/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `1.0.1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 89/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - The endpoint enforces authorisation, advertised via RFC 9728 protected-resource metadata.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 0/100
  - Transport blocked by authentication: the endpoint requires auth we don't have to verify streamable-http.
- **Schema Quality & AI Usability**: 0/100
  - Schema blocked by authentication: the endpoint requires auth we don't have to read it.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 0/100
  - Tool coverage blocked by authentication: the endpoint requires auth we don't have to read its tools.
- **Tool Safety**: 0/100
  - Tool safety blocked by authentication: the endpoint requires auth we don't have to read its tools.
- **Capabilities**: 0/100
  - Capabilities blocked by authentication: the endpoint requires auth we don't have to read them.

**Unverified: 6 categories.** Categories scored 0 because we could not verify them: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.

## Install

### How do I install the Aidenix MCP server?

Aidenix MCP is a hosted endpoint at https://mcp.aidenix.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http com-aidenix-aidenix 'https://mcp.aidenix.com/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "com-aidenix-aidenix": {
      "url": "https://mcp.aidenix.com/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-aidenix-aidenix": {
      "type": "http",
      "url": "https://mcp.aidenix.com/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.com-aidenix-aidenix]
url = "https://mcp.aidenix.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-aidenix-aidenix": {
      "type": "remote",
      "url": "https://mcp.aidenix.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-aidenix-aidenix --url 'https://mcp.aidenix.com/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-aidenix-aidenix:
    url: "https://mcp.aidenix.com/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "com-aidenix-aidenix": {
      "Transport": "http",
      "Url": "https://mcp.aidenix.com/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-aidenix-aidenix -t streamable-http -u 'https://mcp.aidenix.com/mcp'
```

### Other

```json
{
  "mcpServers": {
    "com-aidenix-aidenix": {
      "type": "http",
      "url": "https://mcp.aidenix.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-04 (score 36, −24)

- [security regression] Endpoint reachability: reachable → behind authorisation
- [security regression] Tool safety: pass → unverified
- [security regression] Transport: pass → unverified
- [security improvement] Authorization: fail → pass
- [security] First check of Authorization: partial
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional improvement] Stability: unverified → 0.03
- [functional] First check of Schema quality: unverified

### 2026-11-03 (score 60)

First indexed and scored.

## MCP tools (18)

### `get_account_context` (~34 tokens)

Return the authenticated Aidenix account plan, quota, and selected ICP, using the profile website as its human-readable label.

### `list_icp_profiles` (~25 tokens)

List ICP profiles by website and product description, including which website is selected.

### `analyze_contact` (~59 tokens)

Return a complete user-facing single-contact business-fit analysis and outreach drafts. When presenting a completed result, hide technical metadata and use human-readable headings while preserving every user-facing content field.

Input parameters:

- `contact` (string, required)
- `icp_profile_id`

Output parameters:

- `code`
- `email_message`
- `email_subject`
- `fit_score_pct`
- `job_id`
- `linkedin_message`
- `logic_explanation`
- `message`
- `person_description`
- `request_id`
- `retry_after_seconds`
- `retryable`
- `status`
- `strategy`
- `strategy_do`
- `strategy_dont`

### `get_analysis` (~48 tokens)

Poll one business-fit analysis job and return the complete user-facing result when finished; hide technical metadata and use human-readable headings while preserving every user-facing content field.

Input parameters:

- `job_id` (string, required)

Output parameters:

- `code`
- `email_message`
- `email_subject`
- `fit_score_pct`
- `job_id`
- `linkedin_message`
- `logic_explanation`
- `message`
- `person_description`
- `request_id`
- `retry_after_seconds`
- `retryable`
- `status`
- `strategy`
- `strategy_do`
- `strategy_dont`

### `analyze_contacts` (~42 tokens)

Submit up to 500 contacts for a named batch business-fit analysis.

Input parameters:

- `contacts` (array, required)
- `icp_profile_id`
- `name`

### `list_batches` (~36 tokens)

List batch analyses by name with readable status and progress.

Input parameters:

- `cursor`
- `limit` (integer)
- `status`

### `get_batch` (~48 tokens)

Get readable batch progress and optionally one page of results.

Input parameters:

- `cursor`
- `include_results` (boolean)
- `job_id` (string, required)
- `result_limit` (integer)

### `export_batch` (~38 tokens)

Create a short-lived CSV or JSON export link for a completed batch.

Input parameters:

- `file_format` (string, required)
- `job_id` (string, required)

### `email_intel` (~232 tokens)

Decide whether an email address is worth contacting, before drafting anything. Answers two independent questions: does the mailbox accept mail, and is the person still there. Catches what email verifiers miss — someone who left the company, a renamed domain, a historic address — because a live mailbox at a stale address still bounces the deal, not the message. Costs one request of the user's quota, the same as an analysis: run it before analyze_contact when the address might be dead — personalizing for someone who left wastes the analysis — and skip it on a contact you already trust, where it only adds a second request. Present the recommended action and the reason; keep raw verdicts and scores for your own workflow.

Input parameters:

- `deliverability` (boolean): Add the SMTP layer (does the mailbox accept mail). Slow. Blind on catch-all domains, where the person layer decides instead.
- `email` (string, required): Email address to assess before contacting it.
- `enrich` (boolean): Add the dossier: address age, breach exposure, domain reputation, digital footprint, and a company card for the domain. Slow.

### `email_intel_bulk` (~273 tokens)

Assess a whole list of addresses in one call, before spending analysis on any of them. Same two questions as email_intel — does the mailbox accept mail, is the person still there — answered per address, and returned as a split by recommended action so you can drop the dead ones and keep the rest. Up to 50 addresses per call, or 10 when deliverability or enrich is on, because those layers are slow; split a longer list yourself. Costs one request of the user's quota per address, so it pays for itself on the addresses it lets you drop rather than analyse — worth it on a cold list, not on a handful of contacts you already trust. If the remaining quota covers only part of the list, the rest is reported as skipped, not assessed; say so instead of presenting a short answer as a complete one. Present the counts and name the addresses not to send to; keep the per-address blocks for your workflow.

Input parameters:

- `deliverability` (boolean): Add the SMTP layer to every address. Much slower — the list is capped at 10 when this is on.
- `emails` (array, required): Email addresses to assess in one call.
- `enrich` (boolean): Add the dossier to every address. Much slower — the list is capped at 10 when this is on.

### `build_icp_profile` (~178 tokens)

Build the seller's ICP profile by reading their own website: what they sell, the value proposition, which roles and industries they sell to, the pain points, proof points and tone of voice. The new profile becomes the active one, so every later score and every generated email is weighted by it — confirm with the user before running it on a website they have not named. Use it to onboard a new account or after a repositioning; use list_icp_profiles to see what is already there. The URL is the seller's own site, never the prospect's. A recent profile for the same site is not rebuilt — the upstream reports it already exists.

Input parameters:

- `website` (string, required): Website of the company you sell FOR — your own product site, not the prospect's. Its copy becomes the ICP every later score is weighted by.

### `company_signals` (~513 tokens)

Profile a company and its current moment before working its people. Given a domain or name, returns firmographics + revenue, team makeup, hiring velocity from careers (which catches layoffs a static card misses), activity signals (funding, hiring focus, product, partnerships, attrition), geo footprint, a growth / reorg / stealth / stable verdict with outreach timing, and a teaser of which organizations the team reads. Set relationships=true to expand that teaser into the full attention map — the orgs they follow (competitors / vendors / media), top public accounts influencing the buyer (warm-intro paths), and internal amplifiers by role. team.tools lists what the team uses inside (Snowflake, Kafka, Salesforce…) from current employees' skills, with how many people use each; add enrich=true for an LLM read of the opinion-leaders, what the pattern means, and org categorization (~20s, hot accounts only). Employee names are never exposed. Costs one request of the user's quota per call — priced per account, not per person, so one call carries every lead from that company; do not repeat it per contact. Call once per account for research and timing; then analyze_contact for the individuals. Present the verdict and timing; keep the raw blocks for your workflow.

Input parameters:

- `company` (string, required): Company domain (e.g. 'stripe.com') or name. Returns an account-level signal profile: firmographics + revenue, team makeup, hiring velocity from careers (catches layoffs), activity signals (funding/hi…
- `enrich` (boolean): Only meaningful together with relationships. Adds an LLM judgment layer over the map: the real opinion-leaders influencing the buyer, what the attention pattern reveals about priorities, concrete war…
- `relationships` (boolean): When true, expands the attention teaser into the full map of who the team collectively follows from public employee activity (likes/comments/shares): organizations they follow most (competitors / ven…

### `company_people` (~499 tokens)

Admin-only: the upstream refuses this tool for customer accounts, so do not offer it as an option — company_signals covers the account and analyze_contact covers the person. Get the people of a company and the addresses to reach them. Given a domain, LinkedIn slug or name, returns the team by name — role, grade, seniority, country, LinkedIn — and the work addresses the sources actually hold, ranked by who decides and who is reachable. Every address carries what it is worth: on the company domain, a shared company inbox (info@ / support@), a short address two namesakes share, one a source flagged as a previous job, or a private mailbox — often the only way to reach the founder of a small company. Addresses are never invented from a name@domain template and are not SMTP-probed — these domains are mostly catch-all, so a probe would prove nothing; use email_intel when one specific address has to be trusted. Phone numbers are not returned, and people who opted out are excluded entirely. This is the roster layer: company_signals profiles the ACCOUNT, person_signals explains ONE human, analyze_contact scores the deal and drafts the outreach. Use roles=founder,ceo to keep only the people who answer cold email. Present who to write to and what their address is worth; keep the raw rows for your workflow.

Input parameters:

- `company` (string, required): Company domain (e.g. 'lemlist.com'), LinkedIn company URL/slug, or name. Returns the team by name with every address the sources actually hold — work, shared inbox and private — each labelled with wh…
- `contacts` (boolean): Set to false to skip the contact directories — faster, when you mostly need who works there and in what roles. Addresses carried by the profile snapshots themselves still come back.
- `roles`: Comma-separated role filter — the people who answer cold email: founder, ceo, cto, cpo, cxo, product, growth, sales. Omit to get the whole team ranked.
- `top` (integer): How many people to return by name (default 25). The metrics always describe the whole team behind those rows, so a small top is not a small answer.

### `company_search` (~396 tokens)

Find companies that fit — by industry, size, country, revenue, website tech, the tools their team uses inside, hiring, funding and what they are researching now — without people. Returns one row per company: name, domain, LinkedIn page, industry, size, country, revenue range, funding, website tech stack, intent topics, the company's own public emails, and why it matched. team_uses sees internal tools a website scan never does (Snowflake, dbt, Kafka, Gong), counted from current employees' skills, with how many people use each; the tool's own maker is left out. researching is buyer intent: topics the company's people read about lately. Each company returned costs one request of the user's quota; start with a small limit, then page with next_cursor. This is the first step of account-based work: pick the accounts here, then person_search with the same filters or with domains finds the people, and company_signals profiles one account in depth. Present the total and the companies with the reason they matched.

Input parameters:

- `cursor`: next_cursor from the previous page, to continue the same search.
- `filters` (object, required): Filters, combined with AND; values inside one list combine with OR. At least one is required. industries ['Software Development'], company_size_min / company_size_max (employees), company_countries […
- `limit` (integer): Companies per page, 1-100. Each company returned costs one request.

### `person_search` (~590 tokens)

Find people who fit — by role, company and timing — with their contacts. Returns one row per person: name, title, seniority, department, company and its website, LinkedIn, location, the work email at the CURRENT employer, all known work emails, personal emails and phones from professional sources, months in role against their usual tenure, and why they matched. Beyond title and firmographics it filters on timing: started the role in the last N days, alumni of a company who left, in the seat longer than usual, engaged with a company's LinkedIn posts, talks about a topic, writes code in a language, company website runs a technology, fresh funding. Opted-out people are excluded. Each person returned costs one request of the user's quota; an empty page costs nothing — start with a small limit to see the total, then page with next_cursor. This is the way IN from an account or a segment: company_people lists one company's team (admin only), person_signals explains one human, email_intel checks an address you already hold. Emails here are not SMTP-checked — run them through email_intel_bulk before a send. Present the total, then the people with the reason they matched; keep cursors and raw fields for your workflow.

Input parameters:

- `cursor`: next_cursor from the previous page, to continue the same search.
- `filters` (object, required): Filters, combined with AND; values inside one list combine with OR. At least one is required. Who: titles ['vp sales'], levels ['c-level','vp','director','head','manager'], departments ['Sales','Mark…
- `limit` (integer): People per page, 1-100. Each person returned costs one request.
- `only_with_contacts` (boolean): Skip people without any email or phone.

### `person_signals` (~448 tokens)

Who a person is and what is going on with them. Given an email, LinkedIn URL, or slug, returns their role, grade and current company; the career trajectory from dates (months in the seat, whether they grew inside, their usual tenure); what they publish themselves and the subjects they raise; whose content they read; what they said about themselves (looking for work / hiring / milestone); and a verdict with the career moment and how to approach. Works even when the address is dead — the person is resolved to their current employer, which is often the point. Costs one request of the user's quota per contact, the same as an analysis — reach for it when you need the human behind the address, not as a warm-up before analyze_contact. This is the person layer: email_intel answers whether the ADDRESS is usable, analyze_contact scores the DEAL and drafts outreach, this one says who the human is. Asked by email, the answer carries no name and no profile slug — turning a mailbox into an identity is exactly what email_intel refuses to do, and this layer follows the same rule; ask by profile URL or slug and the name comes back, since the caller already holds it. Present the career moment, their own subjects, and the timing; keep raw blocks for your workflow. When match_confidence is low, say why: either the address did not match the profile name, or linked_profiles shows several people behind one address and the most corroborated was taken.

Input parameters:

- `person` (string, required): Email, LinkedIn profile URL or slug. Returns who the person is and what is going on with them: role, grade and company; career trajectory from dates (how long in the seat, whether they grew inside);…

### `add_opt_out` (~180 tokens)

Record a person in this account's opt-out list when they ask not to be contacted. Takes an email, phone or LinkedIn profile and detects which it is. Repeating a contact is safe — the second call reports it was already there instead of adding it twice. The list is enforced: contact analysis refuses an excluded contact, and people lists leave them out. Costs no quota — recording a request not to be written to must work on an exhausted plan — but new records are capped at 10 per account per day, so this is for people who asked, one at a time, not for bulk-marking a list. Use remove_opt_out to lift a record this account made.

Input parameters:

- `contact` (string, required): Email, phone or LinkedIn profile of the person to record in the opt-out list. The kind is detected from the value itself.

### `remove_opt_out` (~115 tokens)

Take a contact off this account's opt-out list — for a record added by mistake, or a person who asked to be contacted again. Only a record this account created can be lifted: the list is shared, so one account must not undo an exclusion another was asked for. Reports whether the record was lifted, was never there, or belongs to another account.

Input parameters:

- `contact` (string, required): Email, phone or LinkedIn profile to take off this account's opt-out list. Only a record this account created can be lifted.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-aidenix-aidenix/mcp#diagnostics

## Score history

- 2026-11-05: 36
- 2026-11-04: 36
- 2026-11-03: 60

## Common questions

### What is the Aidenix MCP server?

Aidenix MCP is listed in the public MCP registry as com.aidenix/aidenix. B2B people and company data: search, your own list, team tools, email checks, lead fit and drafts. This page covers its hosted endpoint (https://mcp.aidenix.com/mcp).

### Is the Aidenix MCP server safe to use?

Aidenix MCP scores 36 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Aidenix MCP server expose?

Aidenix MCP exposes 18 tools: get_account_context, list_icp_profiles, analyze_contact, get_analysis, analyze_contacts, and 13 more. Their descriptions and schemas cost roughly 3,754 tokens of context every time the server is loaded.

### Does the Aidenix MCP server require authentication?

Yes. Aidenix MCP asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the Aidenix MCP server still maintained?

Aidenix MCP is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What did VerifyMCP test on the Aidenix MCP server?

VerifyMCP ran 5 checks on Aidenix MCP, covering TLS certificate, Authorization, HTTPS, HSTS header and 1 more. 6 items could not be completed, a gap on our side rather than a finding about Aidenix MCP: Transport, Schema quality, Stability, Tool coverage and 2 more. 6 categories score 0 for that reason, because we only credit what we can confirm. Supply Chain Security and Provenance & Transparency do not apply to a hosted endpoint, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- Remote endpoint: https://mcp.aidenix.com/mcp
- Website: https://aidenix.com/mcp
- Changelog RSS feed: https://verifymcp.io/servers/com-aidenix-aidenix/mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-aidenix-aidenix/mcp/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/com-aidenix-aidenix/mcp.json
- HTML version of this page: https://verifymcp.io/servers/com-aidenix-aidenix/mcp