Aidenix MCP
REMOTE · MCP.AIDENIX.COM
B2B people and company data: search, your own list, team tools, email checks, lead fit and drafts.
Available components
Last scanned (11 hours ago)
Scores higher than 19% of remote servers
Reachable. Last reached 5 Nov 2026.
Category CRM and Sales
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. How we score → Why this is hard to score →
Endpoint Security89
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- The endpoint enforces authorisation, advertised via RFC 9728 protected-resource metadata. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability0
- Transport blocked by authentication: the endpoint requires auth we don't have to verify streamable-http. See how to fix → View diagnostics → Unverified
Schema Quality & AI Usability0
- Schema blocked by authentication: the endpoint requires auth we don't have to read it. See how to fix → Unverified
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage0
- Tool coverage blocked by authentication: the endpoint requires auth we don't have to read its tools.Unverified
Tool Safety0
- Tool safety blocked by authentication: the endpoint requires auth we don't have to read its tools.Unverified
Capabilities0
- Capabilities blocked by authentication: the endpoint requires auth we don't have to read them. See how to fix → Unverified
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. Claim this server and supply a read-only token to verify it and lift the score.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Nov 26 −24
- Endpoint reachability: reachable → behind authorisation ▼ security
- Tool safety: pass → unverified ▼ security
- Transport: pass → unverified ▼ security
- Authorization: fail → pass ▲ security
- First check of Authorization: partial security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Stability: unverified → 0.03 ▲ functional
- First check of Schema quality: unverified functional
- 3 Nov 26 60
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://mcp.aidenix.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=aidenix.com | CN=WE1,O=Google Trust Services,C=US | 1 Nov 2026 | 30 Jan 2027 | ECDSA 256 | ECDSA-SHA256 | c68116636ba2ba0c0edd0edd2b109712 |
| SANs: aidenix.com, *.aidenix.com | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.aidenix.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| aidenix.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On connection |
| HTTP status | 401 |
WWW-Authenticate challenge Bearer error="invalid_token", error_description="Authentication required", resource_metadata="https://mcp.aidenix.com/.well-known/oauth-protected-resource/mcp"
Bearer error="invalid_token", error_description="Authentication required", resource_metadata="https://mcp.aidenix.com/.well-known/oauth-protected-resource/mcp" | Header | Value |
|---|---|
| www-authenticate | Bearer error="invalid_token", error_description="Authentication required", resource_metadata="https://mcp.aidenix.com/.well-known/oauth-protected-resource/mcp" |
Protected resource metadata
| Document | https://mcp.aidenix.com/.well-known/oauth-protected-resource/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://mcp.aidenix.com/mcp |
| Authorisation server | https://mcp.aidenix.com/ |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.aidenix.com/mcp | Auth required | 401 | |
| http (plaintext) | http://mcp.aidenix.com/mcp | HTTPS enforced | 301 | https://mcp.aidenix.com/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add_opt_out ~180
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.
| Name | Type | Req | Description |
|---|---|---|---|
| contact | string | yes | Email, phone or LinkedIn profile of the person to record in the opt-out list. The kind is detected from the value itself. |
No output schema declared.
No examples provided.
analyze_contact ~59
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.
| Name | Type | Req | Description |
|---|---|---|---|
| contact | string | yes | – |
| icp_profile_id | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | – | – | – |
No examples provided.
analyze_contacts ~42
Submit up to 500 contacts for a named batch business-fit analysis.
| Name | Type | Req | Description |
|---|---|---|---|
| contacts | array | yes | – |
| icp_profile_id | – | – | – |
| name | – | – | – |
No output schema declared.
No examples provided.
build_icp_profile ~178
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.
| Name | Type | Req | Description |
|---|---|---|---|
| website | string | yes | 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. |
No output schema declared.
No examples provided.
company_people ~499
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.
| Name | Type | Req | Description |
|---|---|---|---|
| company | string | yes | 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. |
No output schema declared.
No examples provided.
company_search ~396
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | – | – | next_cursor from the previous page, to continue the same search. |
| filters | object | yes | 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. |
No output schema declared.
No examples provided.
company_signals ~513
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.
| Name | Type | Req | Description |
|---|---|---|---|
| company | string | yes | 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… |
No output schema declared.
No examples provided.
email_intel ~232
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.
| Name | Type | Req | Description |
|---|---|---|---|
| deliverability | boolean | – | Add the SMTP layer (does the mailbox accept mail). Slow. Blind on catch-all domains, where the person layer decides instead. |
| string | yes | 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. |
No output schema declared.
No examples provided.
email_intel_bulk ~273
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.
| Name | Type | Req | Description |
|---|---|---|---|
| deliverability | boolean | – | Add the SMTP layer to every address. Much slower — the list is capped at 10 when this is on. |
| emails | array | yes | 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. |
No output schema declared.
No examples provided.
export_batch ~38
Create a short-lived CSV or JSON export link for a completed batch.
| Name | Type | Req | Description |
|---|---|---|---|
| file_format | string | yes | – |
| job_id | string | yes | – |
No output schema declared.
No examples provided.
get_account_context ~34
Return the authenticated Aidenix account plan, quota, and selected ICP, using the profile website as its human-readable label.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_analysis ~48
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.
| Name | Type | Req | Description |
|---|---|---|---|
| job_id | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | – | – | – |
No examples provided.
get_batch ~48
Get readable batch progress and optionally one page of results.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | – | – | – |
| include_results | boolean | – | – |
| job_id | string | yes | – |
| result_limit | integer | – | – |
No output schema declared.
No examples provided.
list_batches ~36
List batch analyses by name with readable status and progress.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | – | – | – |
| limit | integer | – | – |
| status | – | – | – |
No output schema declared.
No examples provided.
list_icp_profiles ~25
List ICP profiles by website and product description, including which website is selected.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
person_search ~590
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | – | – | next_cursor from the previous page, to continue the same search. |
| filters | object | yes | 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. |
No output schema declared.
No examples provided.
person_signals ~448
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.
| Name | Type | Req | Description |
|---|---|---|---|
| person | string | yes | 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);… |
No output schema declared.
No examples provided.
remove_opt_out ~115
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.
| Name | Type | Req | Description |
|---|---|---|---|
| contact | string | yes | Email, phone or LinkedIn profile to take off this account's opt-out list. Only a record this account created can be lifted. |
No output schema declared.
No examples provided.
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.
remote · mcp.aidenix.com
claude mcp add --transport http com-aidenix-aidenix 'https://mcp.aidenix.com/mcp'
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.