Skip to main content
Glama

launch_uvision

Launch Keil uVision with a project file to prepare for debugging, reusing an existing window by default and enforcing a single instance unless multiple are explicitly requested.

Instructions

可见方式启动 Keil uVision 并打开工程,供人工查看界面 / 调试准备。project 为 .uvprojx 路径,可省略以用默认工程。reuse(默认 true):已有打开同一工程的 Keil 窗口时复用该窗口并前置,不新开——真机实测 UV4.exe 并非单实例程序,反复调用本工具会累积出多个同工程窗口(曾达 6 个),因此默认复用;确需第二个窗口时才传 reuse=false。single(默认 true)=「只保留一个 Keil 窗口」的执行者:已经开着别的工程的窗口时直接拒绝(error_code=keil-multiple-instances,返回 open_instances 与下一步),不做「偷偷关掉再开」;已经开着同工程窗口时强制复用(reuse=false 也被否决,返回 reuse_forced=true);本次没给 project 且已有实例同样拒绝(无从比对就不猜)。确实要同时开多个窗口才传 single=false。返回值含 reused / pid / instances(当前同工程窗口数)。用户无需手动打开 Keil,AI 可通过本工具拉起;想看当前开了几个窗口用 list_uvision_instances,想把多余的收掉用 close_uvision(keep="latest")。uvsock_port:传端口号则给这次启动加官方开关 -s <端口>,让新实例在该端口上开 UVSOCK——当用户的 Keil 里 UVSOCK 没打开/端口被改过时,光拉起 Keil 仍连不上,这个参数能一步到位(注意 MCP 服务自身的 UVSOCK 端口也要一致)。no_layout=true 加 -sg 禁用 uvguix 布局文件:用户改过窗口布局、布局文件损坏导致 UV4 起得极慢或报错时用它绕开。 【参数】必填: 无;可选: project, reuse, uvsock_port, no_layout, single 【调用示例】{} 【风险】中——会改变目标状态或占用共享资源(调试态/串口/Keil 实例),必要时可回退。 【参数别名】project ← path/proj/project_file/project_path/uvprojx。规范名以上方【参数】行为准;未列出的参数名会被拒绝,不会静默忽略

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reuseNo
singleNo
projectNo
no_layoutNo
uvsock_portNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A5/5.0
Behavior5/5

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

Goes well beyond annotations: discloses that UV4.exe is not single-instance, repeated calls accumulate windows (observed up to 6), explains default reuse behavior, single-mode rejection logic with error_code and return fields (reuse_forced, instances), and the medium risk of changing target state or occupying shared resources. Annotations only provide flags; this gives concrete side effects and safeguards.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long, every sentence adds critical detail: purpose is front-loaded, then parameter semantics, return values, alternatives, risk, and aliases. Bold and structured formatting aid scannability. The empty call example is harmless and not redundant.

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 tool with 5 optional parameters, no required params, no schema descriptions, and non-trivial multi-instance behavior, the description covers all parameter semantics, defaults, return values (reused/pid/instances), error behavior, risk, and prerequisite caveats (uvsock port alignment). It is self-sufficient for an agent to select and invoke correctly.

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

Parameters5/5

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

Schema coverage is 0%, so description fully compensates: each parameter (project, reuse, single, uvsock_port, no_layout) is explained with its default, purpose, and concrete effect (uvsock_port adds `-s <port>`, no_layout adds `-sg`). Also documents parameter aliases and that unlisted parameter names are rejected.

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?

Description states a specific action ('launch Keil uVision and open project visibly for manual UI viewing/debug preparation'), names the resource (.uvprojx project), and distinguishes itself from siblings like list_uvision_instances and close_uvision which are for inspecting and closing windows, not launching.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'AI can launch via this tool', and routes to alternatives: 'to see how many windows are open use list_uvision_instances, to clean up excess use close_uvision(keep="latest")'. Also details precise conditions for reuse=false, single=false, uvsock_port, and no_layout.

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