classdojo_verify_skill_syncCompare current target skills against preset, class, or inline rule lists to identify differences before syncing. Verify skill alignment without modifying any data.
Compares current target skills with a preset, source class, or inline rule list without changing data.
| Name | Required | Description | Default |
|---|---|---|---|
| rulesSource | Yes | ||
| targetClassNames | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so 'without changing data' adds no new safety information. The description clarifies that verification means comparing current skills against one of three sources, but this largely restates the rulesSource oneOf in the schema; no side effects, return behavior, or error conditions are disclosed.
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?
A single 16-word sentence contains the core verb, scope, sources, and a safety guarantee. No filler or redundancy.
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 tool has no output schema, so the description should describe the comparison result format, but it doesn't. It also leaves targetClassNames semantics and the distinctions among verify/preview/apply implicit, making the definition incomplete for a moderately complex nested-parameter tool.
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?
Schema description coverage is 0%, so the description must compensate. It names the three rulesSource variants but doesn't explain targetClassNames (the classes whose skills are checked) or the inner structure of inline skills (category/name/points/iconId). The oneOf details and targetClassNames pattern are left entirely to the schema.
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 a clear verb ('compares') and resource ('current target skills') and explicitly names the three comparison sources (preset, source class, inline rule list). This distinguishes it from mutation-oriented siblings like classdojo_apply_skill_sync and roster-focused tools like classdojo_verify_roster_against_workbook.
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 read-only note ('without changing data') implicitly separates it from apply_skill_sync, but the description never names alternatives or states when to prefer verify over preview_skill_sync. Usage context is implied rather than explicit, so an agent must infer the choice from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.