Skip to main content
Glama

检查初学者能不能跟着读

audit_structure

Checks a Notion page for missing key-point callouts, skipped step numbers, and derivations hidden as obvious or omitted. Reports structural issues without editing pages or judging content accuracy.

Instructions

规则检查:重点和考点有没有用小图标或提示框标出、步骤编号有没有跳步、有没有用「显然 / 略」跳过推导。不强制双语。只报告,不改页面。不判断内容对错。

Input Schema

NameRequiredDescriptionDefault
pageIdYes页面 id 或页面 URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose the key traits — read-only, report-only, no page mutation, and no judgment of content correctness. It says nothing about the shape of the report, what happens on an unreachable page id, or whether a rendered page vs. source is required, which leaves real gaps for a tool with zero structured annotations.

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?

Front-loaded with the category label ("规则检查:") followed by the concrete checks, then two short scope constraints. Nearly every clause earns its place, though the dense enumeration takes a second read to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only audit with no output schema, the description covers what is checked and what the tool will not do, which is the core need. It is still incomplete on report format and on routing among the several audit/scan siblings.

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?

Only one parameter, pageId, and the schema already documents it at 100% coverage ("页面 id 或页面 URL"), so the baseline is 3. The description adds no extra meaning about the parameter (e.g., which page versions are addressable), so it does not exceed the baseline.

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 gives a concrete, enumerable rule set (icon/callout marking, step-number gaps, use of 「显然/略」 to skip derivations) that makes clear this audits page structure for beginner readability. The verb+object is only implicit ("规则检查" plus a list), and it never names how it differs from audit_page, audit_formulas or scan_layout_rules, so not a 5.

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

Usage Guidelines3/5

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

"只报告,不改页面" and "不判断内容对错" set useful negative boundaries (read-only, not a correctness review), which steers the agent away from misuse. But it never states when to choose this over audit_page or scan_layout_rules, so usage is only implied rather than directed.

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