sync_egovframe_catalogVerify official eGovFrame common-components tag, commit, and archive integrity, and check upstream changes plus sec.security package updates against a pinned catalog.
공식 egovframe-common-components 태그·commit·아카이브 무결성을 검증하고, 고정 카탈로그 대비 upstream 변경과 sec.security 보안 패키지를 점검합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | 확인할 태그·브랜치·commit. 미지정 시 카탈로그의 공식 고정 태그 사용 |
Changes observed during successful MCP inspections.
v1.6.0Input schema / additionalPropertiesRemoved value: -falsev0.21.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint/idempotentHint, so safety is covered; the description adds substantive scope detail beyond them — that it validates tag/commit/archive integrity of an official upstream source and also inspects the sec.security package. It does not describe what artifacts or findings come back, which keeps it below a 5.
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?
One front-loaded sentence covering three checks, with no filler. It is dense but every clause (integrity verification, upstream diff, security package) adds distinct information.
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?
For a read-only, one-optional-parameter tool with full schema coverage and no output schema, the description covers scope, source of truth, and default behavior adequately. What is missing is the form of the returned findings and any mention of network/prerequisite requirements for the upstream comparison.
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 coverage is 100% and the single optional 'ref' parameter is already documented in the schema, including the default of the pinned tag. The description reinforces the default behavior (고정 카탈로그 대비) but adds no syntax or format detail beyond the schema, so baseline 3 applies.
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 concrete verb (검증하고/점검합니다) and a precisely named resource (공식 egovframe-common-components 태그·commit·아카이브) rather than a restatement of the name. It clarifies that the tool works against a pinned catalog comparison and sec.security package, which separates it from catalog-listing and template-sync siblings, though it never names those siblings.
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 explicit guidance on when to use this versus the siblings like sync_egovframe_templates or list_egovframe_components, and no exclusion of scenarios (e.g., pre-upgrade checks vs. routine validation). Usage is only inferable from the purpose statement, and the 'sync' name could mislead against sync_egovframe_templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.