Skip to main content
Glama
Sign In

SanYu Research Engine

by com.wentangkeji.sanyu
OverviewDiscussionsAdmin

Full research protocol generation / 完整研究方案 / 方案设计工具

design_protocol_generate
Read-only

Full research protocol generation / 完整研究方案 / 方案设计工具 | USE WHEN: the user wants a complete research protocol including sample size, statistical plan and ethics points | ALIASES: 研究方案, 方案正文, 写方案, 方案生成, protocol, full protocol | RETURNS: 完整研究方案 JSON（14 段）或单项工具结构化结果；缺参时返回 needs_user_input 明确列出缺什么，不返回编造值

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": {
      "tool_name": "<tool_name>"
    },
    "name": "design_protocol_generate"
  }
}

Input Schema

NameRequiredDescriptionDefault
p1No二分类结局：试验组预期发生率（0~1）
p2No二分类结局：对照组预期发生率（0~1）
alphaNo显著性水平，默认 0.05
powerNo检验效能，默认 0.80
topicNo研究选题（一句话）
designNo指定设计类型（rct/cohort/case_control/cross_sectional）；不填则由 PICO 自动推荐
outcomeNoO：主要终点指标（如“28天病死率”“总生存期”“HbA1c 变化值”）
n_groupsNo分组数，默认 2
n_centersNo参与中心数，默认 1
tool_nameYes工具名。推荐 full_proposal（一次输出完整方案）。可选：full_proposal / eligibility_criteria / intervention_detail / randomization / blinding_plan / bias_control / budget_gantt / sample_size_calc / spirit_check / compliance_check
comparisonNoC：对照措施（安慰剂/标准治疗/未暴露）
event_rateNo生存结局：观察期内事件发生率（0~1）
n_subjectsNo受试者例数（预算估算用；不填则用样本量计算结果）
populationNoP：目标人群（疾病/年龄/严重程度）
effect_sizeNo连续结局的标准化效应量 Cohen's d
dropout_rateNo预计脱落率，默认 0.10
hazard_ratioNo生存结局：预期风险比 HR（≠1）
interventionNoI：干预或暴露措施
outcome_typeNo主要终点数据类型：continuous / binary / time_to_event / count；不填按指标名自动识别
completed_stepsNospirit_check / compliance_check 用：已完成的方案步骤编号（1~9）
duration_monthsNo研究周期（月），默认 24
primary_timepointNo主要终点评价时点（如“治疗 12 周”）
secondary_outcomesNo次要终点，多个用分号分隔

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed8 schema fields changed
    • addedInput schema / properties / duration_months
      Added value: +{
+  "description": "研究周期（月），默认 24",
+  "type": "integer"
+}
    • addedInput schema / properties / n_centers
      Added value: +{
+  "description": "参与中心数，默认 1",
+  "type": "integer"
+}
    • addedInput schema / properties / n_subjects
      Added value: +{
+  "description": "受试者例数，默认 60",
+  "type": "integer"
+}
    • removedInput schema / properties / prompt
      Removed value: -{
-  "description": "研究方案需求描述",
-  "type": "string"
-}
    • removedInput schema / properties / title
      Removed value: -{
-  "description": "研究题目",
-  "type": "string"
-}
    • addedInput schema / properties / tool_name
      Added value: +{
+  "description": "工具名，当前仅支持 budget_gantt",
+  "type": "string"
+}
    • removedInput schema / properties / type
      Removed value: -{
-  "description": "研究类型",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "prompt"
-]New value: +[
+  "tool_name"
+]
  4. Added
  5. Removed
  6. Added
  7. Removed
  8. Added
  9. Removed
  10. Added
  11. Removed
  12. 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: it returns a 14-section protocol JSON or a single-section structured result, and on missing inputs it returns needs_user_input listing exactly what is absent rather than fabricating values. This is strong disclosure of failure behavior.

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?

Pipe-delimited sections (purpose / USE WHEN / ALIASES / RETURNS) front-load the trigger and the return contract with no filler. The title is restated at the top and the Chinese aliases are repeated in the title, which is minor redundancy rather than bloat.

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 23-parameter tool with no output schema, the RETURNS clause is essential and present, explaining both the full-proposal shape and the single-section shape plus the missing-parameter response. The main residual gap is that the description does not explain the tool_name dispatch model, though the schema enum and its own description cover it.

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% across 23 parameters, including the enum for tool_name and outcome_type, so the schema does the heavy lifting. The description confirms the fan-out return shape but adds no field-level meaning (e.g. how p1/p2 versus event_rate/hazard_ratio select an analysis path) beyond what the schema states. Baseline 3 is appropriate.

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 the specific phrase 'Full research protocol generation' and enumerates the contents it produces (sample size, statistical plan, ethics points). It does not name a sibling such as wetlab_protocol_generate or topic_research_plan to distinguish itself, but the clinical 14-section protocol scope is stated well enough for an agent to recognize the job.

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?

'USE WHEN: the user wants a complete research protocol including sample size, statistical plan and ethics points' gives a clear trigger condition, and the ALIASES list helps match colloquial phrasing. There is no explicit when-not/alternative guidance (e.g. deferring to a single-section tool or to a lab-protocol sibling), so usage is clear but not fully routed.

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

All SanYu Research Engine toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources