biotools-mcp provides 11 scientifically verified bioinformatics and statistical tools, backed by BioPython and scipy, designed to prevent AI agents from hallucinating calculations. These tools are exposed via an MCP server (stdio or streamable HTTP) for programmatic access by AI agents.
Sequence Utilities:
seq_gc_content – Calculate GC content percentage (0–100) from DNA/RNA, excluding ambiguous bases.
seq_reverse_complement – Compute reverse complement with full IUPAC ambiguity support.
seq_translate – Translate nucleotide sequence to protein using any NCBI genetic code table.
seq_orf_finder – Find ORFs in forward strand (frames 0–2) with configurable minimum length.
seq_motif_scan – Scan for IUPAC motifs supporting bracket groups (e.g., ATG[AC]) and overlap control.
seq_stats – Compute length, mononucleotide/dinucleotide composition, and GC skew.
Statistical Tests & Analysis:
stats_describe – Descriptive statistics: n, min, max, mean, median, variance, std dev, skewness, kurtosis.
stats_t_test – Two-sample t-test (Student/Welch) with Cohen's d, one- or two-sided.
stats_chi_square – Chi-square test of independence with optional Yates' correction.
stats_mann_whitney – Mann-Whitney U test with exact/asymptotic p-value.
stats_correlation – Pearson or Spearman correlation between two paired variables.
Data formats: Accepts sequences and numeric arrays; returns structured results suitable for analysis. Use cases include sequence analysis and statistical hypothesis testing in bioinformatics.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@biotools-mcp Calculate the GC content of the sequence ATGGCCATTGTAATGGGCCGCTGAAAGGGTGCCCGATAG"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Verified bioinformatics tools for AI agents — sequence utilities + statistics, backed by BioPython/scipy, exposed as an MCP server, companion Skill, and Python package.
MIT · public · benchmarked.
Research agents hallucinate bioinformatics math. This project builds the missing layer: battle-tested scientific computation wrapped in a clean, agent-native surface.
Sequence utilities — GC content, reverse complement, translation, ORF finding, motif scanning, sequence stats (BioPython-backed; ORF finder + motif-overlap are custom logic, checked against independent references).
Statistics — descriptive stats, t-test, chi-square, Mann–Whitney U, correlation (scipy-backed, reference-vector tested against published/R values).
MCP server — stdio + streamable HTTP, 11 action-oriented tools
(seq_gc_content, stats_t_test, …), pydantic v2 schemas with structured output.
Companion Skill — agentskills.io spec: when to use which tool, input requirements, and what not to do.
Every tool is reference-vector tested against published values (GenBank records, R t.test
output, Mendel's 1866 pea counts, Anscombe's quartet) — never against the wrapper itself.
Related MCP server: protein-design-mcp
Published on PyPI as biotools-mcp (requires Python 3.11+).
# Install as a standalone CLI (MCP server entry point)
uv tool install biotools-mcp
# Or run without installing
uvx biotools-mcp
# Or plain pip
pip install biotools-mcpAs a library:
uv add biotools-mcpfrom biotools_mcp.seq import gc_content
from biotools_mcp.stats import t_test
print(gc_content("ATGGCCATTGTAATGGGCCGCTGAAAGGGTGCCCGATAG").gc_percent) # 56.4103
print(t_test([1, 2, 3], [4, 5, 6]).statistic) # -3.6742Point your agent at the server over stdio:
Claude Code (.mcp.json):
{
"mcpServers": {
"biotools-mcp": {
"command": "uvx",
"args": ["biotools-mcp"]
}
}
}Cursor — Settings → MCP → Add:
{
"mcpServers": {
"biotools-mcp": {
"command": "uvx",
"args": ["biotools-mcp"]
}
}
}Codex / Gemini CLI — same mcpServers block in the agent's MCP config file.
Streamable HTTP (for remote use):
uvx biotools-mcp --transport streamable-httpTool | Description |
| GC content as a percentage (ambiguous bases excluded) |
| Reverse complement (IUPAC-aware, DNA/RNA) |
| Translate to protein (NCBI tables, incl. mitochondrial) |
| Open reading frames, forward strand, frames 0–2 |
| IUPAC motif scanning with bracket groups + overlap policy |
| Length, mono/di composition, GC skew |
| Descriptive statistics (n, mean, median, var, skew, kurtosis) |
| Student/Welch two-sample t-test with Cohen's d |
| Chi-square test of independence (Yates optional) |
| Mann-Whitney U test (exact/asymptotic) |
| Pearson or Spearman correlation |
Wedge subset of BioAgent Bench + BioTaskBench (sequence utilities + statistics) run against the tools and published in benchmarks/results.md. Every task in the subset runs — failures are published alongside passes.
Current: 15/15 passed (100%) — bioagent-bench subset 7/7, bioTaskBench subset 8/8. Pinned harness, see the results file for task-level detail.
uv run python benchmarks/run_bioagent_bench.py # 7/7
uv run python benchmarks/run_biotaskbench.py # 8/8
uv run python benchmarks/harness.py --suite all # combined 15/15The skills/biotools-mcp skill (agentskills.io spec) teaches agents the tool inventory, when to use which tool, input requirements, and what not to do (never compute GC/translation/t-tests by hand). Load it into any skills-compatible agent.
Past problems and the patterns they produced live in
docs/solutions — including the uvx grandchild-process leak in
subprocess tests, mcp SDK v2 tool-registration conventions, and the CI matrix Python-version
trap. Relevant when implementing or debugging in those areas.
uv sync --extra dev
uv run pytest # reference-vector suite (skips slow packaging by default)
uv run python benchmarks/harness.py --suite all # regenerate benchmark results
uvx ruff check src tests benchmarksCI runs lint + tests on Python 3.11/3.12; a nightly workflow regenerates the benchmark table;
a tag-pushed v* triggers the PyPI publish workflow.
See CONTRIBUTING.md — verification is non-circular (reference-vector fixtures from published values), degenerate inputs must fail loudly, and benchmark tasks are never dropped to keep numbers green. Changes are tracked in CHANGELOG.md.
MIT — see LICENSE.
Compute GC content of a nucleotide sequence as a percentage (0-100).
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Nucleotide sequence (DNA or RNA; case-insensitive). IUPAC ambiguity codes (R, Y, S, W, K, M, B, D, H, V, N) are accepted where documented. |
| Name | Required | Description |
|---|---|---|
| length | Yes | Total sequence length. |
| gc_count | Yes | Number of G and C bases counted. |
| sequence | Yes | The input nucleotide sequence (uppercased). |
| gc_percent | Yes | GC content as a percentage (0-100). Ambiguous bases (N, R, Y, ...) are excluded from the calculation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read-only operation. The description adds the output range (0-100) but discloses no other behavioral traits, such as how ambiguous IUPAC codes are counted or error handling. This is adequate but not rich in added context beyond the annotations.
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 description is a single, front-loaded sentence of 12 words. Every word is informative, with no redundancy or filler. It is an excellent example of conciseness.
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?
The tool is simple (one required parameter), has full schema coverage, a rich output schema, and comprehensive annotations. The description adequately covers the core function. It could optionally mention handling of ambiguous codes, but the schema already covers that, so the context is essentially complete. A 5 would require more nuance, e.g., return format or edge-case behavior.
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 100%: the 'sequence' parameter is fully described with type, minLength, and details about case-insensitivity and IUPAC codes. The tool description itself adds no parameter-level information, so the baseline of 3 applies.
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 ('Compute'), a clear resource ('nucleotide sequence'), and the exact output ('percentage (0-100)'). This fully distinguishes it from sibling tools like seq_motif_scan or seq_reverse_complement, leaving no ambiguity about the tool's function.
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 context is clear: use this tool when you need GC content as a percentage. No explicit exclusions or alternatives are mentioned, but the tool's purpose is so specific that usage is evident. However, it does not name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a nucleotide sequence for IUPAC motif occurrences (supports bracket groups).
| Name | Required | Description | Default |
|---|---|---|---|
| motif | Yes | IUPAC motif to search for, optionally with bracket groups (e.g. 'ATG[AC]' matches ATGA and ATGC). Valid: A,C,G,T,U,R,Y,S,W,K,M,B,D,H,V,N. | |
| sequence | Yes | Nucleotide sequence (DNA or RNA; case-insensitive). IUPAC ambiguity codes (R, Y, S, W, K, M, B, D, H, V, N) are accepted where documented. | |
| max_matches | No | Cap on the number of matches reported. When the cap is reached the result's truncated flag is True and the reported matches are a prefix; narrow the motif or set overlapping=False for the full set. | |
| overlapping | No | If True, report overlapping matches (next scan starts at the next base); if False, scan greedily left-to-right. |
| Name | Required | Description |
|---|---|---|
| motif | Yes | The motif searched for (uppercased). |
| matches | Yes | Match positions (empty when the motif is not found). |
| sequence | Yes | The input nucleotide sequence (uppercased). |
| truncated | No | True when the match cap (max_matches) was reached and the reported matches are a prefix of the full result set. Narrow the motif or set overlapping=False to get all matches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds useful behavioral context, notably the support for IUPAC codes and bracket groups, which are not in the annotations. It does not describe edge cases like truncation, but schema parameters cover those, making this a solid 4.
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 description is a single, front-loaded sentence that conveys the core action and a key capability. There is zero wasted prose, and it earns a perfect score for conciseness and structure.
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 a detailed input schema (100% coverage), informative annotations, and an output schema present, the brief description is sufficient. It supplies the high-level purpose while the schema and annotations handle parameter semantics and safety, making the overall tool definition complete.
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 100%, with detailed parameter descriptions for motif, sequence, max_matches, and overlapping. The tool description itself adds no new parameter meaning beyond the schema, so the baseline score of 3 applies.
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 'Scan a nucleotide sequence for IUPAC motif occurrences (supports bracket groups)' uses a specific verb and resource, clearly distinguishing this tool from sequence-statistics or transformation siblings. It also highlights the distinctive bracket-group feature, making the purpose unambiguous.
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 context clearly implies use for finding motif occurrences in nucleotide sequences, and the sibling tool names (e.g., seq_gc_content, seq_reverse_complement) make alternatives obvious. However, the description does not explicitly state when not to use this tool or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find open reading frames (forward strand, frames 0-2) in a nucleotide sequence.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Nucleotide sequence (DNA or RNA; case-insensitive). IUPAC ambiguity codes (R, Y, S, W, K, M, B, D, H, V, N) are accepted where documented. | |
| min_length | No | Minimum ORF length in nucleotides (ORFs shorter than this are filtered out). |
| Name | Required | Description |
|---|---|---|
| orfs | Yes | Open reading frames found (empty when none meet min_length). |
| sequence | Yes | The input nucleotide sequence (uppercased; U is normalized to T). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds the behavioral constraint of scanning only the forward strand and frames 0-2, which is useful context. However, it does not disclose other behaviors such as ORF boundary definitions (start/stop codons) or whether stop codons are included, leaving some gaps beyond what annotations cover.
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 description is a single, concise sentence that front-loads the action ('Find open reading frames') and then adds the relevant constraints. Every phrase adds value, with no redundant or extraneous text. It is well-structured and appropriately sized.
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?
The description, combined with rich annotations and full input schema coverage, provides a solid understanding of the tool's behavior and parameters. The output schema exists, so return values are not required in the description. The only minor gap is the lack of a formal definition of what constitutes an ORF (e.g., start/stop codons), but this is likely implied by the tool's domain and the output schema. Overall, it is reasonably complete for a simple analysis tool.
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 input schema fully documents both parameters with descriptions, examples, and constraints, so schema coverage is 100%. The description itself adds no further parameter-specific detail, thus it does not improve upon what the schema already provides. A baseline score of 3 is appropriate.
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 clearly states the tool's function: finding open reading frames. It specifies the forward strand and frames 0-2, which distinguishes it from sibling tools like seq_translate or seq_motif_scan. The verb 'Find' and resource 'open reading frames' are specific and unambiguous.
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 description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or refer to sibling tools. An agent must infer usage from the purpose alone, which is not sufficient for comparative decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the reverse complement of a nucleotide sequence (DNA or RNA).
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Nucleotide sequence (DNA or RNA; case-insensitive). IUPAC ambiguity codes (R, Y, S, W, K, M, B, D, H, V, N) are accepted where documented. |
| Name | Required | Description |
|---|---|---|
| sequence | Yes | The input nucleotide sequence (uppercased). |
| reverse_complement | Yes | The reverse complement of the input sequence. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that input can be DNA or RNA, which is a useful behavioral constraint beyond the annotations. However, it does not disclose output format or behavior with invalid input, though an output schema exists.
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?
One concise sentence that directly states the operation and input type. No redundant words or filler, making it easy to scan and understand.
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 simple one-parameter tool with rich annotations and an output schema, this description is adequately complete. It doesn't detail return values, but the output schema covers that. The DNA/RNA mention adds useful context, and the tool's simplicity means this level of detail is sufficient.
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 input schema has 100% coverage with a detailed description of the 'sequence' parameter, including case-insensitivity and IUPAC ambiguity codes. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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 clearly states the verb 'compute' and the resource 'reverse complement of a nucleotide sequence', distinguishing it from sibling tools like seq_translate or seq_gc_content. It is specific about DNA/RNA scope, making the purpose unambiguous.
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 description implies usage for any nucleotide sequence needing reverse complementation, but it does not explicitly contrast with alternatives or state when not to use it. The tool name and sibling list provide enough context for an agent to infer differentiation, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute sequence length, mono/dinucleotide composition, and GC skew.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Nucleotide sequence (DNA or RNA; case-insensitive). IUPAC ambiguity codes (R, Y, S, W, K, M, B, D, H, V, N) are accepted where documented. |
| Name | Required | Description |
|---|---|---|
| length | Yes | Sequence length in nucleotides. |
| gc_skew | Yes | GC skew = (G - C) / (G + C); 0.0 when G + C == 0. |
| composition | Yes | Mononucleotide counts keyed by base. |
| dinucleotides | Yes | Overlapping dinucleotide counts keyed by pair. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description only restates the core computational behavior without adding extra context such as input constraints, edge cases, or performance traits. It does not contradict annotations.
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 description is a single, focused sentence that begins with the action verb and lists the outputs. No wasted words; it is appropriately sized for the tool's simplicity.
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?
Given the single parameter, full schema coverage, existing output schema, and annotations, the description is sufficient. It explains what the tool computes, and the output schema likely defines return values, so no further detail is needed.
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 100%, so the schema fully documents the 'sequence' parameter including case-insensitivity and IUPAC ambiguity acceptance. The description does not add any parameter-specific meaning beyond what the schema provides, maintaining baseline score.
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 uses a specific verb 'Compute' and identifies the resources (sequence length, mono/dinucleotide composition, GC skew), clearly distinguishing this from sibling tools like seq_gc_content which likely only computes GC content. It is unambiguous and precise.
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 purpose is clear, but there is no explicit guidance on when to use this tool versus alternatives (e.g., seq_gc_content for GC content alone). Usage is implied but not stated, and no exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a nucleotide sequence to protein using an NCBI genetic code table.
| Name | Required | Description | Default |
|---|---|---|---|
| to_stop | No | If True, stop translation at the first in-frame stop codon (the terminal '*' is omitted); if False, stops translate to '*' (BioPython convention). | |
| sequence | Yes | Nucleotide sequence (DNA or RNA; case-insensitive). IUPAC ambiguity codes (R, Y, S, W, K, M, B, D, H, V, N) are accepted where documented. | |
| table_id | No | NCBI genetic code table id. 1 = Standard; 2 = Vertebrate Mitochondrial (TGA codes for W). |
| Name | Required | Description |
|---|---|---|
| to_stop | Yes | The requested to_stop flag (True = stop translation at the first in-frame stop codon). Reports the input request, not whether a stop codon was actually encountered. |
| sequence | Yes | The input nucleotide sequence (uppercased). |
| table_id | Yes | Genetic code table id used. |
| table_name | Yes | Genetic code table name used. |
| translated | Yes | The translated protein sequence ('*' marks a stop codon). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent behavior. The description adds the fact that translation uses an NCBI genetic code table, but it does not go beyond the schema to describe edge cases like stop-codon handling or ambiguous base codes. No contradiction with annotations.
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 description is a single, well-structured sentence that starts with the action verb. It contains no filler, fluff, or redundant information, making it both concise and informative.
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 simple transformation tool, the description combined with the rich schema and annotations is sufficiently complete. The existence of an output schema removes the need to describe return values. The only minor gap is lack of cross-references to related tools, which is more a usage guideline concern.
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 input schema has 100% description coverage for all three parameters (sequence, to_stop, table_id), so the description does not need to add parameter details. It adds no extra semantic value, aligning with the baseline score for high schema coverage.
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 clearly states the verb 'Translate', the resource 'nucleotide sequence to protein', and the method 'using an NCBI genetic code table'. This distinguishes it from sibling sequence-analysis tools like seq_reverse_complement or seq_gc_content by specifying the exact transformation.
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 description implies this tool is for translation but does not explicitly state when to use it versus alternatives like seq_orf_finder, nor does it mention how to choose between table_id values. Usage context is inferred rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a chi-square test of independence on a contingency table (Yates correction optional).
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | 2-D contingency table of observed counts (list of rows; all rows same length; at least 2 rows and 2 columns; non-negative). | |
| correction | No | If True apply Yates' continuity correction (meaningful for 2x2 tables only). |
| Name | Required | Description |
|---|---|---|
| dof | Yes | Degrees of freedom. |
| method | Yes | Method used: 'Yates continuity correction' (2x2 with correction) or "Pearson's chi-squared". |
| p_value | Yes | p-value. |
| expected | Yes | Expected frequencies under independence. |
| statistic | Yes | The chi-square statistic. |
| correction | Yes | Whether Yates' continuity correction was applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that the tool is read-only, idempotent, and non-destructive. The description adds minimal behavioral context beyond that, only mentioning that Yates correction is optional (which also appears in the schema). No additional behaviors such as expected output or assumptions are discussed, so the description does not significantly enrich transparency beyond the annotations.
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 description is a single, efficient sentence that conveys the test type, input, and an optional parameter without any filler. It is appropriately sized for the tool's simplicity.
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?
The description, combined with a rich schema (100% parameter coverage) and an existing output schema, is sufficiently complete for an agent to understand what the tool does. It does not mention statistical assumptions (e.g., expected cell counts) or return values, but the output schema covers return details, so this is not a significant gap.
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 100%, with both 'table' and 'correction' parameters already documented in the schema. The description text repeats 'Yates correction optional' but adds no new meaning beyond the schema's existing parameter descriptions.
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 clearly states the specific test ('chi-square test of independence') and the input type ('contingency table'), which distinguishes it from sibling statistical tests like t-tests or correlation. The optional Yates correction is a specific detail that adds further clarity.
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 description provides clear context for when to use the tool: when you have a contingency table and want to test independence. It does not explicitly mention alternatives or when not to use it, but the purpose is specific enough that the intended usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute Pearson or Spearman correlation between two paired variables.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | First variable (numeric observations; same length as y). | |
| y | Yes | Second variable (numeric observations; same length as x). | |
| method | No | Correlation method: 'pearson' or 'spearman'. | pearson |
| Name | Required | Description |
|---|---|---|
| n | Yes | Number of paired observations. |
| method | Yes | Correlation method used. |
| p_value | Yes | p-value for the correlation. |
| statistic | Yes | Correlation coefficient (r for Pearson, rho for Spearman). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond the two methods, which is already visible in the schema's method enum. It does not contradict annotations.
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 description is a single, short sentence that front-loads the core action ('Compute Pearson or Spearman correlation') and includes the target resource. There is no redundant detail or filler, making it appropriately concise.
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?
The tool has an output schema, so return values are not required in the description. Given the simple nature of the operation, the description sufficiently covers purpose and method selection, while annotations and schema handle safety and parameter details. The description is complete for invoking the tool.
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 input schema provides full descriptions for all three parameters (x, y, method), including examples, defaults, and constraints, achieving 100% schema coverage. The description's mention of 'two paired variables' adds no meaning beyond what the schema already states.
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 uses a specific verb ('Compute') and resource ('correlation'), and explicitly names the two methods (Pearson or Spearman). This clearly distinguishes it from sibling tools like stats_t_test or stats_chi_square, which serve different statistical purposes.
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 description implies usage for measuring correlation between two paired variables and mentions both available methods, but it does not explicitly say when to use this tool over alternatives like t-tests or chi-square tests. No when-not guidance or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute descriptive statistics (n, min, max, mean, median, variance, std, skew, kurtosis).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Numeric observations (at least 2 values). |
| Name | Required | Description |
|---|---|---|
| n | Yes | Number of observations. |
| max | Yes | Maximum value. |
| min | Yes | Minimum value. |
| std | Yes | Sample standard deviation (ddof=1). |
| mean | Yes | Arithmetic mean. |
| median | Yes | Median. |
| kurtosis | Yes | Excess kurtosis (Fisher, bias-corrected). |
| skewness | Yes | Skewness (bias-corrected). |
| variance | Yes | Sample variance (ddof=1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific computed statistics but does not disclose return format, edge case handling, or other behavioral traits. This is acceptable given the annotations, but the description carries minimal extra behavioral context.
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 description is a single, front-loaded sentence that immediately states the tool's purpose and the key statistics. No redundant words or repetition of schema details.
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 simple one-parameter tool with rich annotations, a complete output schema, and a clear description of the computed metrics, the description is fully adequate. It does not need to explain return values or elaborate on siblings.
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 100% with the 'data' parameter described as 'Numeric observations (at least 2 values).' The description does not add additional parameter semantics beyond restating the tool's purpose, so it stays at the baseline for well-documented schemas.
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 uses a specific verb ('Compute') and resource ('descriptive statistics') with a detailed list of metrics (n, min, max, mean, etc.). This clearly distinguishes it from siblings like stats_t_test (inferential) and seq_stats (sequence statistics), making its purpose unambiguous.
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?
No explicit when-to-use or alternative tools are mentioned. The usage is implied by the summary statistics list, but there is no guidance on when to select this over inferential statistical tools. This is functional but lacks direct context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Mann-Whitney U test on two independent groups.
| Name | Required | Description | Default |
|---|---|---|---|
| group_a | Yes | First group of numeric observations (at least 2 values). | |
| group_b | Yes | Second group of numeric observations (at least 2 values). | |
| alternative | No | Alternative hypothesis: 'two-sided', 'less', or 'greater'. | two-sided |
| Name | Required | Description |
|---|---|---|
| n_a | Yes | Size of the first group. |
| n_b | Yes | Size of the second group. |
| method | Yes | How the p-value was computed: 'exact' when both groups have n <= 8 and there are no ties, else 'asymptotic'. |
| p_value | Yes | p-value. |
| statistic | Yes | The Mann-Whitney U statistic (for the first group). |
| alternative | Yes | Alternative hypothesis tested. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety profile (read-only, idempotent). The description adds minimal context ('independent groups') but does not elaborate on assumptions, handling of ties, or interpretation. No contradiction with annotations.
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 description is a single, direct sentence with no redundant information. It is front-loaded with the action and clearly expresses the core function.
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?
Given comprehensive schema descriptions, annotations, and an output schema, the description is nearly sufficient for a well-known statistical test. However, it lacks explicit guidance on when to select it over alternative tests, which is a minor gap.
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 100%; all parameters (group_a, group_b, alternative) are well-documented in the schema. The tool description adds no parameter-level detail, so the baseline of 3 applies.
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 explicitly states the statistical test name ('Mann-Whitney U test') and data context ('two independent groups'), making it highly specific and distinguishing it from sibling tools like t-test or chi-square.
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 phrase 'on two independent groups' implies a use case but does not explicitly state when to prefer this over alternatives (e.g., t-test, chi-square) or mention assumptions like non-normality. This leaves the agent to infer from the test name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a two-sample Student or Welch t-test with Cohen's d effect size.
| Name | Required | Description | Default |
|---|---|---|---|
| group_a | Yes | First group of numeric observations (at least 2 values). | |
| group_b | Yes | Second group of numeric observations (at least 2 values). | |
| equal_var | No | If True use Student's t-test (pooled variance, df = n1+n2-2); if False use Welch's t-test (unequal variances, fractional df). | |
| alternative | No | Alternative hypothesis: 'two-sided', 'less', or 'greater'. | two-sided |
| Name | Required | Description |
|---|---|---|
| df | Yes | Degrees of freedom (Welch: fractional; Student: n1+n2-2). |
| method | Yes | Student (equal variances) or Welch (unequal variances). |
| p_value | Yes | p-value for the requested alternative hypothesis. |
| cohens_d | Yes | Effect size: Cohen's d = (mean_a - mean_b) / pooled_sd (positive when group_a mean is larger). |
| statistic | Yes | The t statistic. |
| alternative | Yes | Alternative hypothesis tested. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by disclosing that Cohen's d effect size is computed, which is a behavioral detail beyond annotations. No contradiction exists between the description and annotations.
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 description is a single, front-loaded sentence that efficiently states the core action and a key output (effect size). No redundant or filler content is present.
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?
Given the comprehensive input schema and the presence of an output schema, the brief description is sufficient for selection and invocation. It conveys the essential purpose (two-sample t-test, Student/Welch, Cohen's d) without needing to repeat structured schema details. The only gap is usage guidance, already accounted for in that dimension.
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 schema provides detailed descriptions for all four parameters (group_a, group_b, equal_var, alternative), achieving 100% coverage. The description adds no parameter-level detail, so the baseline of 3 applies as the schema carries the heavy lifting.
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 clearly specifies the tool's function: 'Run a two-sample Student or Welch t-test with Cohen's d effect size.' It identifies a specific statistical test and distinguishes it from siblings like Mann-Whitney (non-parametric) and chi-square (categorical) by naming the parametric test and effect size.
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?
No explicit guidance is provided on when to use this tool versus alternatives. The phrase 'Student or Welch t-test' implies parametric assumptions for comparing two means, but the description does not state when to prefer it over the sibling Mann-Whitney test or mention assumptions like normality or equal variances except through the equal_var parameter in the schema.
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.
v0.1.0seq_gc_contentseq_motif_scanseq_orf_finderseq_reverse_complementseq_statsseq_translatestats_chi_squarestats_correlationstats_describestats_mann_whitneystats_t_testScored across 11 tools
Each tool has a distinct purpose within its domain. The seq_* tools cover motif scanning, GC content, reverse complement, translation, ORF finding, and sequence stats with no overlap. The stats_* tools cover descriptive statistics, t-test, chi-square, Mann-Whitney, and correlation, also without ambiguity. The two domains are clearly separated by prefix and description.
Tool names follow a consistent domain-prefix pattern: seq_ for sequence operations and stats_ for statistical tests. However, within each prefix, the naming style is mixed (e.g., seq_translate is a verb, seq_orf_finder is a noun; stats_describe is a verb, stats_t_test is a noun). This minor inconsistency lowers the score from 5 to 4, but the prefix convention makes names predictable.
With 11 tools, the server is well-scoped for a bioinformatics toolkit. It covers a reasonable set of sequence analysis functions and common statistical tests without being bloated. The count falls well within the ideal range for a focused utility server.
The tool surface covers core sequence operations (translation, reverse complement, GC content, motif scanning, ORF finding, and stats) and common statistical tests (descriptive, t-test, chi-square, Mann-Whitney, correlation). Minor gaps exist, such as sequence alignment or advanced statistical tests like ANOVA, but agents can perform most basic workflows without dead ends.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP with 91 agent tools: X, domains, SEO, Maps, Trends, Search, YouTube, TikTok, and more.
One MCP tool for verified AI-agent outcomes with success-only charging.
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
