Skip to main content
Glama
bpp

bpp-mcp

by bpp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

make_control_file

Generates a BPP control file for species tree, delimitation, or joint analyses, returning its text and path for linting before BPP runs.

Instructions

Create a BPP control file (bpp-lint --template --suggest-priors).

Never write a control file yourself; use this, then lint_control_file.

  • analysis: A00 = estimate parameters on a fixed species tree; A01 = estimate the species tree; A10 = species delimitation on a fixed guide tree; A11 = joint species delimitation and species tree. Ask the user, explaining the choices in plain language.

  • seqfile, imapfile: from convert_data (PREFIX.txt, PREFIX.imap). stree_file: from build_species_tree (PREFIX.stree). nloci: from convert_data's server.nloci. out: the control file to write. Data paths are written relative to the control file's folder.

  • phase: for unphased diploid data, one digit per species in species&tree order (look up 'phase' with lookup_docs and ask the user).

  • thetaprior, tauprior: leave unset to use priors derived from the data (inverse-gamma, alpha = 3); set only if the user asks.

  • nsample, burnin, sampfreq, seed: chain settings; template defaults apply when unset. Discuss chain length with the user.

  • extra: any other keywords as {"keyword": "value"}, e.g. {"wprior": "...", "threads": "..."}. Each name is checked against the manual's keyword list. Look up the syntax with lookup_docs first.

  • overwrite: an existing file is refused unless true. Ask the user.

Returns the file's text and path. server.workarounds_applied lists patches for known bpp-lint bugs. Next: lint_control_file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outYes
seedNo
extraNo
nlociYes
phaseNo
burninNo
jobnameNoout
nsampleNo
seqfileYes
analysisYes
imapfileYes
sampfreqNo
taupriorNo
overwriteNo
stree_fileYes
thetapriorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations declare a non-readOnly write with destructiveHint=false; the description adds genuinely new behavior: existing files are refused unless overwrite=true, and server.workarounds_applied reports patches for known bpp-lint bugs. Return shape (text and path) is also disclosed, though it does not detail file-size or error modes.

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?

Front-loaded with purpose and an imperative, then organized as tight per-parameter bullets. It is long, but for a 16-parameter tool nearly every line earns its place; the density is justified rather than padded.

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?

For a complex file-generating tool with no output schema, the description covers inputs, defaults, the overwrite guard, the return payload, bug workarounds, and the next step. An agent has everything needed to call it correctly without opening the schema.

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

Parameters5/5

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

Schema coverage is 0%, so the description must carry the burden, and it does: it explains analysis codes, the source tools for seqfile/imapfile/stree_file/nloci, path relativization, phase digit rules, prior defaults, chain settings, and extra-keyword validation. Only jobname is undocumented, which is minor against 16 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?

States a specific verb and resource ('Create a BPP control file') plus the underlying mechanism (bpp-lint --template --suggest-priors), and clearly distinguishes itself from siblings like lint_control_file and upgrade_control_file by positioning itself as the creation step.

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

Usage Guidelines5/5

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

Explicitly says 'Never write a control file yourself; use this, then lint_control_file' and gives per-parameter when-to-use rules (ask the user for analysis; leave priors unset unless asked). The workflow handoff is unambiguous.

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

Deploy Server

Other Tools