Skip to main content
Glama

环境自检与调试工作流引导

mdk_guide
Read-onlyIdempotent

Run a read-only environment self-check for Keil/UVSOCK/UV4/.axf and source drift, then receive recommended debug workflow and scene-specific tools to prevent blind trial-and-error.

Instructions

AI 落地的第一个工具:一键自检 Keil/UVSOCK/UV4/.axf/源码漂移/调试态/RTOS 类型,并返回推荐的调试工作流与各场景应调用的工具,避免 AI 盲目试错。返回 {environment:{...}, recommended_workflow:[...], scene_tools:{...}}。注意:建议 AI 落地第一件事先调本工具获取环境自检与工作流,再按场景选择工具;自检为无副作用只读操作,可在任意时刻调用。topic=tool, name=<工具名> 取回该工具被挪出上下文的完整说明(为省上下文,长描述在工具列表里只留一句话摘要,正文全文存在这里);topic=tool 不带 name 则列出全部已归档工具与描述档位。 【输出控制】本工具返回体可能较大,额外接受三个可选参数:compact=true(精简)/ max_lines=N(限制列表条数)/ full=true(强制全量)。默认都不传=行为不变;被裁掉的内容一定会在返回体的 output 字段里如实上报(truncated/dropped/trimmed/hint),不会静默丢数据。也可用环境变量 MDKDEBUG_COMPACT=1 / MDKDEBUG_MAX_LINES=N 设全局默认。 【参数】必填: 无;可选: topic, name, compact, max_lines, full 【调用示例】{}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNo强制返回全量:忽略 compact/max_lines 与对应环境变量的默认值。当上面两项让你只看到部分数据、而你要据此下结论时,用它取回完整结果。
nameNo
topicNo
compactNo精简返回体:去掉空值字段,把列表元素中取值完全相同的字段提到 output.shared,并把 usage/note/hints 之类**说明性**长文本截断到 200 字符(数值与内容字段不动)。被裁掉的东西都会列在 output 里,绝不静默丢弃。不传则不改行为(受 MDKDEBUG_COMPACT 影响)。
max_linesNo限制返回的列表条数(只作用于元素为对象的列表,如 results/items/tools):最多 N 条,其余丢弃并在 output.truncated/dropped/hint 里如实上报。0 或省略=不限(受 MDKDEBUG_MAX_LINES 影响)。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only and idempotent. The description adds concrete behavioral details beyond annotations: it mentions that the return body may be large, that truncation reports dropped/trimmed/hints without silent loss, and that it can be called at any time without side effects. This enriches the safety and operational context.

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 long but well-structured with explicit sections (【输出控制】,【参数】,【调用示例】). It front-loads the core purpose in the first sentence and avoids redundancy. The length is justified by the tool's complexity, and the information is compactly organized without redundant padding.

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?

Given the tool's complexity (5 optional params, rich output, truncation logic), the description covers the essential use cases, parameter behavior, output fields, and environment variables. An output schema also exists, reducing the need to describe return types. Minor gaps like error handling are acceptable for a well-scoped guide tool.

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

Parameters4/5

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

The description explains all five parameters in prose (topic, name, compact, max_lines, full) including usage examples and the behavior of environment variables. Since schema coverage is only 60% and name/topic lack schema descriptions, the description compensates well, explaining the semantics of topic=tool with and without name.

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 states a specific verb+resource: it performs environment self-check and returns a recommended debug workflow plus scene-specific tools. It clearly differentiates itself from sibling tools by focusing on the diagnostic/workflow guidance, not just a single check (env_check) or viewer (view_guide).

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 explicitly advises to call this tool first as an AI landing step, before selecting other tools. However, it does not name alternative tools or give explicit 'when not to use' conditions. The instruction is clear but lacks comparative routing against specific siblings.

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