Skip to main content
Glama

biomcp_configure

DestructiveIdempotent

Inspect BioMCP feature status, update configuration, or reset parameters in one atomic batch. Validate changes with dry-run, then apply them by restarting the client.

Instructions

Inspect and configure biomcp — unified observability and restricted controllability for every parameter.

What it covers: three optional feature groups (database, analysis_r, analysis_biowasm) whose knobs live in the .biomcp.json project config file (written by this tool, loaded at server startup — a restart applies changes), plus every environment-only parameter (API keys, proxy, security boundaries), which is query-only.

Actions:

  • status (default; call with {}): per-feature running state (with each feature's settable_keys), config file health, conflicts (e.g. an env var vetoing the file), pending-restart flags, dependency prerequisites, and parameter counts. The full parameter catalog is NOT inlined — use filter for detailed rows: 'file', 'env', a feature id ('analysis_r'), or a dotted-id prefix ('features.database').

  • set: create/modify file parameters in one atomic batch. Enable/disable is just features..enabled. null removes a key (restores default). Sensitive keys (connection targets, mirrors) require confirm_sensitive=true. Nothing is written when any key is invalid (dry_run=true validates and diffs without writing).

  • reset: remove a feature section (target: feature id) or specific keys (target: [dotted ids]).

Hard rules: environment parameters are never settable here (the response tells you how to set them in your client's env block); env var values are never displayed (masked: presence + fingerprint only); the file write is refused when the server's working directory is not a project root — the response then carries a paste-ready env block instead.

Examples: {"action":"status"} · {"action":"status","filter":"features.analysis_r"} · {"action":"set","values":{"features.analysis_biowasm.enabled":true}} · {"action":"set","values":{"features.database.enabled":true,"features.database.type":"sqlite","features.database.sqlite_path":["data/geo.db"]}} · {"action":"set","values":{"features.analysis_r.mirror_url":null}} · {"action":"reset","target":"analysis_r"}

Changes apply at server startup: finish dependency prerequisites first (see prerequisites in the response), then restart the client/session once, then re-call this tool with {} to verify running_now.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNostatus = inspect (default, works with no other arguments); set = create/modify file parameters; reset = remove.status
filterNoFor status: "file" | "env" | feature id | dotted-id prefix — returns detailed rows (effects, how-to-set).
targetNoFor reset: a feature id ("database" | "analysis_r" | "analysis_biowasm") removes the whole section, or a list of dotted file-param ids removes those keys.
valuesNoFor set: {"<dotted file-param id>": <value|null>} — e.g. {"features.analysis_r.enabled": true}. null removes the key. Valid ids are listed by status.
dry_runNoValidate and diff without writing (set/reset).
confirm_sensitiveNoRequired true when set/reset touches sensitive keys (connection targets, mirrors, credentials).
Install Server

TDQS

A5/5.0
Behavior5/5

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

Annotations indicate a non-read-only, destructive, idempotent tool, and the description richly expands on these traits: atomic batch writes, null removal semantics, dry-run validation, sensitive-key confirmation, write refusal outside project roots, env masking, and pending-restart behavior. There is no contradiction with 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.

Conciseness5/5

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

The description is long but appropriately so for a tool with three actions, hard rules, and restart semantics. It is structured with clear headings, compact bullet-like action definitions, and illustrative examples; the front-loaded purpose and action summary make it easy to scan.

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?

With no output schema, the description compensates by explaining what status returns, how filtering works, what happens on invalid writes or dry runs, and how the response guides env-parameter setup. It also covers sensitive keys, project-root refusal, dependency prerequisites, and the post-change verification workflow, making the tool safely callable without additional documentation.

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?

Although the schema already describes all six parameters at 100% coverage, the description adds substantial semantic context beyond the schema: valid filter categories and dotted-id prefixes, the meaning of empty values as null-removal, the distinction between feature-section reset and key-list reset, and the behavior of dry_run and confirm_sensitive.

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 states a specific verb and resource: inspect and configure biomcp's parameters across feature groups and environment-only settings. It clearly distinguishes this tool from the biomedical query siblings by scoping it to biomcp configuration, and it enumerates the three actions and the config file involved.

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?

The description gives explicit when-to-use guidance for each action: status for inspection, set for creation/modification, reset for removal, plus filter usage for detailed rows. It also states hard exclusions — environment parameters are never settable here and env var values are never displayed — and provides concrete examples and a restart workflow.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yeyuan98/biomcp-ts'

If you have feedback or need assistance with the MCP directory API, please join our Discord server