Skip to main content
Glama

run_beta_cell

Read-only

Fit early aggregate C-peptide ratios and evaluate later visits without using them in optimization. Read beta_cell_guide first. Returns simple-baseline errors, identifiability checks, source snapshots, solver replay manifests and eight hypothetical mechanism combinations. Stateless and read-only. No ranking, clinical prediction or automatic Agent Council ratification.

Input Schema

NameRequiredDescriptionDefault
datasetNoclver (bundled CLVer aggregate C-peptide data, default) or custom (supply customDataset).clver
recoveryRateNoNative beta-cell recovery rate per week, 0.02 to 0.3. Default 0.1.
customDatasetNoAggregate dataset, only when dataset=custom: {id, citation (https), population, assay, reportedUnit, kind, statistic, arms:[control, comparator] with 5 to 20 {week, value} points each}. See beta_cell_guide.
durationWeeksNoScenario length in weeks: 52, 78 or 104. Default 52.
graftAttritionNoNon-immune graft loss per week, 0 to 0.1. Default 0.01.
graftProtectionNoFraction of graft protected from immune attack, 0 to 1. Default 0.8.
immuneSuppressionNoFraction of autoimmune attack removed in the scenario, 0 to 1 (dimensionless). Default 0.5.
trainingThroughWeekNoLast week used for fitting (weeks). Fixed at 39 for clver; later visits are held out. Example 39.
replacementContributionNoAdded beta-cell function from replacement, relative to baseline, 0 to 2. Default 0.25.

Output Schema

NameRequiredDescriptionDefault
dataNoThe answer. Shape depends on the tool; describe_tool documents it.
_metaNosource, generatedAt, sources (per-source lastSyncedAt and ageHours), rateLimit, disclaimer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "_meta": {
      +      "additionalProperties": {},
      +      "description": "source, generatedAt, sources (per-source lastSyncedAt and ageHours), rateLimit, disclaimer.",
      +      "propertyNames": {
      +        "type": "string"
      +      },
      +      "type": "object"
      +    },
      +    "data": {
      +      "description": "The answer. Shape depends on the tool; describe_tool documents it."
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed9 schema fields changed
    • addedInput schema / properties / customDataset / description
      Added value: +"Aggregate dataset, only when dataset=custom: {id, citation (https), population, assay, reportedUnit, kind, statistic, arms:[control, comparator] with 5 to 20 {week, value} points each}. See beta_cell_guide."
    • addedInput schema / properties / dataset / description
      Added value: +"clver (bundled CLVer aggregate C-peptide data, default) or custom (supply customDataset)."
    • addedInput schema / properties / durationWeeks / description
      Added value: +"Scenario length in weeks: 52, 78 or 104. Default 52."
    • addedInput schema / properties / graftAttrition / description
      Added value: +"Non-immune graft loss per week, 0 to 0.1. Default 0.01."
    • addedInput schema / properties / graftProtection / description
      Added value: +"Fraction of graft protected from immune attack, 0 to 1. Default 0.8."
    • addedInput schema / properties / immuneSuppression / description
      Added value: +"Fraction of autoimmune attack removed in the scenario, 0 to 1 (dimensionless). Default 0.5."
    • addedInput schema / properties / recoveryRate / description
      Added value: +"Native beta-cell recovery rate per week, 0.02 to 0.3. Default 0.1."
    • addedInput schema / properties / replacementContribution / description
      Added value: +"Added beta-cell function from replacement, relative to baseline, 0 to 2. Default 0.25."
    • addedInput schema / properties / trainingThroughWeek / description
      Added value: +"Last week used for fitting (weeks). Fixed at 39 for clver; later visits are held out. Example 39."
  3. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds meaningful context: 'Stateless and read-only', the design constraint that later visits are not used in optimization, and the list of returned artifacts (simple-baseline errors, identifiability checks, source snapshots, solver replay manifests, eight mechanism combinations). It stops short of explaining failure modes or interpretation of the identifiability checks, so it is strong but not exhaustive.

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 four purposeful sentences, front-loading the core action before the prerequisite, return list, and scope caveats. The jargon density (solver replay manifests, identifiability checks) is high, but every sentence carries information relevant to correct invocation.

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?

For a complex tool with nine parameters, a nested custom dataset, and a dedicated output schema, the description covers the operation, prerequisite reading, return contents, and scope exclusions. Because the output schema and 100%-covered input schema carry the structural detail, no critical invocation information is missing, though the interpretation of returned diagnostics is left implicit.

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 description coverage is 100% – all nine parameters, including the nested customDataset envelope, have detailed descriptions and ranges in the schema. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline of 3 applies.

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 description uses a specific verb+resource combo ('Fit early aggregate C-peptide ratios and evaluate later visits') and names the domain artifact (beta_cell_guide). It is distinguishable from siblings mostly via the negative scope statement 'No ranking, clinical prediction or automatic Agent Council ratification', which implicitly separates it from agent_council and ranking tools. The heavy domain jargon (identifiability checks, solver replay manifests) makes the exact purpose slightly opaque without prior context.

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 an explicit prerequisite ('Read beta_cell_guide first') and clear exclusions ('No ranking, clinical prediction or automatic Agent Council ratification'), which tell an agent when this tool is the wrong choice. It does not name a specific alternative tool for the excluded tasks, leaving the agent to infer that agent_council or ranking tools fill those roles.

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.

Resources