repo-pulse-mcp

Overview Schema Source Related Servers Discussions Admin

Knowledge map

knowledge_map

Read-onlyIdempotent

Identify who knows a file or directory best from Git commit history, weighted by recency. Shows author knowledge shares, bus factor, and files at risk from a single contributor.

Instructions

Who knows a file or directory: each author's share of the knowledge, from the commits they made in the last N days (merge commits excluded), with recent commits weighted more. Also returns the bus factor and how many files depend on a single person. Useful for "who should review this?" and "who knows the auth module best?".

Input Schema

Name	Required	Description
`days`	No	Time window in days.
`path`	No	Restrict to this file or directory.
`repo`	No	Repo name or path; defaults to the first configured repo.
`limit`	No	Maximum number of results.
`exclude`	No	Globs to leave out, as in file_hotspots.
`halfLifeDays`	No	A commit counts half as much for every this many days of age.
`maxFilesPerCommit`	No	Skip commits touching more files than this (bulk renames, formatting).

Output Schema

Name	Required	Description
`path`	Yes	The requested file or directory, or null for the whole repo.
`repo`	Yes	Name of the repository that was queried.
`files`	Yes	Most frequently changed files first.
`authors`	Yes
`busFactor`	Yes	Fewest authors who together hold more than half of the knowledge.
`windowDays`	Yes
`halfLifeDays`	Yes
`filesAnalyzed`	Yes
`scanTruncated`	Yes
`commitsScanned`	Yes
`commitsSkipped`	Yes	Commits ignored for touching more than maxFilesPerCommit.
`concentratedFiles`	Yes	Files where a single author holds at least 80% of the knowledge.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Oct 19, 2026

TDQS

A4.2/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), but the description adds real methodology: merge commits excluded, recency weighting, bus factor, and files depending on one person. It doesn't disclose cost/performance characteristics of a potentially long commit scan, which is the only notable 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?

Two tightly packed sentences with zero filler: the first defines the computation and its exclusions/weighting, the second names the outputs and use cases. Front-loaded with the core answer rather than preamble.

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?

With an output schema present, return values need no explanation, and all seven parameters are schema-documented. What's missing is only marginal: no note on result limits/pagination behavior or the default-repo fallback, both of which an agent relies on the schema for.

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 every parameter including days, halfLifeDays, and maxFilesPerCommit is already documented in the schema. The description restates the time-window and weighting concepts but adds no syntax or format detail beyond it, so the baseline 3 applies.

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?

Specific verb+resource with scope spelled out: per-author share of knowledge for a file/directory, plus bus factor and single-person dependency count. It is clearly distinguishable from siblings like contributor_summary and file_hotspots, which the description implicitly disambiguates through its per-path focus.

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?

It names two concrete decision contexts ('who should review this?' and 'who knows the auth module best?'), which tells the agent when this tool is the right call. It stops short of stating when-not to use it or naming an alternative sibling explicitly.

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

Deploy Server