Skip to main content
Glama
yeyuan98

BioMCP

by yeyuan98
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

batch_get

Read-only

Fetch multiple biomedical entities in parallel and return per-item results, including article metadata and errors for invalid IDs, so batches continue without failing.

Instructions

Get multiple entities in parallel. Article items return metadata (with inline abstract) by default; for full text pass sections:["fulltext"] on the item — PMC articles then return a small file handle (file_path + outline, never body text inline) while non-PMC articles return an explicit unavailable + reason. Nonexistent PMIDs yield a per-item error and the batch continues. For inline text use article_get with fulltext_output="inline"

Input Schema

NameRequiredDescriptionDefault
inputsYesList of entity requests

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.0-alpha.10
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / inputs / items / additionalProperties
      Removed value: -false
  2. Changed1 schema field changedv1.6.0-alpha.7
    • addedInput schema / properties / inputs / items / properties / id / minLength
      Added value: +1
  3. Changed1 schema field changedv0.7.1
    • changedInput schema / properties / inputs / items / properties / entity / enum
      Previous value: -[
-  "gene",
-  "variant",
-  "drug",
-  "disease",
-  "trial",
-  "article"
-]New value: +[
+  "gene",
+  "variant",
+  "drug",
+  "disease",
+  "trial",
+  "article",
+  "patent"
+]
  4. First observedv0.1.8

TDQS

A4.3/5.0
Behavior5/5

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

Beyond readOnlyHint, the description discloses the default return shape (metadata with inline abstract), the conditional behavior of sections:["fulltext"] per source (PMC returns a file handle with file_path + outline and never body text; non-PMC returns explicit unavailable plus a reason), and crucially the partial-failure contract — a bad PMID yields a per-item error while the batch continues. That error-isolation semantics is exactly the kind of behavior the annotation cannot convey.

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 default behavior is front-loaded and every clause carries operational information with no filler. The middle sentence is a long run-on that packs three conditional branches together, which slightly hurts scannability, but nothing is wasted.

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 batched read tool with one nested parameter and no output schema, the description covers defaults, per-entity-type return differences, the fulltext escape hatch, and per-item error handling — enough for an agent to call it and interpret results without trial and error.

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

Parameters4/5

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

Schema coverage is 100% and the nested item shape is fully specified, so the baseline is 3. The description earns above that by giving the only non-obvious value: sections:["fulltext"], including what that value does and how results differ for PMC vs non-PMC items — information the open-ended string array in the schema cannot supply.

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

Purpose4/5

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

The opening sentence states a specific verb and resource (get multiple entities) plus the key differentiator 'in parallel', which separates it from the many singular *_get siblings. It further scopes behavior to article items, but never states the tool is *only* for articles — the entity enum in the schema carries that breadth, leaving the description's stated purpose narrower than the tool actually is.

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?

It gives one explicit routing rule: for inline text use article_get with fulltext_output="inline", which directly resolves the most likely confusion. It does not, however, say when to prefer batch_get over the singular siblings (gene_get, drug_get, etc.) or whether there is any overhead tradeoff for small batches, so the general when-to-use guidance is left to inference.

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