repo-pulse-mcp

by hasanyelaldi

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Release notes draft

release_notes_draft

Read-onlyIdempotent

Generate release notes or structured sections by grouping commits between two refs by conventional-commit type.

Instructions

Group commits between two refs by conventional-commit type (breaking changes, features, fixes, ...) as a Markdown draft, or as structured sections. "from" defaults to the latest tag before "to"; without any tag, all commits up to "to" are used. To draft notes for an existing release, pass its tag as "to" (see list_tags).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "release_notes_draft"
  }
}

Input Schema

Name	Required	Description	Default
`to`	No	End ref, inclusive.	HEAD
`from`	No	Start ref, exclusive (tag, branch or commit).
`repo`	No	Repo name or path; defaults to the first configured repo.
`format`	No	"markdown" for a ready-to-paste draft, "sections" for structured data.	markdown

Output Schema

Name	Required	Description
`to`	Yes
`from`	Yes	Start ref (exclusive); null means from the first commit.
`repo`	Yes	Name of the repository that was queried.
`markdown`	No	Present when format is "markdown" or "both".
`sections`	No	Present when format is "sections" or "both".
`truncated`	Yes
`commitCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.5.0Oct 19, 2026

addedInput schema / properties / format

Added value: +{
+  "default": "markdown",
+  "description": "\"markdown\" for a ready-to-paste draft, \"sections\" for structured data.",
+  "enum": [
+    "markdown",
+    "sections",
+    "both"
+  ],
+  "type": "string"
+}

changedInput schema / properties / repo / description

Previous value: -"Repository name or absolute path from the allowlist. Defaults to the first configured repo."New value: +"Repo name or path; defaults to the first configured repo."

addedOutput schema / properties / markdown / description

Added value: +"Present when format is \"markdown\" or \"both\"."

addedOutput schema / properties / sections / description

Added value: +"Present when format is \"sections\" or \"both\"."

changedOutput schema / required

Previous value: -[
-  "repo",
-  "from",
-  "to",
-  "commitCount",
-  "truncated",
-  "sections",
-  "markdown"
-]New value: +[
+  "repo",
+  "from",
+  "to",
+  "commitCount",
+  "truncated"
+]

First observedv0.2.0Oct 17, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add the behavior that actually matters: how the ref range resolves by default and what happens when no tag exists. It does not mention pagination or size limits on potentially large commit ranges, which is the remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, tightly front-loaded with the core action and output modes, then the defaulting rule, then the concrete use case. Every sentence earns its place with no filler.

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?

An output schema exists, so return structure needs no explanation, and all four parameters are schema-documented. The description covers defaults, modes, and the release-drafting workflow; only edge cases like empty ranges or oversized histories are unaddressed.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics the schema lacks: the default resolution rule for 'from' (latest tag before 'to', else all commits up to 'to'), which is not expressed in the schema's parameter descriptions. It also clarifies the practical role of 'to' for existing releases.

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?

States a specific verb+resource (group commits between two refs into a release-notes draft) with the grouping axis (conventional-commit type) and both output modes. This is clearly separable from siblings like commit_search, compare_refs, and list_tags at a glance.

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?

Gives the key usage path: defaulting behavior of 'from', the no-tag fallback, and the specific case of drafting notes for an existing release by passing its tag as 'to', with a pointer to list_tags. It does not explicitly say when to prefer compare_refs or commit_search over this tool, so it stops short of full alternative routing.

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

Deploy Server