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., "@Computase Translate the sequence ATGGCCTAA"
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.
Computase is a local Python library for small, well-defined DNA and RNA sequence calculations:
nucleotide composition, GC bounds, and GC skew
DNA or RNA reverse complements
translation with selectable NCBI genetic-code tables
six-frame candidate ORF enumeration
IUPAC motif searches on either strand
The Python API is the primary interface. The same operations are also available through the optional Model Context Protocol (MCP) interface for local agent workflows. Computation runs locally; input sequences are not sent to a service.
For most Python environments:
pip install computaseFor a project managed with uv:
uv add computasePython 3.11 or newer is required.
Related MCP server: ESMfold MCP Server
from computase.seq import translate_sequence
sequence = ">synthetic-cds\nATGGCCATTGTAATGGGCCGCTGAAAGGGTGCCCGATAG\n"
result = translate_sequence(sequence, table_id=1)
print(result.model_dump())Representative output (computase_version matches the installed release):
{'computase_version': '<installed version>', 'parameters': {'table_id': 1, 'stop_handling': 'translate-through'}, 'protein': 'MAIVMGR*KGAR*', 'table_id': 1, 'table_name': 'Standard', 'stop_handling': 'translate-through', 'codon_count': 13, 'stopped_early': False}Results are typed Pydantic models. They record the Computase version and effective parameters, but never echo the full input sequence.
See the Python examples for concise, runnable examples of all five sequence operations.
Scientific task | Python function | Contract and validation evidence |
Composition, GC content bounds, and GC skew |
| Preserves IUPAC uncertainty; checked against the GenBank HBB coding sequence and composition/property invariants |
DNA/RNA reverse complement |
| Preserves the input alphabet and IUPAC symbols; checked against an M13 reference sequence and the reverse-complement involution property |
NCBI genetic-code translation |
| Uses a selected NCBI table and requires complete codons; checked against an NCBI translation example and table-specific codons |
Six-frame candidate ORF enumeration |
| Reports forward-reference coordinates and explicit start, stop, and nesting policies; checked with synthetic fixtures spanning all six frames and coordinate round trips |
IUPAC motif search |
| Supports ambiguous symbols, overlapping matches, and either strand; checked against the pUC19 EcoRI site and interval/property tests |
These checks establish the documented conventions and regression boundaries; they do not establish correctness for every biological interpretation or use case. If a result differs from an independent reference, use the scientific correctness report with a minimized, non-sensitive sequence.
Inputs are raw nucleotide strings or a single FASTA record, not multi-record files.
Coordinates are 0-based and end-exclusive on the normalized forward reference, after FASTA headers and whitespace are removed.
Strand is reported separately; normalized_sequence[start:end] reproduces each
reported forward span.
ORFs are sequence candidates, not gene predictions.
IUPAC GC bounds preserve uncertainty rather than assigning probabilities.
Sequence length is capped at 5,000,000 nucleotides; motif and result limits are enforced.
Computase 0.1.x does not fetch records, align sequences, or annotate genes.
With uv installed, uvx can run the MCP server without installing Computase
into the current environment:
{
"mcpServers": {
"computase": {
"command": "uvx",
"args": ["computase"]
}
}
}If Computase was installed with pip into an environment available to the MCP
client, use computase as the command and omit the arguments. For a uv-managed
project, run uv run computase from the project root; configure the MCP client
with uv as the command and ["run", "computase"] as the arguments.
The five tools are computase_summarize_sequence, computase_reverse_complement, computase_translate_sequence, computase_enumerate_orfs, and computase_scan_motif.
uvx computase --transport streamable-http --host 127.0.0.1 --port 8000Connect an MCP client to http://127.0.0.1:8000/mcp. HTTP binds to localhost by default.
Do not expose the Computase HTTP server directly to a public network. Non-loopback deployment requires a separately managed TLS boundary that authenticates every request and enforces request-size, concurrency, and rate limits.
The repository and source distribution include a
Computase companion Skill
that teaches agents when and how to choose the five operations. Prefer the
Computase MCP tools when configured; otherwise the Skill can run an isolated
uv fallback that resolves Computase without mutating the active environment.
Its
usage examples
cover MCP, runner, and Python workflows. These Skill files are not installed by
the Python wheel.
Install the Skill into a supported agent with:
npx skills add madhusudan-kulkarni/computase --skill computaseskills.sh indexes public repositories from install telemetry. There is no separate submission form.
Use uv sync --locked --extra dev, then run:
uv lock --check
uv run --locked ruff format --check src tests evaluations scripts skills/computase/scripts
uv run --locked ruff check src tests evaluations scripts skills/computase/scripts
uv run --locked mypy src tests evaluations scripts skills/computase/scripts
uv run --locked pytest -q
uv run --locked python -m evaluations.runnerSee CONTRIBUTING.md for reference-vector requirements.
See ROADMAP.md for planned capabilities, including melting temperature calculations, restriction digestions, and a client-side WebAssembly interface.
If Computase contributes to your work, cite the software metadata in CITATION.cff. GitHub also exposes this through Cite this repository. Computase is also registered on bio.tools.
Computase is licensed under the MIT License.
Enumerate bounded candidate ORFs across all six reading frames.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Raw nucleotide sequence or one FASTA record; IUPAC codes are accepted. The normalized sequence is limited to 5,000,000 nucleotides. | |
| table_id | No | NCBI genetic-code table identifier. | |
| max_results | No | Maximum returned candidates. | |
| require_stop | No | Require an in-frame terminal stop codon. | |
| start_codons | No | Allowed start-codon policy. | table-starts |
| min_length_nt | No | Minimum nucleotide span including stop. | |
| include_nested | No | Report starts nested before the same stop. |
| Name | Required | Description |
|---|---|---|
| note | No | Scientific interpretation boundary. |
| orfs | Yes | Candidate ORFs in deterministic coordinate order. |
| truncated | Yes | Whether candidates were omitted by max_results. |
| parameters | No | Effective operation parameters, excluding the input sequence. |
| total_found | Yes | Total candidates found before result limiting. |
| computase_version | No | Computase version used for the computation. |
| coordinate_system | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context by specifying that ORFs are 'bounded' and that enumeration covers 'all six reading frames,' going beyond what annotations alone convey.
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 leads with the action and resource, then adds the critical six-frame scope. There is zero redundant wording and every word contributes to understanding the tool's purpose.
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 a rich input schema with full parameter documentation and an output schema, so the one-sentence description is sufficient for selection and basic invocation. It does not explain the exact meaning of 'bounded,' but the schema's require_stop, max_results, and min_length_nt parameters clarify that concept.
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 each of the 7 parameters is already well documented with types, defaults, and constraints. The description adds no parameter-specific meaning, but it does not need to because the schema carries that burden.
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 ('Enumerate') and a specific resource ('bounded candidate ORFs'), and adds the important scope detail 'across all six reading frames.' This clearly distinguishes the tool from siblings like translate_sequence or scan_motif, which perform different biological analyses.
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 gives clear operational context: if the task is to enumerate candidate ORFs in all six reading frames, this is the tool to use. It does not explicitly list exclusions or alternatives, but the sibling names are distinct enough that an agent can infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute an IUPAC-aware DNA or RNA reverse complement.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Raw nucleotide sequence or one FASTA record; IUPAC codes are accepted. The normalized sequence is limited to 5,000,000 nucleotides. |
| Name | Required | Description |
|---|---|---|
| length | Yes | Normalized input sequence length. |
| parameters | No | Effective operation parameters, excluding the input sequence. |
| sequence_type | Yes | Detected nucleotide alphabet. |
| computase_version | No | Computase version used for the computation. |
| reverse_complement | Yes | Reverse complement in the same DNA or RNA alphabet. |
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 that IUPAC codes are handled and both DNA and RNA are supported, but it does not disclose edge-case behavior such as FASTA header handling or output formatting. No contradiction with annotations 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?
The description is a single, front-loaded sentence with no filler. Every phrase contributes meaning: 'Compute,' 'IUPAC-aware,' 'DNA or RNA,' and 'reverse complement.'
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 single-parameter, schema-backed, annotation-covered read-only transformation with an output schema, the description is sufficient. An agent has everything needed to invoke it correctly: input type, molecule scope, alphabet handling, and safety profile are all covered.
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%, and the schema already documents the accepted formats, IUPAC support, and the 5,000,000-nucleotide cap. The tool description adds only that the input is DNA or RNA, which is marginal beyond the schema's 'nucleotide sequence' wording.
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 the exact operation ('Compute'), the target resource ('reverse complement'), and the scope ('DNA or RNA', 'IUPAC-aware'). This clearly distinguishes it from the sibling tools (summarize, translate, enumerate ORFs, scan motif), so an agent can immediately identify the right tool.
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 explicit guidance about when to use this tool versus the sibling tools, nor any exclusions. However, the operation is so specific that the intended usage is strongly implied: use it whenever a DNA or RNA reverse complement is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan an IUPAC motif on the forward, reverse, or both strands.
| Name | Required | Description | Default |
|---|---|---|---|
| motif | Yes | IUPAC nucleotide pattern. | |
| strand | No | Strand orientation to scan. | forward |
| sequence | Yes | Raw nucleotide sequence or one FASTA record; IUPAC codes are accepted. The normalized sequence is limited to 5,000,000 nucleotides. | |
| max_matches | No | Maximum returned sites. | |
| overlapping | No | Report overlapping sites. |
| Name | Required | Description |
|---|---|---|
| motif | Yes | Normalized IUPAC motif. |
| strand | Yes | Requested strand policy. |
| matches | Yes | Motif occurrences in coordinate order. |
| truncated | Yes | Whether occurrences were omitted by max_matches. |
| parameters | No | Effective operation parameters, excluding the input sequence. |
| total_found | Yes | Total occurrences before result limiting. |
| computase_version | No | Computase version used for the computation. |
| coordinate_system | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds the strand-orientation behavior but does not disclose details like match truncation, overlapping behavior, or edge cases; these are left to the schema and output 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?
A single, front-loaded sentence with no filler. Every word earns its place, and the core action and scope are presented clearly.
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 output schema, full parameter documentation, and safety annotations, the description is mostly sufficient. The only gap is the lack of explicit guidance about when to choose this tool over siblings, which is a minor omission.
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 all five parameters. The description mentions motif and strands but adds no semantic value beyond what the parameter descriptions already provide.
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 specific action ('Scan'), a specific input type ('IUPAC motif'), and a clear scope ('forward, reverse, or both strands'). This clearly distinguishes it from sibling tools like reverse-complementing, translating, or summarizing sequences.
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: an agent can infer this tool is for finding motif occurrences rather than for sequence transformation or summarization. However, there is no explicit when-to-use/when-not-to-use guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize composition, GC uncertainty, and GC skew.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Raw nucleotide sequence or one FASTA record; IUPAC codes are accepted. The normalized sequence is limited to 5,000,000 nucleotides. |
| Name | Required | Description |
|---|---|---|
| length | Yes | Normalized sequence length. |
| gc_skew | Yes | Concrete-base (G-C)/(G+C), or null when no concrete G/C exists. |
| gc_percent | Yes | GC percentage over residues with determinate GC status. |
| parameters | No | Effective operation parameters, excluding the input sequence. |
| composition | Yes | Counts for every residue present. |
| dinucleotides | Yes | Counts of overlapping adjacent residue pairs. |
| sequence_type | Yes | Detected nucleotide alphabet. |
| gc_max_percent | Yes | Maximum possible GC percentage under IUPAC resolutions. |
| gc_min_percent | Yes | Minimum possible GC percentage under IUPAC resolutions. |
| ambiguous_count | Yes | Number of non-ACGT or non-ACGU IUPAC residues. |
| computase_version | No | Computase version used for the computation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the output metrics (composition, GC uncertainty, GC skew) but does not describe behavior such as normalization or how input limits are handled beyond what the schema already states. 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, front-loaded sentence with no filler or redundant restating of the title. Every word adds value by naming the specific analysis outputs.
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, rich annotations, and the presence of an output schema, the description is largely complete. It names the key computed metrics, and the output schema covers return details. It falls slightly short only by not addressing usage context relative to siblings, but this 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%, and the one required parameter 'sequence' has a descriptive schema entry including accepted inputs and length limits. The tool description adds no additional meaning beyond what the schema already provides, so the 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 uses a specific verb ('Summarize') with a clear resource and names three concrete outputs: composition, GC uncertainty, and GC skew. This distinguishes it from siblings like reverse_complement or translate_sequence, which perform transformations rather than summary statistics.
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 explicit guidance on when to use this tool versus the sibling tools. The purpose implies it is for sequence summary statistics rather than transformations or motif scanning, but no when-to-use or when-not-to-use conditions are stated, leaving the agent to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate complete codons with a selected NCBI genetic code.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Raw nucleotide sequence or one FASTA record; IUPAC codes are accepted. The normalized sequence is limited to 5,000,000 nucleotides. | |
| table_id | No | NCBI genetic-code table identifier. | |
| stop_handling | No | Stop-codon handling policy. | translate-through |
| Name | Required | Description |
|---|---|---|
| protein | Yes | Translated protein, with stops represented as '*'. |
| table_id | Yes | NCBI genetic-code table identifier. |
| parameters | No | Effective operation parameters, excluding the input sequence. |
| table_name | Yes | Primary NCBI genetic-code table name. |
| codon_count | Yes | Number of complete input codons. |
| stop_handling | Yes | Effective stop-codon handling policy. |
| stopped_early | Yes | Whether translation was truncated at an encountered stop codon. |
| computase_version | No | Computase version used for the computation. |
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 some behavioral context by restricting translation to complete codons and allowing a selectable genetic-code table, but it leaves undefined edge behaviors like partial trailing codons or stop-codon outcomes, which are only implied by 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 description is a single concise sentence with no filler. It front-loads the action ('Translate complete codons') and includes the key qualifier ('selected NCBI genetic code'), making it appropriately sized for a straightforward operation.
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 rich input schema, output schema, and annotations carry most of the operational details, making the description adequate for invoking the tool. However, it is slightly incomplete because it does not position the tool against the related ORF-enumeration sibling or clarify partial-codon handling.
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 sequence, table_id, and stop_handling are already fully documented. The description adds little beyond restating the genetic-code selection, so the schema-based 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 names a specific verb ('Translate') and resource ('complete codons'), with a meaningful qualifier ('selected NCBI genetic code'). This clearly distinguishes the tool from siblings such as reverse_complement or scan_motif, and 'complete codons' helps separate it from ORF enumeration.
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 the intended use—translating a nucleotide sequence with a chosen genetic code—but it does not explicitly say when to choose this tool over computase_enumerate_orfs or any other sibling. There is no when-not-to-use guidance or mention of alternatives.
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.2computase_enumerate_orfs2 fields changedOutput schema / $defs / Orf / properties / computase_version / defaultPrevious value: -"0.1.1"New value: +"0.1.2"Output schema / properties / computase_version / defaultPrevious value: -"0.1.1"New value: +"0.1.2"computase_reverse_complement1 field changedOutput schema / properties / computase_version / defaultPrevious value: -"0.1.1"New value: +"0.1.2"computase_scan_motif2 fields changedOutput schema / $defs / MotifMatch / properties / computase_version / defaultPrevious value: -"0.1.1"New value: +"0.1.2"Output schema / properties / computase_version / defaultPrevious value: -"0.1.1"New value: +"0.1.2"computase_summarize_sequence1 field changedOutput schema / properties / computase_version / defaultPrevious value: -"0.1.1"New value: +"0.1.2"computase_translate_sequence1 field changedOutput schema / properties / computase_version / defaultPrevious value: -"0.1.1"New value: +"0.1.2"v0.1.1computase_enumerate_orfscomputase_reverse_complementcomputase_scan_motifcomputase_summarize_sequencecomputase_translate_sequenceScored across 5 tools
Each tool targets a distinct operation: summarization, reverse complement, translation, ORF enumeration, and motif scanning. There is no functional overlap or ambiguity between them.
All tools follow a consistent snake_case verb_noun pattern with the same computase_ prefix. The naming is uniform and predictable across the entire set.
Five tools form a compact, purposeful toolkit for common sequence analysis tasks. Each tool adds meaningful capability without bloat or triviality.
The server covers core sequence manipulation and analysis workflows: composition stats, complementing, translation, ORF detection, and motif scanning. Minor gaps such as restriction enzyme analysis or format conversion exist, but the main stated domain is well served.
Structured analysis API and remote MCP tool for text, JSON records and numeric series.
Workflow diagnostics, capability routing, and x402 settlement for MCP-compatible agents.
Hosted DNA/RNA/protein tools: primers, oligos, PCR, cloning, CRISPR, alignment, batch & pipelines.
Agent-driven search: build, import, tune, search, and score result quality — all over MCP.
