Skip to main content
Glama
dcd887

mc-changelog-mcp

generate_text_summary

Generates a concise plain-text changelog from old and new modpack directories, producing copy-ready change notes for Discord, forums, or group chats.

Instructions

生成简洁的纯文本格式变更记录,适合复制粘贴到 Discord/论坛/群聊

Input Schema

NameRequiredDescriptionDefault
new_versionNo新版本标签
old_versionNo旧版本标签
new_pack_dirYes新版本整合包根目录路径
old_pack_dirYes旧版本整合包根目录路径

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.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 full behavioral burden. It usefully discloses the output format (concise plain text, copy-paste ready), which matters because there is no output schema. It does not say whether it only compares/reads the two pack dirs or persists anything (save_changelog exists as a sibling, implying this one does not save), nor how expensive the comparison is.

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?

A single front-loaded sentence with zero waste. It is appropriately sized but also thin — the brevity comes at the cost of the routing and behavior detail an agent needs.

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?

Four parameters at full schema coverage and no output schema mean the description needn't document inputs or return values, and it does state the output format. What is missing for a tool sitting among four changelog/compare siblings is any explicit routing guidance or note that it is a read-only analysis versus a writer.

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?

Schema description coverage is 100%, so old_pack_dir, new_pack_dir, old_version, and new_version are already documented in the schema. The description adds no parameter-level meaning such as whether version labels are optional display strings or how paths are resolved, so the baseline 3 applies.

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 pairs a specific verb (生成/generate) with a specific resource (变更记录/changelog) and adds the output shape (简洁的纯文本格式), so an agent knows this produces a short text changelog rather than a full one. It implicitly contrasts with generate_full_changelog via '简洁' but never names the sibling, so differentiation is inferred rather than stated.

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?

'适合复制粘贴到 Discord/论坛/群聊' gives a concrete usage context, which implies when to pick this over a formal changelog. However, it names no alternatives and gives no when-not guidance, so choosing between this, generate_changelog, and generate_full_changelog is left to inference.

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