Fittest
REMOTE · FITTEST-MCP.WESTUS2.CLOUDAPP.AZURE.COM
Three ML interatomic potentials check a molecule: trust (Beta-posterior score, 90% CI) or DFT.
Available components
Last scanned (1 hour ago)
Scores higher than 40% of remote servers
Unreachable for 3 days in a row. Last reached 2 Nov 2026.
Category AI and Machine Learning
Degraded
One or more channels of this server are currently unreachable; their trust score is decaying and will reach 0 if they stay down.
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 Security11
- TLS not yet verified: we couldn't open a connection to check the certificate. View diagnostics → Unverified
- Authorisation not yet verified: we couldn't confirm whether this endpoint requires it. View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS not yet verified: we couldn't read the response headers to check for it. View diagnostics → Unverified
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability0
- Transport check failed: declared streamable-http, but we couldn't connect to verify it. See how to fix → View diagnostics → Fail
Schema Quality & AI Usability0
- Schema not yet verified: we couldn't read the endpoint's schema, or could read only part of its tool list.Unverified
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage0
- Tool coverage not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Tool Safety0
- Tool safety not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Capabilities0
- Capabilities not yet verified: we couldn't read the endpoint's capabilities.Unverified
Unverified: 5 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.
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.
- 5 Nov 26 −12
The score moved with no change recorded against any check. We would rather say so than guess.
- 3 Nov 26 0
- Endpoint reachability: reachable → unreachable ▼ security
- HSTS header: fail → unverified ▼ security
- Stability: 0.07 → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- TLS certificate: pass → unverified ▼ security
- Transport: pass → fail ▼ security
- Authorization: Authorisation not yet verified: we couldn't confirm whether this endpoint requires it. security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
- 2 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.
- 1 Nov 26 0
- Stability: unverified → 0.03 ▲ functional
- 31 Oct 26 57
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://fittest-mcp.westus2.cloudapp.azure.com/mcp
TLS unreached
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of fittest-mcp.westus2.cloudapp.azure.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| azure.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Inconclusive
We could not reach the endpoint well enough to judge its authorisation posture.
| Result | Inconclusive |
|---|
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://fittest-mcp.westus2.cloudapp.azure.com/mcp | Unreachable | ||
| http (plaintext) | http://fittest-mcp.westus2.cloudapp.azure.com/mcp | HTTPS enforced |
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 →
check_structures ~543
Ask the Fittest swarm whether a machine-learned interatomic potential can be trusted on your molecular structures, or whether they need DFT. Three model agents (MACE-MPA-0, AIMNet2, Orb-v3) predict forces; their disagreement sigma_F and the Calibrator's DFT-label ledger give the verdict. Input `structures`: XYZ text (single or multi-frame; bare 'El x y z' atoms on separate lines or separated by commas/semicolons also work) and/or a list of objects {"Z": [8,1,1] or "symbols": ["O","H","H"], "R": [[x,y,z], ...]} in Angstrom. Exact element symbols only. Limits: <= 20 structures per call, 2..100 atoms each, isolated molecules (no periodic cells). Elements the full committee supports: H B C N O F Si P S Cl As Se Br I. Returns per structure: verdict (trust / send_to_dft) with verdict_reasons, trust_score (Beta posterior P(correct), never exactly 1) with its 90% interval and labels_behind_score, the recommended model or blend, served and reference energy (eV; compare reference_energy_eV across a batch), max/mean force (eV/A), sigma_F vs tau, per-model summary, domain_warning outside C/H/N/O or Transition1x sizes. A bad structure gets its own error entry; the rest are still scored. Rule: trust only if: every model agent supports all elements, the forces do not all vanish, sigma_F < tau, and trust_score >= 0.5. Otherwise send_to_dft, with verdict_reasons. tau is a fixed escalation threshold: the 70th percentile of sigma_F on the round-0 pool. The Calibrator's threshold rule never moved it during the run (see results/RESULTS.md). Logging: every call to this server is logged (UTC time, tool name, an anonymous client id = salted hash of client name + IP), structure and atom counts, verdict counts, latency and ok/error category. Raw IPs are not stored by the app or written to the access log; since 2026-10-31 19:11 UTC Caddy's error/unmapped-host logs drop them too (before that, some Caddy error and bare-IP entries in the system journal contained client IPs, kept until journa…
| Name | Type | Req | Description |
|---|---|---|---|
| include_forces | boolean | – | – |
| structures | – | yes | – |
No output schema declared.
No examples provided.
explain ~205
Explain why Fittest trusted or escalated ONE structure (XYZ text or {Z|symbols, R}): the verdict rule applied, sigma_F vs tau, the Calibrator bucket with its label count, the posterior P(correct) of every candidate in it, which model agents disagree most, and the most uncertain atoms. Logging: every call to this server is logged (UTC time, tool name, an anonymous client id = salted hash of client name + IP), structure and atom counts, verdict counts, latency and ok/error category. Raw IPs are not stored by the app or written to the access log; since 2026-10-31 19:11 UTC Caddy's error/unmapped-host logs drop them too (before that, some Caddy error and bare-IP entries in the system journal contained client IPs, kept until journal rotation). Structures, coordinates, element lists and names are NOT stored. Aggregate counts are public at /stats.
| Name | Type | Req | Description |
|---|---|---|---|
| structure | – | yes | – |
No output schema declared.
No examples provided.
swarm_status ~186
Show the Fittest population: model agents (answerers) and the Skeptic (critic) with reputations from the ledger, the calibration domain, tau and the verdict rule, which models are live, and the evolution family trees if published. Logging: every call to this server is logged (UTC time, tool name, an anonymous client id = salted hash of client name + IP), structure and atom counts, verdict counts, latency and ok/error category. Raw IPs are not stored by the app or written to the access log; since 2026-10-31 19:11 UTC Caddy's error/unmapped-host logs drop them too (before that, some Caddy error and bare-IP entries in the system journal contained client IPs, kept until journal rotation). Structures, coordinates, element lists and names are NOT stored. Aggregate counts are public at /stats.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
usage_stats ~179
Aggregate usage of this server: distinct users (anonymous clients that got at least one structure verdict; internal test clients excluded), total calls, calls per tool, first/last call time. No per-user data. Logging: every call to this server is logged (UTC time, tool name, an anonymous client id = salted hash of client name + IP), structure and atom counts, verdict counts, latency and ok/error category. Raw IPs are not stored by the app or written to the access log; since 2026-10-31 19:11 UTC Caddy's error/unmapped-host logs drop them too (before that, some Caddy error and bare-IP entries in the system journal contained client IPs, kept until journal rotation). Structures, coordinates, element lists and names are NOT stored. Aggregate counts are public at /stats.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
How do I install the Fittest MCP server?
Fittest is a hosted endpoint at https://fittest-mcp.westus2.cloudapp.azure.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 · fittest-mcp.westus2.cloudapp.azure.com
claude mcp add --transport http pavel-tk-fittest 'https://fittest-mcp.westus2.cloudapp.azure.com/mcp'
What is the Fittest MCP server?
Fittest is an MCP server listed in the public MCP registry as io.github.Pavel-Tk/fittest. Three ML interatomic potentials check a molecule: trust (Beta-posterior score, 90% CI) or DFT. This page covers its hosted endpoint (https://fittest-mcp.westus2.cloudapp.azure.com/mcp).
Is the Fittest MCP server safe to use?
Fittest scores 46 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 Fittest MCP server expose?
Fittest exposes 4 tools: check_structures, explain, swarm_status, usage_stats. Their descriptions and schemas cost roughly 1,113 tokens of context every time the server is loaded.
Does the Fittest MCP server require authentication?
Its publisher declares no required credentials for Fittest. We have not been able to confirm that against the live endpoint, and a server can require authorisation without declaring it here.
Is the Fittest MCP server still maintained?
Fittest is still listed in the MCP registry, but we have not been able to reach this channel for several days and its score is decaying. We last reached this channel on 2 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.