Skip to main content
Glama

workbench

by com.seqbench

Prime Editing Studio (pegRNA)

prime_editing_design
Read-onlyIdempotent

Design SpCas9 prime-editing pegRNAs for a substitution, insertion, deletion, or small replacement: for each usable NGG PAM it builds the spacer, a primer-binding-site (PBS) length sweep targeting a ~30 C melting temperature, the reverse-transcriptase template (RTT) that encodes the edit, and the full 3' extension, plus PE3 nicking-sgRNA suggestions 40-90 bp away on the opposite strand. Designs where the edit destroys the pegRNA's own PAM (preventing re-nicking of the edited allele) are ranked first. Coordinates: every pegRNA coordinate (protospacer span, nick position, editStart/editEnd) is 1-based inclusive in the submitted PRE-EDIT target's frame — the protospacer+PAM search runs on the unedited sequence, because Cas9 has to bind the allele you actually have. The one exception is edit-dependent PE3b nicking guides, which exist only once the edit is installed; each nickingGuides entry therefore carries a coordinateFrame field of "target" or "editedSequence" naming the frame its own start/end/nickToNickDistance are measured in, and for a length-changing edit the two frames differ downstream of the edit. Off-target activity is not evaluated (no in-browser reference genome).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYesForward-strand target DNA (raw or FASTA), with flanking sequence around the intended edit.
editEndYes1-based inclusive end of the region being changed. For a pure insertion, set editEnd = editStart - 1.
editStartYes1-based inclusive start of the region being changed.
pbsLengthNoOptional preferred PBS length to highlight; a full 8-17 nt sweep is always returned.
frameStartNoOptional 1-based CDS reading-frame start, used only to annotate whether a PAM-blocking mutation would be silent.
insertedSeqNoReplacement bases (forward strand). Empty string means a deletion.
rttHomologyNoHomology length (nt) 3' of the edit that the RTT should include (typically 10-16).

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes far beyond the readOnlyHint and idempotentHint annotations. It discloses the coordinate frame behavior (1-based inclusive, pre-edit frame), explains the exception for PE3b guides via a coordinateFrame field, and notes the ranking priority for PAM-destroying edits. It also discloses the absence of off-target evaluation, providing deep 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense, with each sentence adding value. It is well-structured, starting with the core purpose and then detailing coordinates, ranking, and limitations. While not as curt as a two-sentence example, the complexity justifies the length, and the text is front-loaded with the most important information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description explains the shape of the returned data (nickingGuides entries with coordinateFrame) and the key behavioral rules (PAM destruction ranking, coordinate frame semantics). It also notes a limitation (no off-target scoring), making it highly complete for an agent to understand what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers 100% of parameters, so the baseline is 3. The description adds some context (e.g., explaining that a pure insertion uses editEnd = editStart - 1), but this duplicates schema descriptions. It does not add significant new meaning beyond the schema for individual parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Design') and a precise resource ('SpCas9 prime-editing pegRNAs'), and enumerates the edit types (substitution, insertion, deletion, or small replacement). It clearly distinguishes itself from the sibling tool prime_editing_twin_design by detailing the pegRNA design workflow and PE3 nicking-sgRNA suggestions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly scopes when to use the tool: for prime editing of small edits with an NGG PAM, and it states what is and is not evaluated (e.g., 'Off-target activity is not evaluated'). It does not explicitly name alternatives or when-not-to-use, but the scope and constraints are clear enough to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All workbench toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation4/5

Most tools have highly specific purposes (e.g., crispr_grna_design vs base_editing_design vs prime_editing_design). However, there is some overlap in sequence analysis tools (characterize_sequence, sequence_report) and plasmid annotation tools (plasmid_annotate vs plasmid_deep_annotate) which could cause confusion.

Naming Consistency3/5

The naming pattern is largely consistent with snake_case verb_noun or noun_descriptor (e.g., primer_design, plasmid_annotate, fastq_trim). However, there are exceptions like 'batch', 'workflow', 'gc_content', and 'cloning_diagnose' which don't follow the verb_noun pattern consistently. Also, some names are phrases like 'golden_gate_from_parts'.

Tool Count2/5

With 101 tools, this server is extremely large and likely overwhelming for agents. Even for a comprehensive bioinformatics toolkit, this exceeds a manageable scope, risking agent confusion and inefficient tool selection. A more modular approach would be advisable.

Completeness4/5

The tool surface covers a wide range of bioinformatics workflows including sequence analysis, primer design, cloning, CRISPR, NGS, expression analysis, and data export. There are minor gaps such as lack of a dedicated protein structure prediction tool and limited off-target genome coverage, but overall the set is impressively complete for its domain.

Resources