deltaprobe
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | A GitHub token. Optional for reading public repos, but raises the rate limit from 60 to 5,000 requests/hour and enables private repo access. `post_review_comment` requires a token with Pull requests: Read and write permission. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_open_prsA | List open pull requests in a GitHub repository, most recently updated first. Use this to find which PR to review. |
| summarize_prA | Get an overview of a pull request without its diff: title, description, author, branches, labels, size, file types (source/test/docs/config/generated), most-touched areas, review status and CI check results. Call this first when reviewing a PR, then use get_pr_diff to read the code. |
| get_pr_diffA | Get the changed files and unified diff hunks of a pull request. Patches are trimmed to whole hunks within a character budget; lock files and build output are skipped. Every file is listed, and files without a patch have an 'omitted' reason. If 'truncated' is true, call again with 'files' to read specific files in full. |
| check_pr_riskA | Run rule-based risk checks on a pull request: possible secrets in added lines (masked), sensitive files, large diffs, source changes without tests, CI workflow, migration and dependency changes, and leftover debug code. Returns an overall level (none/low/medium/high) and findings with file and line where possible. These are heuristics: confirm each finding by reading the code with get_pr_diff before reporting it. |
| post_review_commentA | Post a review on a pull request: an overall summary plus optional inline comments on specific lines. Inline comments must target lines in the PR's diff (RIGHT = new version, LEFT = removed lines); they're all checked first, and nothing is posted if any is invalid. Defaults to a neutral COMMENT review. Use dryRun to preview. Requires a GITHUB_TOKEN that can write to pull requests. Only post when the user has asked you to. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a distinct stage of PR review: listing (list_open_prs), overview metadata (summarize_pr), code content (get_pr_diff), heuristic risk scanning (check_pr_risk), and writing feedback (post_review_comment). Descriptions explicitly state sequencing and warn against confusing heuristics with actual code reading, leaving no ambiguity.
All five names follow a consistent snake_case verb_noun pattern (list_, get_, summarize_, check_, post_) with a shared 'pr' domain noun. No mixed conventions or vague verbs.
Five tools map cleanly onto a coherent review workflow with no redundancy or filler. Each tool covers a necessary and non-overlapping step from discovery to posting a review.
The surface covers the core review lifecycle: discover PRs, understand them, read diffs, assess risk, and post comments with inline feedback. Minor gaps remain around reading existing review threads/replies and retrieving CI log details, but agents can work around these.