F
licenseNot graded
qualityB
maintenanceEnables AI agents to scan codebases for prioritized findings (TODO, FIXME, XXX) and retrieve results in table, JSON, or SARIF format via MCP.
Charlie Work
by Falcon305
Charlie Work is a code-health MCP server that scans, prioritizes, and tracks maintenance toil (technical debt) in your repository, integrating with AI agents and CI/CD pipelines.
Scan for toil (charlie_scan_toil): Detect flaky/skipped/focused tests, TODO rot, expiring TLS certs, dead feature flags, vulnerable/outdated dependencies, secret leaks, unpinned deps, unowned scripts, and stray debug statements. Findings are ranked by severity, effort, confidence tier (verified, high, heuristic), and a hotspot multiplier (churn × complexity). Detection uses real parsers (Python AST, tree-sitter) and authoritative data sources (OSV.dev, PyPI/npm/crates, real X.509 parsing).
Summarize toil budget (charlie_summary): Report total estimated remediation minutes, a debt ratio, and an A–E maintainability grade — inspired by Google SRE's "keep toil under 50%" guideline.
Triage top findings (charlie_triage): Return a prioritized top-N action plan of the most critical toil items for an agent or developer to work through.
Explain a specific finding (charlie_explain): Dive deep into a toil item by ID — evidence, why it's real debt, hotspot weight, owner, and a suggested fix.
Track toil over time (charlie_trend): Record budget snapshots and report deltas to observe whether technical debt is improving or degrading.
Record completed work (charlie_did_it): Log that someone cleared a piece of toil, persisting credit to a local ledger so invisible maintenance work becomes visible.
View the credit ledger (charlie_ledger): See who cleared what, the current "Champion of the Grease Trap," and how much toil remains open — ideal for standups and retros.
Generate automated patches: For auto-safe toil types (e.g., removing breakpoint()), the server can suggest ready-to-apply unified diffs without directly modifying files.
CI/CD integration: Can serve as a CI gate to block new high-severity toil and generate SARIF output. Output mode can be toggled between charlie (personality-flavored) and plain (paste-into-a-ticket clean).
Folds in open issues and PRs labeled with chore, tech-debt, or good-first-issue from a GitHub repository.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Charlie WorkScan this repo for toil and show the prioritized queue."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Charlie Work
A code-health tool that surfaces — and dignifies — the toil in your repo. An MCP server and a CLI and a CI gate.
The un-fun, load-bearing maintenance work everyone ignores until it bites: flaky tests, a TLS cert nine days from death, known-vulnerable dependencies, committed secrets, dead feature flags, TODO rot, scripts nobody owns. Charlie Work scans your repo with real parsers and real vulnerability data, ranks the findings by where your team actually bleeds time, and keeps a credit ledger so the invisible work finally shows up in standup.
Named after the episode where the gang realizes Charlie has been quietly holding Paddy's together the whole time.
THIS IS CHARLIE WORK. Nobody else will do it. That's why it's yours.
The jokes are a toggle, not a tax — pass mode="plain" (or set CHARLIE_VOICE=off) and every response is flavor-free, paste-into-a-ticket clean. CI and SARIF output are always plain.
Use it with any agent
Charlie is a stdio MCP server, so it drops into every MCP client — Claude Code, Codex, Cursor, VS Code, Claude Desktop, Windsurf, Zed, Gemini, Cline. The universal config is one block:
{
"mcpServers": {
"charlie-work": { "command": "uvx", "args": ["charlie-work-mcp"] }
}
}Don't hand-write it — let Charlie wire himself in:
uvx --from charlie-work-mcp charlie-work install --client cursor --write # or: codex, claude-code, vscode, …install knows each client's dialect and prints (or, for project-local clients, --writes) the exact config. Run install --client all to see every one.
Claude Code — claude mcp add --transport stdio charlie-work -- uvx charlie-work-mcp (or the block above in .mcp.json).
OpenAI Codex CLI — ~/.codex/config.toml:
[mcp_servers.charlie-work]
command = "uvx"
args = ["charlie-work-mcp"]Cursor (.cursor/mcp.json), Claude Desktop (claude_desktop_config.json), Windsurf, Gemini CLI, Cline — the universal mcpServers block above.
VS Code — .vscode/mcp.json uses servers (not mcpServers):
{ "servers": { "charlie-work": { "type": "stdio", "command": "uvx", "args": ["charlie-work-mcp"] } } }Zed — settings.json uses context_servers:
{ "context_servers": { "charlie-work": { "source": "custom", "command": "uvx", "args": ["charlie-work-mcp"] } } }Teach every agent the drill — write a Charlie section into AGENTS.md (the cross-vendor rules file read by Codex, Cursor, Copilot, Gemini, Aider, Windsurf, Zed; Claude reads it too):
uvx --from charlie-work-mcp charlie-work initAs a CLI:
uvx --from charlie-work-mcp charlie-work scan # the prioritized toil queue
charlie-work next # the single next best fix, as a patch
charlie-work fix --top 5 | git apply # patch the safe ones
charlie-work summary # toil budget + A–E gradeAs a CI gate — fail a PR only when it introduces new high-severity toil ("Clean as You Code"):
- uses: Falcon305/charlie-work-mcp@master
with:
severity: "4"As a scheduled watchman — some toil is time-based: a cert quietly ticks toward expiry, a TODO ages, a new CVE lands against a dep you already shipped. A nightly scan catches it before it pages you:
on:
schedule: [{ cron: "0 7 * * *" }]
jobs:
charlie:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: uvx --from charlie-work-mcp charlie-work sarif -o charlie.sarif
- uses: github/codeql-action/upload-sarif@v3
with: { sarif_file: charlie.sarif }Until the PyPI release lands, replace
uvx charlie-work-mcpwithuvx --from git+https://github.com/Falcon305/charlie-work-mcp charlie-work-mcp(and likewise--from git+…for the CLI).
Related MCP server: skillhub
Trustworthy detection (not regex theater)
Every scanner is backed by a parser or an authoritative data source, and every finding carries a confidence tier (verified / high / heuristic) so CI gates on facts, not guesses.
Kind | How it's detected |
| Lockfiles → OSV.dev (free, no key). Emits the CVE + the exact fixed version. |
| gitleaks-style provider regexes + Shannon-entropy gate + allowlists. |
| Python AST and tree-sitter (JS/TS/Go) — never matches a string or a comment. |
| AST calls: |
| Flags read but never set anywhere (the Pepe Silvia case), via AST literal extraction. |
| Real X.509 parsing — |
| Registry queries (PyPI/npm/crates/Go) → majors-behind. |
|
|
| Unpinned deps; operational scripts with no owner or CODEOWNERS. |
The difference from regex, in one line: the Python string "pytest.mark.skip" and a # breakpoint() comment are not flagged. Only real code is.
Where your team actually bleeds — hotspots + a toil budget
Charlie ranks by churn × complexity (CodeScene-style): debt in a file edited 40× this quarter outranks the same debt in one untouched for years. charlie-work summary rolls it into a toil budget — total remediation minutes, a SQALE-style debt ratio, and an A–E grade. Google SRE says keep toil under 50%.
Not just a reporter — a doer
Charlie returns patches, not prose. charlie_next hands the agent the single highest-value item — where it is, why it matters (hotspot × severity), and a ready-to-apply unified diff when it's safely fixable:
$ charlie-work next
breakpoint() left in the code at pay.py:88 — severity 4, in a hotspot (2.1x). [auto-safe]
--- a/pay.py
+++ b/pay.py
@@ -85,7 +85,6 @@
- breakpoint()Every patch is a diff you (or CI) apply with git apply — the server never edits your files. Fixes are labelled auto-safe (mechanical: delete a breakpoint()) or needs-review (changes behaviour: un-skip a test, delete a stale TODO). Secrets, certs, and dependency bumps are surfaced for a human, never auto-patched.
Tool | What it does |
| The single next best fix, as a patch + why + follow-up actions. |
| Unified-diff patches for a finding (or the top N), labelled auto-safe / needs-review. |
| Prioritized, paginated toil queue (structured output). |
| Toil budget: score, debt ratio, A–E grade. |
| Top-N action plan for an agent to work through. |
| Why a finding is debt — evidence, hotspot, owner, fix. |
| Records a snapshot and reports the delta over time. |
| The credit ledger — who cleared what, Champion of the Grease Trap. |
Plus toil://queue + toil://item/{id} resources and four prompts (slash commands in any client): triage_toil, fix_next, pre_pr_check, charlie_rules. Things a dashboard can't do: "fix the next thing, run the tests, and credit me in the ledger."
Not a toy: token discipline + evals
The heavy work happens server-side. An agent finding this toil itself would read the whole repo into context; Charlie returns only a compact ranked queue. The raw files never enter the model's context.
A reproducible eval harness (
evals/run.py) plants known toil and asserts the end state — recall and ranking — plus a token-cost measurement. There's also an optional model-graded tool-selection eval (evals/agentic.py).
$ uv run evals/run.py
kinds recalled : 9/9 (100% recall) top item is the cert : True
naive: read whole repo : 1881 tokens
charlie work queue : 1353 tokens → 28% fewer tokens
RESULT: PASSThat 28% is on a tiny fixture; the gap widens fast — naive cost grows with the repo, the queue stays bounded to one page.
Configuration & suppression
Zero-config to start. Tune via [tool.charlie] in pyproject.toml (or charlie.toml):
[tool.charlie]
exclude = ["vendor/**"]
disable = ["charlie/todo-rot"]
min_confidence = "high"
[tool.charlie.per-file-ignores]
"tests/**" = ["secret_leak"]Plus inline # charlie: ignore[rule], a .charlieignore, and a committed baseline (charlie-work baseline) so a fresh install starts at "0 new."
Development
uv sync --extra dev
uv run ruff check . && uv run mypy && uv run pytest -q
uv run python evals/run.pyCI runs ruff + mypy(typed) + pytest + evals across Python 3.11–3.13. Releases publish to PyPI via OIDC Trusted Publishing.
The gang (roadmap)
Each ships as its own standalone MCP server: The Implication (auth & dark-pattern auditor), Pepe Silvia (dead-code tracer), The D.E.N.N.I.S. System (rollout comms planner).
License
Code: MIT. The hero image is a still from It's Always Sunny in Philadelphia (© FX Networks), used for identification and commentary; it is not covered by the MIT license. An original vector rendition ships at assets/hero.svg.
Available Tools
7 toolscharlie_did_itCharlie: I did itA
Record that someone cleared a piece of toil, by its toil_id from a scan. Persists to a local ledger so the invisible work becomes visible. Rescans to resolve the item's title.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| who | Yes | ||
| mode | No | ||
| note | No | ||
| repo | No | . | |
| toil_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| report | Yes | |
| credits | Yes | |
| entries | Yes | |
| minutes | No | |
| champion | No |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and idempotentHint=false, consistent with a write operation. The description adds that the tool persists to a local ledger and rescans to resolve the title, providing useful behavioral context beyond annotations. No contradictions.
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 three sentences, each serving a purpose: core action, side effect, and secondary effect. No redundant or unnecessary wording. Front-loaded with the main purpose.
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 description covers the core action and side effects but lacks detail on prerequisites (e.g., existence of a prior scan), error handling, and parameter details for mode/note/repo. An output schema exists, reducing the need to explain return values, but parameter semantics remain insufficient.
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?
With 0% schema description coverage, the description must explain parameters. It mentions toil_id and implies who, but does not describe 'mode', 'note', or 'repo'—three of five parameters. The meaning of these parameters remains opaque, failing the high burden.
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 (record clearance), the resource (toil identified by toil_id), and the side effect (rescans). It distinguishes from sibling tools like charlie_scan_toil (scan) and charlie_ledger (ledger inspection).
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 the usage context (recording clearance of toil) but does not explicitly state when not to use or mention alternatives among siblings. It is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
charlie_explainCharlie: explain thisARead-only
Explain why a specific finding (by its toil id) is real debt, with evidence and a fix.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | . | |
| online | No | ||
| finding_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| item | No | |
| found | Yes | |
| report | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds limited new behavioral context. It does disclose that the output includes evidence and a fix, but does not elaborate on side effects, authentication needs, or rate limits.
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 a single, clear sentence that is front-loaded with the key purpose. It is concise with no redundant information, though it could be slightly more structured (e.g., listing evidence and fix explicitly).
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?
Given the presence of an output schema and annotations, the description is adequate for the core function but lacks explanation for all parameters. It does not describe the output in detail (relying on output schema) and does not cover the optional parameters, leaving some completeness gaps.
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 description coverage is 0%, so the description must compensate. It explains that finding_id is a 'toil id', but does not clarify the meaning or usage of 'repo' and 'online' parameters. The description adds value only for one of three parameters.
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 tool's action ('Explain why a specific finding is real debt'), the resource (a finding by toil id), and what the output includes (evidence and a fix). It distinguishes this from siblings like charlie_scan_toil (which scans) and charlie_summary (which provides summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need an explanation for a specific finding, but it does not explicitly state when to use this tool versus alternatives (e.g., charlie_triage) or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
charlie_ledgerCharlie: the ledgerARead-only
Report the credit ledger for standup or retro: who cleared what toil, the current Champion of the Grease Trap, and how much is still open.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| repo | No | . |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| report | Yes | |
| credits | Yes | |
| entries | Yes | |
| minutes | No | |
| champion | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the tool is safe. The description adds behavioral context by stating what the ledger reports (who cleared toil, Champion, open amount). No contradictions with annotations.
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 a single sentence that front-loads the purpose. It is concise, though slightly dense. Every part adds value.
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?
Given the simple tool (2 optional params, output schema exists), the description covers the main outputs but omits parameter details (e.g., what 'mode' values do) and usage context. Adequate but has gaps.
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 description coverage is 0%. The description does not explain the 'mode' or 'repo' parameters. With 0% coverage, the description should compensate but fails to add meaning beyond the schema.
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 specific verbs and resources: 'Report the credit ledger for standup or retro', listing what is included (who cleared toil, Champion, open amount). It distinguishes from sibling tools (charlie_summary, etc.) by its focus on ledger reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions usage contexts ('for standup or retro'), implying when to use. However, it does not provide explicit when-not-to-use guidance or contrast with sibling tools like charlie_summary or charlie_trend.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
charlie_scan_toilCharlie: scan for toilARead-only
Scan a repository for toil — the un-fun, load-bearing maintenance work everyone ignores: flaky, skipped, and focused tests; TODO/FIXME/HACK rot; expiring TLS certs; feature flags read but never set; unpinned dependencies; unowned operational scripts; and stray debug statements. Returns a prioritized queue. Set mode='plain' for a flavor-free report.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| repo | No | . | |
| kinds | No | ||
| limit | No | ||
| offset | No | ||
| online | No | ||
| github_repo | No | ||
| include_github | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of items on this page. |
| items | Yes | The prioritized toil queue for this page. |
| total | Yes | Total toil items found across the whole scan. |
| offset | Yes | Offset of this page into the full queue. |
| report | Yes | Human-readable prioritized report. |
| has_more | Yes | Whether more items exist past this page. |
| next_offset | No | Offset to pass for the next page. |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns a prioritized queue and lists the kinds of toil it detects. The annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by specifying what is scanned. No contradictions are present.
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. The first sentence effectively lists toil types, and the second provides a usage hint. While the list is long, it is acceptable for a scanning tool. Could be slightly more structured but is efficient overall.
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?
Given 8 parameters with zero schema description coverage, the description is incomplete. It only addresses mode and indirectly implies repo (scan a repository). The output schema exists, so return values are covered, but the parameter semantics are severely lacking, making the tool hard to use without further documentation.
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 description coverage is 0%, and the description only explains the 'mode' parameter (mode='plain'). The other seven parameters (repo, kinds, limit, offset, online, github_repo, include_github) are not described. The description fails to compensate for the lack of schema parameter descriptions.
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 tool scans a repository for toil, listing numerous specific types (flaky tests, TODOs, etc.). The name and title are descriptive, and it is distinct from sibling tools which likely perform different operations (e.g., charlie_did_it, charlie_trend).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions setting mode='plain' for a flavor-free report, providing some usage guidance. However, it does not explicitly compare to sibling tools or state when to choose this tool over others. The context of scanning for toil is clear, but no alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
charlie_summaryCharlie: the toil budgetBRead-only
Report the repo's toil budget: total estimated remediation minutes, a debt ratio, an A-E maintainability grade, and counts by kind. Google SRE says keep toil under 50 percent.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | . | |
| online | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| loc | Yes | |
| count | Yes | |
| grade | Yes | |
| counts | Yes | |
| report | Yes | |
| debt_ratio | Yes | |
| toil_score | Yes | |
| total_minutes | Yes |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds context about the output metrics but does not disclose potential side effects or limitations (e.g., whether online parameter affects behavior). With annotations present, this is adequate but not exceptional.
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 two sentences long, front-loading the main purpose and listing output components efficiently. No extraneous information. Front-loading: immediately starts with 'Report the repo's toil budget'.
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?
Given the simplicity of the tool (2 optional params, output schema exists), the description should explain input usage and prerequisites. It misses guidance on how parameters affect the output. For instance, 'repo' defaults to '.' and 'online' may trigger checks, but this is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the 'repo' and 'online' parameters. It fails to add meaning beyond the schema, such as default values or when each parameter is useful. This is a significant gap.
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 what the tool does: reports the repo's toil budget with specific metrics (remediation minutes, debt ratio, grade, counts). The reference to Google SRE adds context. It distinguishes itself from siblings like charlie_scan_toil by focusing on summary metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting a toil budget overview, but it does not explicitly state when to use this tool versus siblings (e.g., when a high-level summary vs. detailed scan is needed). No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
charlie_trendCharlie: the trendC
Record a toil snapshot and report how the toil budget has moved since last time.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | . | |
| online | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| delta | No | |
| report | Yes | |
| current | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write behavior (readOnlyHint=false) and open-world effects. The description adds the context of recording a snapshot, but does not detail side effects, required permissions, or what happens to existing data. It meets a basic level of transparency given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks structured details. It could benefit from a brief parameter explanation or usage note without becoming verbose.
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 2 parameters and an output schema, but the description omits details about the snapshot mechanism, the meaning of 'since last time', and the output format. This leaves the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description does not explain the 'repo' or 'online' parameters. Despite being few parameters, the description fails to add meaning beyond the schema, leaving the agent to guess their roles.
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 states the tool records a toil snapshot and reports budget movement. It uses specific verbs and clearly identifies the action. However, it does not differentiate from sibling tools like charlie_did_it or charlie_summary, which could have overlapping purposes.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or suggest alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
charlie_triageCharlie: triageBRead-only
Return the top-N highest-priority toil items as an action plan for an agent to work through.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | . | |
| top_n | No | ||
| online | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| report | Yes |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description adds only the basic purpose. It doesn't disclose ordering details, result stability, or side effects. With openWorldHint, the agent might need to know results can change externally, but this isn't mentioned.
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 with no redundancy. Every word contributes meaning, making it efficient and easy to parse.
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?
Despite having an output schema and annotations, the description is too minimal. It lacks details on what constitutes 'highest-priority', how the action plan is structured, or how parameters (repo, online) affect results. More context is needed for effective use.
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 description coverage is 0%, and the description only hints at 'top_n' by name. It does not explain 'repo' or 'online' parameters. The agent gains no additional meaning beyond the parameter names and default values.
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 tool returns the top-N highest-priority toil items as an action plan. It uses specific verbs ('Return') and resources ('toil items', 'action plan'), distinguishing it from sibling tools like charlie_scan_toil or charlie_summary.
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?
No guidance on when to use this tool versus its siblings (e.g., charlie_scan_toil, charlie_summary). The description does not specify prerequisites, context, or scenarios where this tool is preferred or should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.6/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: scanning for toil, explaining a finding, recording clearance, reporting the ledger, summarizing budget, tracking trends, and triaging priorities. No overlap.
Naming Consistency5/5
All tools follow a consistent 'charlie_verb' pattern with clear action words: scan_toil, explain, did_it, ledger, summary, trend, triage. The naming is predictable and informative.
Tool Count5/5
Seven tools cover the core workflow of toil management without excess. The count is well-scoped for the domain, providing essential functions without unnecessary duplication.
Completeness4/5
The tool set covers discovery, explanation, resolution recording, and reporting. Minor gaps might include a tool to manually add toil items or update details, but the surface is largely complete for typical toil management.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Audit and repair any public GitHub repo. Free survey; paid source, unified diffs and a pull request.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Security + bug + perf + refactor audit for Python. Returns 0-10 score + MD report.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceEnables AI agents to scan codebases for TODO/FIXME/XXX patterns and get prioritized results over MCP, supporting CI gates and multiple output formats.
- AlicenseNot gradedqualityDmaintenanceScans codebases for TODOs, FIXMEs, code complexity, file stats, and dependencies, generating a health report with a letter grade. Zero configuration required.29MIT
- AlicenseNot gradedqualityDmaintenanceEnables scanning projects for dependency vulnerabilities, secrets, license conflicts, code quality, and git health, returning a 0-100 health score with actionable suggestions.14MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Falcon305/charlie-work-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server