Loading ToolBench

Reading the current corpus…

projektor MCP server · F · ToolBench

← Browse

projektor

github.com/TAJD/projektor

A project management and workflow coordination platform with MCP server capabilities for tool integration

2026-07-28+STREAMABLE_HTTP1 tools

47/100

Definition Quality38

Protocol Readiness65

Supportability49

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

Single tool 'github_link_pr' has a complete JSON Schema with 4 required parameters (issueId, prUrl, prNumber, repo), all typed as strings or numbers. However, the tool description is minimal (18 chars: 'Link a GitHub pull request to an issue'), falling below the 20-char threshold. No parameter descriptions are visible in the schema, each param lacks a 'description' field explaining its purpose, format, or constraints. No error handling guidance, no output schema documentation, and no indication of idempotency or side effects despite being a WRITE operation.

Tools (1)

github_link_prwriteauthsource verified38/100

Link a GitHub pull request to an issue

Issues (5)

CRITICALtool-description ↗

Tool description is 18 characters, below 20-char minimum. Provides no context for LLM selection or when to use the tool.

github_link_pr

CRITICALtool-description ↗

No parameter descriptions in schema. LLMs cannot infer what 'issueId', 'prUrl', 'prNumber', 'repo' mean or what format they expect (e.g., is issueId a number or string? Is prUrl a full GitHub URL or a short reference?).

github_link_pr

HIGHresponse-shaper ↗

No output schema documented. LLMs do not know what the tool returns (success/failure, linked PR ID, confirmation message, etc.), preventing downstream tool chaining.

github_link_pr

HIGHrecovery-guide ↗

WRITE operation with no error handling guidance. No indication of what happens on failure (PR already linked? Issue not found? Repo access denied?), forcing LLM to guess recovery steps.

github_link_pr

Recommendations

Expand tool description to 50 - 150 characters explaining WHAT it does, WHEN to use it, and what it returns. Example: 'Link a GitHub pull request to an issue to track related work. Returns success status and the linked PR reference. Use after creating a PR to associate it with an existing issue.'
Add 'description' field to each parameter: issueId ('The GitHub issue ID or number to link to'), prUrl ('Full GitHub PR URL, e.g., https://github.com/owner/repo/pull/123'), prNumber ('The PR number within the repo'), repo ('Repository in owner/name format, e.g., TAJD/projektor').
Document the output schema with fields like { success: boolean, linkedPrId: string, message: string, issueId: string } so LLMs know what to expect and can chain to downstream tools.
Add error handling guidance: 'If issue not found, call search_github_issues() first. If PR already linked, returns error, check existing links before retrying.'
Clarify idempotency: 'Calling this tool twice with the same parameters is safe, it returns the existing link without creating a duplicate.'

Score history

Overall score trend

First recorded score · v2 rubric

47/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	47	2026-07-28+	v2