Three ML interatomic potentials check a molecule: trust (Beta-posterior score, 90% CI) or DFT.
Scored across 4 tools
Each tool has a clearly distinct role: batch structure checking, single-structure explanation, swarm/model status, and aggregate usage statistics. Although check_structures and explain both accept structures, their purposes (scoring vs. debugging one verdict) are clearly separated in the descriptions.
All names use snake_case and are readable, but the conventions are mixed: check_structures is verb_noun, explain is a bare verb, and swarm_status/usage_stats are noun phrases. The pattern is not fully predictable, though it is not chaotic.
Four tools is well-scoped for this domain: one main scoring tool, one explanation tool, one status tool, and one usage-stats tool. Each tool has a clear place and there is no redundant bloat.
The core workflow is covered: submit structures, get trust/DFT verdicts, explain a single verdict, and inspect model/calibration status. Minor gaps exist, such as no dedicated historical verdict lookup or batch explanation, but agents can work around these with the available tools.
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 journal rotation). Structures, coordinates, element lists and names are NOT stored. Aggregate counts are public at /stats.
| Name | Required | Description | Default |
|---|---|---|---|
| structures | Yes | ||
| include_forces | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does so well: it discloses the three model agents, the decision rule (all elements supported, non-vanishing forces, sigma_F < tau, trust_score >= 0.5), how tau is defined, that trust_score is a Beta posterior that is never exactly 1, per-structure error isolation, and full logging/privacy behavior including what is and is not stored.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the verdict rule are well front-loaded, but the logging paragraph is very long and contains forensic detail (Caddy error/unmapped-host log history, journal rotation dates) that does not change whether or how the agent calls the tool. The parenthetical reference to results/RESULTS.md is also not actionable at call time, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with no output schema, and the description fully describes the return surface: verdict, verdict_reasons, trust_score with interval and labels_behind_score, recommended model/blend, energies, force statistics, sigma_F vs tau, domain_warning, and per-structure error entries. Nothing essential for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate — and it does heavily for `structures`, spelling out accepted XYZ text forms, separators, the {"Z"/"symbols", "R"} object shape, Angstrom units, and per-call limits. The second parameter `include_forces` is never mentioned, and it is unclear whether it toggles per-atom force output versus the max/mean force already returned in the summary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+decision: ask the Fittest swarm whether an ML interatomic potential can be trusted for given structures or whether DFT is needed. That is concrete and clearly distinct from the siblings (explain, swarm_status, usage_stats), even though no sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit applicability constraints — isolated molecules only, no periodic cells, exact element symbols, <=20 structures, 2..100 atoms, enumerated supported elements — which tells the agent when not to call it. It does not, however, route the agent to any sibling for adjacent needs (e.g. explanation of a verdict, service health), leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| structure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the explanation components, describes logging behavior, privacy practices, and data retention. It does not explicitly state read-only side effects, auth needs, rate limits, or error behavior, preventing a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, but the first sentence is a dense enumeration and the logging paragraph is long. The logging/privacy details are relevant transparency, but the overall definition is wordier than necessary for invocation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema and no annotations, the description covers the main explanation outputs and logging/privacy context. It still lacks exact return format and error behavior, but it is substantially complete enough to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives examples of accepted structure representations ('XYZ text or {Z|symbols, R}'), which helps, but does not clarify the schema's anyOf alternatives (string, array, or object) or required format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Explain why Fittest trusted or escalated ONE structure,' and enumerates the explanation contents. It is clear what the tool does, though the sibling differentiation from check_structures is only implied by 'ONE structure' rather than explicitly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this to explain a single structure, versus likely batch checking in check_structures. However, there is no explicit when-to-use/when-not-to-use guidance or named alternatives, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden: "Show" implies a read-only operation and "if published" discloses that family trees are conditionally absent. It does not state permissions, rate limits, or output size, and much of the second paragraph concerns server-wide logging rather than this tool's behavior, though it does usefully reveal that structures and coordinates are not retained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is dense but front-loaded and informative. The logging paragraph is roughly half the text and is filled with details irrelevant to selecting or invoking this tool (Caddy log history, journal rotation, the 2026-10-31 cutoff), diluting the signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does a decent job describing the return payload: reputations, calibration domain, tau, verdict rule, live-model list, optional family trees. It stops short of describing shape or ordering, but an agent knows what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The schema is an empty object and the description invents no arguments, which is consistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete read operation ("Show the Fittest population") and enumerates its contents: answerer/critic reputations from the ledger, calibration domain, tau, verdict rule, live models, and evolution family trees. An agent can tell it is a status/inspection call, though it never distinguishes itself from usage_stats or explain and leans on domain jargon an outsider may not parse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus the siblings (check_structures, explain, usage_stats), nor any precondition or exclusion. The agent must infer from the name alone that this is the top-level status call and usage_stats is the aggregate one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses what data is excluded (internal test clients), that no per-user data is returned, what is logged on every call (time, tool name, salted-hash client id, latency, error category), what is never stored (structures, coordinates, element lists, names), and even the exact date and retention semantics for IP data. This is far beyond what an agent could infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The return-value summary is front-loaded in the first sentence, and the logging/privacy paragraph follows logically. That second paragraph is long and reads partly like a compliance disclosure, but nearly every clause carries information an agent would not otherwise have; only marginal trimming is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must describe return values itself, and it does — naming each aggregate plus the absence of per-user data. Combined with the privacy/logging disclosure, an agent has everything needed to call it and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. It correctly does not waste space describing non-existent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Aggregate usage of this server') and then enumerates exactly which aggregates are returned: distinct users, total calls, calls per tool, first/last call time. This is unambiguous and cannot be confused with the sibling tools check_structures, explain, or swarm_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use (fetch aggregate usage statistics) is implied clearly by the description, but there is no explicit statement of when to call this versus the siblings, and no conditions or exclusions for invocation. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_structuresexplainswarm_statususage_statsHuman hepatic clearance from in-vitro CLint, with the error band measured on known drugs.
Protein analysis: ESM-2/ESMC embeddings, mutation scoring, landscape scans, ESMFold structure.
Calibrated probabilities for Kalshi markets, a news wire and Polymarket outliers (Pro).
FTIR spectral search and material identification for AI agents via MCP.
Add one secure layer between your agents and this server.
