Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@crc-lnm-medical-agent verify MCP initialization and list tools"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
这是面向 ModelScope 托管 STDIO 的完整懒加载纯 NumPy 单模型版本。一个 console script、一个进程内注册六个医学工具；initialize 和 tools/list 不读取模型参数或展开病例。第一次 crc_lnm_predict_multimodal 调用校验并加载唯一的 seed_2024 NumPy runtime asset，后续预测复用同一实例。默认安装不依赖 PyTorch、NVIDIA 或 CUDA 包。
{
"mcpServers": {
"crc-lnm-medical-agent": {
"command": "uvx",
"args": [
"crc-lnm-medical-agent@1.0.12"
]
}
}
}ModelScope 中选择托管部署和 STDIO；command 填 uvx，args 只填上面一个带版本参数。不要增加 URL、host、port、transport 参数或环境变量。
Related MCP server: my-mcp-server2
powershell -ExecutionPolicy Bypass -File scripts/release_verify_full.ps1六工具为模型信息、病例质控、CT 特征准备、病理特征准备、单模型预测和报告生成。内置病例仅为合成演示资源；本包只用于科研辅助，不构成诊断，所有输出均需专家复核。
Describe the deliberately limited behavior of this deployment stage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It hints at 'deliberately limited behavior' but does not explain what those limits are, nor does it describe side effects, permissions, or output characteristics. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It is highly concise and front-loaded, stating the action and target immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a zero-parameter tool with an output schema, but the cryptic phrase 'deliberately limited behavior' is unexplained. It could be more complete by clarifying what the description includes or excludes, especially since no usage or alternative context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with an empty properties object. Since there are no parameters to describe, the 0-param baseline of 4 applies, and the description need not add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'describe' with a specific resource (the deployment stage's behavior), making its core purpose clear. It distinguishes from the sibling healthcheck by focusing on description rather than health status, though the phrase 'deliberately limited' adds ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling healthcheck tool. The description only states what it does, not under what conditions it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the installed package identity and canary transport profile.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. The verb 'report' implies a read-only operation, but it does not explicitly state safety, side effects, permissions, or other behavioral traits. The one-liner adds minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the action 'Report' and clearly states the resources. It is concise with no unnecessary information, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and an output schema, the description leaves gaps in usage guidelines and behavioral transparency. It provides the essential purpose but lacks guidance on when to use the tool or what behavioral impacts it might have, making it minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to describe. The baseline of 4 applies, and the description does not need to add parameter details. The empty schema already confirms the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'report' and the resource 'installed package identity and canary transport profile.' It distinguishes itself from the sibling tool describe_deployment by focusing on identity and canary transport rather than deployment details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus describe_deployment or any other alternative. It lacks context about appropriate scenarios, prerequisites, or exclusions, providing no decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.11describe_deploymenthealthcheckScored across 2 tools
The two tools are clearly distinct: one reports health/status information, the other describes the deployment's behavior. There is no overlap in their purposes.
Naming styles are inconsistent: 'healthcheck' is a single word noun, while 'describe_deployment' follows the verb_noun snake_case pattern. This lack of a consistent convention makes the set feel uncoordinated.
With only two tools, the set is on the thin side, but the explicit mention of a 'deliberately limited behavior' suggests this small count is intentional for a staging environment. Still, it is borderline for a typical server.
Despite the server name indicating a medical agent, the provided tools only cover operational metadata (healthcheck and deployment description) with zero medical domain functionality. The surface is severely incomplete for any meaningful medical workflow.
Security research: MCP registries verify identity, not tool behavior. See gtfo.dev.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Security research canary remote MCP server for owned-account testing.