t-rush-mcp

by DevDs1989

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.10
Disambiguation4/5
Most tools have clearly distinct purposes: find_todos ranks priorities, scan_todos_raw returns an unranked list, search_todos does fuzzy searches, resolve_todo marks completion, and get_streak_status/aggregate_debt handle stats. The main potential confusion is between find_todos and scan_todos_raw, as both scan for TODOs, though the ranking distinction helps.
Naming Consistency4/5
All tool names use lowercase snake_case with leading verbs (find, resolve, scan, search, get, aggregate), forming a consistent pattern. Minor deviations exist: resolve_todo is singular while most others are plural, and scan_todos_raw appends 'raw' as a modifier, slightly breaking the simple verb_noun structure.
Tool Count5/5
Six tools are well-scoped for a tech debt tracking server. Each tool serves a distinct aspect—scanning, ranking, searching, resolving, streak stats, and cross-repo aggregation—so the count feels appropriate without being sparse or bloated.
Completeness4/5
The tool surface covers the core lifecycle: scanning and ranking TODOs, searching for specific items, resolving them, and tracking streaks across repositories. Minor gaps exist, such as no ability to reopen a resolved TODO or add a TODO, but these are acceptable limitations for a tech debt scanner.
Average 3.7/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 49 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It states the data source ('shared local store') and the verb 'Get' implies read-only, but it does not explicitly confirm safety, side effects, or return behavior. This is insufficient transparency for a tool with no annotations.
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?
The description is a single, clear sentence that is front-loaded with the action and resource. It contains no redundant words or filler.
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?
For a simple no-parameter tool, the description gives the basic purpose but lacks details about what 'stats data' includes or the return format. Since there is no output schema, the description should provide more context about the response, which it does not.
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?
The tool has zero parameters, and the schema has an empty properties object (coverage 100%). With no parameters to document, the baseline is 4, and the description does not need to add parameter details.
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 uses the verb 'Get' and specifies the resource as 'current streak and stats data' from the 'shared local store'. It clearly distinguishes from sibling tools that focus on todos and debt, though 'stats data' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context or exclusions, leaving the agent without information on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavior disclosure. It only restates the purpose ('returns the full unranked list') without detailing output format, potential performance implications, or why it's marked internal. This is a significant gap for an unannotated tool.
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?
The description is one short sentence with no filler. The 'Internal/manual use' prefix is a useful, concise qualifier. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema, and the description doesn't explain what the list contains (file paths, line numbers, snippets) or how directory_filter affects the result. For an internal/debugging tool, an agent would likely need more detail to use it correctly. Completeness is insufficient.
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?
The input schema covers 100% of parameters with descriptions, so the schema does the heavy lifting. The description adds no new parameter semantics beyond implying the result is 'full' and 'unranked', which may hint at directory_filter behavior but is ambiguous. Baseline of 3 is appropriate.
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 clearly states the verb ('returns'), resource ('full unranked list of TODOs in a repo'), and scope ('in a repo'). The term 'full unranked' helps distinguish it from sibling tools like search_todos or find_todos, though it doesn't explicitly name an alternative.
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?
The prefix 'Internal/manual use' provides clear context that this tool is not intended for normal AI workflows, implying it should be used sparingly or for debugging. While it doesn't list explicit alternatives, the manual/internal tag effectively communicates when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not state whether the operation is read-only, what side effects might occur, performance implications, or the shape of the returned data. The wording 'aggregate' suggests read-only but it is not explicit.
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?
The description is a single, front-loaded sentence of nine words with no filler. Every word contributes to conveying the core purpose, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what 'debt' and 'streak views' mean in terms of return values and any limitations. It omits these details, making it incomplete for an agent to invoke without making assumptions about output format and behavior.
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?
Only one parameter 'paths' exists, and schema description coverage is 0%. The description's phrase 'across multiple local repositories' implies that 'paths' contains the repository paths, but it does not explicitly map the parameter or specify path details (e.g., relative/absolute). It adds partial meaning but does not fully compensate for the lack of schema docs.
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?
The description uses the specific verb 'aggregate' with clear resources 'debt and streak views' and specifies the scope 'across multiple local repositories'. It distinguishes from sibling tools like find_todos or get_streak_status by focusing on multi-repo aggregation rather than individual TODO ops.
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?
The description gives clear context for when to use the tool (aggregating debt/streak data across multiple repos) but does not explicitly mention alternative tools or exclusion criteria. This meets the bar for clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key side effects (verification and streak increment) but omits important details like whether the file is modified in-place, what happens if the TODO isn't found, or any permission requirements. The description adds some value but is not comprehensive.
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?
The description is a single concise sentence that front-loads the main action and includes two important behavioral notes. Every word earns its place; no wasted or redundant information.
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?
The tool is a mutation with no annotations and no output schema, so the description needs to explain return values and failure modes, which it doesn't. It captures the core behavior but misses edge cases (e.g., TODO not found) and the relationship between 'TODO' and the type enum. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with file described as 'File path to verify' and type having only an enum. The description does not explain the enum values or how they map to different todo types; it only says 'TODO' generically, which could mislead since type supports FIXME, BUG, etc. This narrows the tool's scope and doesn't clarify parameter semantics.
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?
The description clearly states the action (mark as resolved), the resource (TODO), and additional behavior (verification and streak increment). This distinguishes it from sibling read/search tools (find_todos, scan_todos_raw, search_todos) which focus on listing or searching.
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?
The description implies when to use the tool (when you want to resolve a TODO) and the contrast with sibling search tools is evident from context. However, there are no explicit exclusions or alternative tool mentions, so it doesn't fully meet the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that searches are fuzzy and intent-based, but does not state whether the tool is read-only, what it returns, or any side effects. This is a moderate gap for a search tool.
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?
The description is concise with two sentences: a critical instruction and a clear behavior statement. The all-caps 'CRITICAL INSTRUCTION' is slightly emphatic but not wasteful; the text is well structured and front-loaded.
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?
For a tool with no output schema and no annotations, the description should explain return values and limitations. It mentions fuzzy/intent matching but does not describe result format, error behavior, or performance, leaving the context partially incomplete.
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?
The input schema has 100% coverage for all three parameters (cwd, query, directory_filter) with clear descriptions. The tool description adds no additional parameter semantics, so it matches the baseline for full schema coverage.
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?
The description clearly states it searches for specific TODOs, FIXMEs, or BUGs using fuzzy matching by intent. It explicitly says to use this instead of generic Search or grep_search, distinguishing it from generic alternatives.
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?
The description gives explicit when-to-use guidance: 'ALWAYS use this tool instead of generic Search or grep_search when looking for a specific TODO, FIXME, or BUG.' However, it does not mention when to use sibling tools like find_todos or scan_todos_raw, so it lacks a complete exclusionary set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It reveals that the tool scans the entire repo, ranks by age, and returns top items. Also imposes an agent-side rule to not list items in chat. However, it does not detail any side effects, permissions, or output format, leaving some ambiguity.
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?
Description is longer but front-loaded with the critical instruction, and every sentence serves a purpose. The all-caps emphasis and workflow steps are somewhat verbose but structurally justified.
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?
For a scan tool with no output schema, the description explains what it returns and the expected follow-up, but lacks specifics on return structure or alternative tools. It is sufficiently complete for the agent to execute, though not exhaustive.
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?
Input schema covers all 3 params with descriptions, so description adds no additional parameter meaning. Baseline 3 is appropriate given the high schema coverage.
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 it finds TODOs, FIXMEs, BUGs, and priorities by scanning the repo, ranking by age, and returning highest priority items. Clearly distinguishes from siblings like resolve_todo and search_todos by claiming to be the primary tool.
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?
Explicitly instructs the agent to ALWAYS use this tool for finding tech debt, and outlines a mandatory follow-up workflow (create artifact, request feedback). Does not mention when to use alternatives like scan_todos_raw, but the directive is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![trush-mcp MCP server](https://glama.ai/mcp/servers/DevDs1989/trush-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DevDs1989/trush-mcp)

Score Badge

Copy to your README.md:

[![trush-mcp MCP server](https://glama.ai/mcp/servers/DevDs1989/trush-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DevDs1989/trush-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DevDs1989/trush-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server