Skip to main content
Glama

Build research dossier

build_dossier
Read-onlyIdempotent

Build a multi-section dossier in one call: verified identity, default record sections and top related papers, with citations and per-source outcomes. Workflows: target_dossier, model_input_bundle (gene), drug_review, disease_landscape, pathway_review, variant_dossier, negative_evidence (bounded literature check; never proves absence). Add sections with get_record. e.g. {"workflow":"target_dossier","focus":"LDLR","species":9606}

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workflow": "<workflow>",
      "focus": "<focus>"
    },
    "name": "build_dossier"
  }
}

Input Schema

NameRequiredDescriptionDefault
focusYesGene symbol, drug, disease (MONDO ID or name), pathway (R-HSA ID or exact name), variant, or topic.
speciesNoNCBI taxon ID; 9606 is human.
assemblyNoGenome build for coordinate IDs.
sectionsNoReplace the workflow's default sections.
workflowYes
section_parametersNoOptions keyed by requested section.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is low. The description adds real behavior beyond them: results carry citations and per-source outcomes, and negative_evidence is explicitly bounded and never establishes absence — a caveat an agent could otherwise get wrong.

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 payload sentence is front-loaded, the workflow inventory is compact, and the JSON example earns its space by anchoring required arguments. It is dense with semicolons but no sentence is filler.

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

Completeness4/5

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

An output schema exists, so return shape need not be restated, and annotations cover the safety profile. Given 6 parameters and 7 workflows, the description supplies the workflow semantics and a usage example; only the sections/section_parameters customization path is left entirely to the schema.

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?

Schema coverage is 83%, so the schema already carries most parameter meaning and the baseline applies. The description clarifies that workflow drives which default sections appear and shows a valid focus/species combination, but it never mentions the sections or section_parameters inputs, which are the main knobs for customizing output.

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 names a specific verb and resource ("Build a multi-section dossier in one call") and enumerates exactly what the dossier contains: verified identity, default record sections, top related papers, citations and per-source outcomes. The workflow list plus the concrete example {"workflow":"target_dossier","focus":"LDLR","species":9606} makes it unmistakable against siblings like search_records or query_source.

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 routes the agent across workflows with parenthetical qualifiers — model_input_bundle is for genes, negative_evidence is a bounded literature check that never proves absence — and names get_record as the way to extend a dossier. What is missing is explicit guidance on when to skip the dossier entirely in favor of single-source siblings such as query_source or search_literature.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.