Cynical Sally is a brutally honest code review assistant offering AI-powered analysis, feedback, and suggestions across development and content tasks.
sally_roast (Code Review): Get a 0–10 scored review with identified issues and actionable fixes. Supports quick or full_truth (deep dive) modes, file/directory paths or inline code, multiple tones (cynical, neutral, professional), and a preview dry-run mode to verify what would be sent before sending.
sally_explain (Code Explanation): Explains what a piece of code does in plain English — useful for undocumented or inherited code.
sally_review_pr (PR Review): Submit a unified diff and get a senior-engineer-style review with concrete findings and a verdict.
sally_refactor (Refactoring): Proposes before/after refactoring suggestions with explanations of why the original code is problematic.
sally_brainstorm (Idea/Architecture Review): Pitch an idea or architectural approach and receive critical feedback on risks and failure points at scale.
sally_frontend (Frontend/UI Review): Specialized critique for HTML, CSS, JSX/TSX, Vue, Svelte, etc., covering re-renders, accessibility, z-index issues, and component design.
sally_marketing (Marketing Copy Review): Critique and before/after rewrites for taglines, landing pages, product descriptions, and brand messaging.
sally_usage (Quota & Account Status): Check your plan tier, remaining roast quota, per-tool trial status, and linked account email.
Key properties: All tools are read-only and never modify files. Secret files (.env, keys, certs) are skipped automatically. Code is never stored, logged, or used for training. Multi-language support via ISO 639-1 codes. Free tier includes 90 quick roasts/month; premium tools include 1 free trial/month.
Provides the same set of MCP tools for code review and analysis within the Windsurf IDE, which is a Codeium product.
Enables CI/CD integration with options to gate pipelines on code quality scores, fail builds below thresholds, and output compact results with exit codes.
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., "@Cynical Sally roast src/utils/auth.ts"
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.
Your AI pair programmer is lying to you. Sally isn't.
She's the senior engineer your code hoped it'd never meet. Scores from 0 to 10, real issues backed by evidence, and fixes you can actually use.
Works as a CLI tool and as an MCP server in Claude Code, Cursor, and Windsurf.
npm install -g @cynicalsally/cliOr run without installing:
npx @cynicalsally/cli roast ./src/Requirements: Node.js 18+
Related MCP server: DeepShit MCP Code Critic
Sending code to a server you don't control deserves more than "trust me." So Sally lets you verify it instead:
sally roast --dry-run ./src/--dry-run collects everything as if it were about to roast — then sends nothing. Instead it prints the exact payload: every file path, byte size, and token estimate; which files were held back and why (.env, keys, certs, binaries, .gitignore matches, size limits); and writes a local SHA-256 receipt to .sally/ so you can verify byte-for-byte what would have been uploaded.
WOULD SEND 3 files · 91 B · ~24 tokens (est.)
src/app.ts 36 B ~9 tok 68a3be428746…
HELD BACK 2 items — kept on your machine
✖ secret (2) — looks like a secret — never leaves your machine
.env
server.keySecret files (.env, SSH keys, certs, credential files) are skipped on your machine before anything is sent — verify it yourself with --dry-run. Only review code you're allowed to upload. Local reports land in .sally/ — add it to your .gitignore:
.sally/See Privacy & Security below for the full data-flow.
# Sally auto-detects what to review
sally roast
# → staged changes? reviews those
# → unstaged changes? reviews those
# → recent commit? reviews that
# → nothing? scans the directory
# Roast a file or directory
sally roast src/utils/auth.ts
sally roast ./src/
# Roast staged changes before you commit
sally roast --staged
# Compare your branch against main
sally roast --diff main
# Deep analysis with issues + actionable fixes
sally roast ./src/ -m full_truth
# Run deep analysis in the background (OS notification when done)
sally roast ./src/ -m full_truth --bg
# See exactly what would be sent — and send nothing
sally roast --dry-run ./src/
# Get a shareable roast card (saved to .sally/)
sally roast ./src/ --card
# Publish a share link — only the score + sneer go public, never your code
sally roast ./src/ --sharesally roast [paths...] [options]
--staged Review only staged git changes
--diff <branch> Compare against another branch (e.g., main)
-m, --mode <mode> "quick" (default) or "full_truth" (deep dive)
--tone <tone> "cynical" (default), "neutral", or "professional"
--lang <lang> Response language code (default: "en")
--json Output raw JSON (for piping or scripting)
--fail-under <score> Exit code 1 if quality score is below threshold
--ci CI mode: compact output, exit codes
--bg Run Full Truth in background, get OS notification when done
--dry-run Print the exact payload (files, sizes, tokens, SHA-256) and send NOTHING
--card Print + save a shareable roast card after the review
--share Create a public share link (cynicalsally.com/card/…) — score + sneer only, never codeLet Sally judge your whole repo and hand you a README badge with the score baked in:
sally verdictShe scores the repo, then prints ready-to-paste badge markdown:
[](https://cynicalsally.com)Score an 8 or higher and the badge is a flex worth wearing. Score lower and, well — it's an honest signal that you're shipping anyway. Either way the badge links back, so every README that wears it does the bragging for you.
Too lazy to copy-paste? Sally will hang it up herself:
sally badge --add # inserts the badge into README.md, right under the title
sally badge # just prints the markdown (and your current score)The badge image updates automatically on every new sally verdict — add it once,
judged forever.
Sally reads the spaghetti someone left in your codebase and translates it into plain English. Just the cold, clear truth of what it actually does.
sally explain src/utils/auth.ts
# Pipe code directly
cat legacy-module.js | sally explain
# Explain the current directory
sally explainBefore and after, side by side. Sally explains why one of them is going to haunt your 3am on-call rotation.
sally refactor src/components/Dashboard.tsx
# Refactor current directory
sally refactorSally reviews your PR like a senior engineer who has time, opinions, and absolutely no reason to be polite.
# Review PR #42 (requires GitHub CLI)
sally review-pr 42
# Review current branch vs main
sally review-pr
# Pipe a diff
git diff main | sally review-prPitch your architecture idea and Sally tells you the three ways it falls apart at scale. Cheaper than a post-mortem.
sally brainstorm "Microservices for a 2-person team?"
# Brainstorm about the current project
sally brainstormSally tells you why your component re-renders on every keystroke and why your z-index is load-bearing.
sally frontend src/components/Header.tsx
# Review all frontend code in a directory
sally frontend ./src/Run your copy by Sally before your customers do. They won't be this constructive about it.
sally marketing "Ship faster with AI-powered code reviews"
# Review your README and landing page copy
sally marketing README.mdEvery tool accepts file paths, raw text, or piped stdin. Each includes 1 free trial, no account needed.
Gate your pipeline on code quality:
# GitHub Actions
- name: Sally Code Review
run: npx @cynicalsally/cli roast ./src/ --fail-under=5 --ci--ci gives compact output with exit codes. --fail-under fails the build when the score drops below your threshold. Add --json for machine-readable output.
Sally works as an MCP server inside Claude Code, Cursor, and Windsurf.
claude mcp add cynical-sally -- npx @cynicalsally/cli mcpOne click:
Or add to ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project):
{
"mcpServers": {
"cynical-sally": {
"command": "npx",
"args": ["@cynicalsally/cli", "mcp"]
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"cynical-sally": {
"command": "npx",
"args": ["@cynicalsally/cli", "mcp"]
}
}
}MCP Tool | What it does |
| Code review with score, issues, and fixes |
| Explain code with Sally's personality |
| Review PR diffs |
| Refactoring suggestions with before/after |
| Feedback on ideas and approaches |
| Frontend/UI code review |
| Marketing copy review |
| Check quota and account status |
Roast by path — the agent can call sally_roast with just paths (files or directories); Sally reads them locally and skips binaries and secret files, so the agent doesn't have to read and pass content itself.
Prompts — Sally also exposes ready-made slash-command intents (roast, review-pr, explain) in clients that surface MCP prompts.
Run sally mcp in your terminal to see setup instructions.
Command | Description |
| Review files, directories, or git changes |
| Score your repo + get a README badge |
| Print your badge markdown, or add it to README.md |
| Explain what code actually does |
| Refactoring with before/after code |
| Review a PR diff |
| Feedback on ideas and approaches |
| Frontend/UI code review |
| Marketing copy review |
| Log in via magic link |
| Clear stored session |
| Check your quota and account status |
| Upgrade to Sally's Full Suite |
| View background review results |
| MCP server setup instructions |
90 free roasts per month, no account needed. Every premium tool includes a free trial.
sally usage # Check your quota
sally upgrade # Unlock the Full SuiteYour code is yours. Don't take our word for it — run sally roast --dry-run and see the exact payload before anything is sent. Here's what happens to it:
Verify before you send. --dry-run prints every file, size, token estimate, and a SHA-256 receipt of exactly what would be uploaded — and sends nothing. The MCP sally_roast tool has the same preview mode.
Sent only to be reviewed. The files you choose are transmitted over HTTPS and processed in real-time to generate the review — that's the only reason they leave your machine.
Never written to disk, logs, or analytics. Your source code is processed in memory and discarded after analysis. It is never persisted to a database, never written to application logs or error traces, and never sent to any third-party APM or analytics. We keep the review (score, issues), not your source.
Never trained on, sold, or shared. Analysis runs through Anthropic's API, which doesn't train on submitted content.
Only what you point at. Sally doesn't browse your repo, read files you didn't give her, or scan your projects or plans. Secret files (.env, keys, certs, credential files) are skipped on your machine before anything is sent — and --dry-run shows you exactly which ones.
Sharing is opt-in, and never includes code. Nothing is ever published unless you pass --share — and even then the public card contains only the score and Sally's one-liner.
Anonymous by default. Reviews are tied to a random device ID, not your identity — until you link an email for Full Suite. Config stored locally at ~/.sally/config.json.
Signed releases. npm packages are published with provenance — a cryptographic, public attestation linking each release to the exact source commit and CI build that produced it.
Full engineering detail — data-flow diagram, what's retained, subprocessors, and log policy — is in docs/PRIVACY.md. User-facing summary: cynicalsally.com/privacy.
Found a bug or have a feature idea? Open an issue. Sally promises to only judge your issue title a little.
Pitch an idea or architecture and Sally names the three ways it falls apart at scale — cheaper than a post-mortem. Use when the user wants feedback on an idea, approach, design decision, or trade-off before building it. Sends only the provided description to the Cynical Sally backend — never stored, never used for training. Read-only: never modifies files. Returns a markdown verdict with risks and a bright side. Premium tool: one free use per month on the free tier, unlimited with Full Suite.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ISO 639-1 language code for Sally's response (e.g. 'en', 'nl'). Defaults to English. | en |
| description | Yes | The idea, architecture, or approach to evaluate — from a few sentences to a full design sketch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description adds critical behavioral context: data is never stored or used for training, it is read-only ('never modifies files'), and it includes premium usage limits. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with core purpose, then usage guidelines, privacy, and premium info. It is slightly verbose but each sentence adds value. No waste, but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters (both documented in schema), no output schema, but the description explains the return format ('markdown verdict with risks and a bright side'), along with privacy and limits. Enough for the agent to understand behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions are detailed. The tool description adds only a minor confirmation that only the provided description is sent to the backend, not additional semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to evaluate an idea or architecture for scalability flaws, using a specific verb ('Pitch...Sally names the three ways it falls apart'). It distinguishes itself from sibling tools (e.g., sally_roast, sally_explain) by focusing on pre-build critique and scalability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use ('Use when the user wants feedback on an idea... before building it') and provides context about premium tiers and limits. However, it does not explicitly list when not to use or directly contrast with sibling tools, which would have earned a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Have Sally explain what a piece of code actually does, in plain English — no hand-holding, just the cold, clear truth. Use when the user wants a snippet or file explained, asks 'what does this do', or inherited code nobody documented. Sends only the provided code to the Cynical Sally backend — never stored, never used for training. Read-only: never modifies files. Returns a markdown explanation in Sally's voice. Premium tool: one free use per month on the free tier, unlimited with Full Suite.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ISO 639-1 language code for Sally's response (e.g. 'en', 'nl'). Defaults to English. | en |
| content | Yes | The code to explain — a snippet, function, or whole file, as plain text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint, adds no-storage/no-training privacy guarantee, markdown output format, and premium tier info. Does not detail any potential dynamic behavior but adds significant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately long (5 sentences) but every sentence serves a purpose: purpose, usage, privacy, read-only, output, premium. Front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects for agent invocation: purpose, when to use, privacy, read-only nature, return format, and usage limits. No output schema but return format is described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal extra meaning: only mentions that 'content' is the code and 'lang' is optional. Sufficient but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'explain' and resource 'code', with a distinctive tone ('plain English, no hand-holding'). Differentiates from siblings by focusing on code explanation rather than brainstorming or refactoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: 'when the user wants a snippet or file explained, asks what does this do, or inherited code nobody documented.' Provides clear context and implicit alternative avoidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sally roasts frontend/UI code — wasteful re-renders, load-bearing z-index, accessibility sins, and questionable component design. Use for HTML/CSS/JSX/Vue/Svelte or other UI code; for general-purpose code use sally_roast instead. Sends only the provided code to the Cynical Sally backend — never stored, never used for training. Read-only: never modifies files. Returns markdown with categorized issues and fixes. Premium tool: one free use per month on the free tier, unlimited with Full Suite.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ISO 639-1 language code for Sally's response (e.g. 'en', 'nl'). Defaults to English. | en |
| content | Yes | The frontend/UI code to review — HTML, CSS, JSX/TSX, Vue, Svelte, or similar, as plain text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: never stored, never used for training, read-only, returns markdown with categorized issues. No contradictions with annotations (readOnlyHint, openWorldHint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding distinct value: core function, usage scope, privacy/behavior, output format and pricing. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and multiple frontend types, the description sufficiently covers tool behavior, safety, return format (markdown with categorized issues), and usage limits. Complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add significant new meaning beyond what the schema already provides for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it roasts frontend/UI code, listing specific types (HTML, CSS, JSX, Vue, Svelte), and distinguishes from the sibling sally_roast for general-purpose code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (for frontend/UI code) and when not to (use sally_roast instead). Also mentions premium tier usage limits, providing context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sally reviews marketing copy, branding, and landing-page text before your customers do it less kindly. Use when the user wants copy, taglines, or brand messaging critiqued — returns before/after rewrites with the reasoning. Sends only the provided text to the Cynical Sally backend — never stored, never used for training. Read-only: never modifies files. Premium tool: one free use per month on the free tier, unlimited with Full Suite.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ISO 639-1 language code for Sally's response (e.g. 'en', 'nl'). Defaults to English. | en |
| content | Yes | The marketing copy to review — taglines, landing-page text, product descriptions, or brand messaging |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds key behavioral details: text is sent only to the backend, never stored or used for training. It also states that it never modifies files, aligning with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding essential information: purpose, usage/output, and behavioral/privacy details. No wasted words and front-loaded with the most important info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter tool with no output schema, the description covers purpose, usage, behavioral transparency (privacy, read-only), and output format (before/after rewrites with reasoning). It also mentions premium tier limits. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no significant new meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that Sally reviews marketing copy, branding, and landing-page text, and specifies that it returns before/after rewrites with reasoning. This distinguishes it from siblings like sally_roast or sally_review_pr, which likely have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the user wants copy, taglines, or brand messaging critiqued' and notes the read-only nature. It could be more explicit about when not to use, but the context and sibling names provide enough differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sally proposes concrete refactors with before/after code and explains why the original would haunt your 3am on-call rotation. Use when the user wants code improved, cleaned up, simplified, or modernized. Sends only the provided code to the Cynical Sally backend — never stored, never used for training. Read-only: suggestions come back as markdown, nothing is applied to files. Premium tool: one free use per month on the free tier, unlimited with Full Suite.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ISO 639-1 language code for Sally's response (e.g. 'en', 'nl'). Defaults to English. | en |
| content | Yes | The code to refactor — a function, class, or file, as plain text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. Description adds key details: output is markdown, code is never stored or trained on, usage limits (one free use/month). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient: clear purpose sentence, usage directive, privacy guarantee, read-only note, and premium tier info. Every sentence adds unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains output as markdown with before/after code. It covers privacy, behavior, and usage limits, making it complete for a simple 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema (100% coverage). The description does not add extra detail about lang or content beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs refactoring with concrete before/after code and explains why original code is poor. It distinguishes from siblings like sally_roast (roasting) and sally_explain (explaining) by focusing on code improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when the user wants code improved, cleaned up, simplified, or modernized.' Provides clear context but no explicit alternative suggestions or when-not-to-use flags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sally reviews a PR diff like a senior engineer with time, opinions, and no reason to be polite — catching what automated tools miss. Use when the user wants a pull request, commit, or unified diff reviewed before merging. Sends only the provided diff to the Cynical Sally backend — never stored, never used for training. Read-only: never modifies files. Returns a markdown review with a verdict and concrete findings. Premium tool: one free use per month on the free tier, unlimited with Full Suite.
| Name | Required | Description | Default |
|---|---|---|---|
| diff | Yes | The pull request changes as a unified diff (e.g. output of `git diff main` or `gh pr diff`) | |
| lang | No | ISO 639-1 language code for Sally's response (e.g. 'en', 'nl'). Defaults to English. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds 'Read-only: never modifies files' and 'never stored, never used for training.' Provides additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise but complete. Front-loaded with core purpose. Each sentence adds value: purpose, usage, privacy, read-only, return format, pricing. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Moderate complexity with 2 parameters, no output schema. Description explains return format 'markdown review with a verdict and concrete findings.' Sufficient for agent to understand outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds context: 'Sends only the provided diff to the Cynical Sally backend' and explains diff format (e.g., git diff main) and lang examples. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it reviews a PR diff like a senior engineer with opinions. Verb and resource are specific, and it distinguishes from siblings by emphasizing catching what automated tools miss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the user wants a pull request, commit, or unified diff reviewed before merging.' Provides usage context. Does not explicitly list when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a brutally honest code review from Cynical Sally — a 0–10 score, real issues backed by evidence, and fixes you can actually use. Use this whenever the user wants code reviewed, critiqued, roasted, or asks 'what does Sally think'. Pass paths (files or directories Sally reads herself, skipping binaries and secrets) OR files with inline content. quick = a fast, sharp take (90 free per month per device); full_truth = a deep dive with ranked issues and actionable fixes. Sends the selected code to the Cynical Sally backend for analysis — never stored, never used for training; set preview to true to see exactly what would be sent without sending anything. Read-only: never modifies files. Returns markdown with the score, verdict, top issues, and fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ISO 639-1 language code for Sally's response (e.g. 'en', 'nl'). Defaults to English. | en |
| mode | No | quick = fast roast; full_truth = deep dive with ranked issues + actionable fixes (1 free per month, then Full Suite) | quick |
| tone | No | Sally's delivery: cynical (default, full sass), neutral, or professional — same findings, different wording. | cynical |
| files | No | Code files with inline content (alternative to `paths`) | |
| paths | No | File or directory paths to review. Sally reads them locally (skips binaries, oversized files, and common secret files). Prefer this over `files` so you don't have to read and pass content yourself. | |
| share | No | Publish a public share card and include the link — the card shows only the score and Sally's one-liner, never code. Only use when the user explicitly asks to share the roast. | |
| preview | No | Dry run: return exactly what WOULD be sent (file list, byte sizes, token estimates, SHA-256 hashes, and which files were skipped and why) and send NOTHING to the backend. Use this when the user wants to verify what leaves their machine before roasting. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'Read-only: never modifies files', 'never stored, never used for training', and explains preview mode for verifying what is sent. Perfectly aligns with readOnlyHint:true and openWorldHint:true annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well structured with purpose up front, then input options, mode, privacy, and preview info. Each sentence adds value, though slightly verbose; could be trimmed slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers all aspects of a complex 7-parameter tool without output schema: purpose, input methods, modes, privacy, security (preview), sharing, and return format (markdown). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by recommending paths over files, explaining mode differences, preview functionality, and share option. Provides practical guidance beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'brutally honest code review' with a 0-10 score, issues, and fixes. It distinguishes from siblings by focusing on roasting and reviewing code, with specific verbs like 'review', 'critique', 'roast'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when user wants code reviewed, critiqued, roasted, or asks what Sally thinks. Differentiates between paths vs files inputs and quick vs full_truth modes. Does not explicitly state when not to use or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the user's Cynical Sally quota and account status: tier (Free or Full Suite), remaining quick roasts and Full Truth reviews this month, per-tool premium trials, and the email linked to this device. Use when the user asks how many roasts they have left, what plan they're on, or why a Sally tool just hit a quota wall. Takes no parameters. Sends only the anonymous device ID to the Cynical Sally backend — no code, no personal data. Read-only: never modifies files. Returns a markdown account summary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by explaining what data is sent ('only the anonymous device ID') and that no code or personal data is transmitted, reinforcing the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise at 4-5 sentences, front-loaded with the main purpose. Every sentence adds essential context without redundancy. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters and no output schema, the description is fully complete: it explains inputs (none), behavior (read-only, sends anonymous device ID), and output (markdown account summary). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100% (empty). The description states 'Takes no parameters,' which is sufficient. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the user's Cynical Sally quota and account status, listing specific details like tier, remaining roasts, Full Truth reviews, per-tool premium trials, and email. It distinguishes from siblings like sally_roast, sally_explain, etc., by focusing on usage and account status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when the user asks how many roasts they have left, what plan they're on, or why a Sally tool just hit a quota wall.' Also clarifies it takes no parameters, providing clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a specific domain (ideas, code explanation, frontend, marketing, refactoring, PR reviews, general code review, usage) with clear boundaries. Overlaps are minimal and well-differentiated in descriptions.
All tools follow the 'sally_{action_or_target}' pattern in lower_snake_case, providing a predictable and consistent naming convention across the set.
Eight tools cover the core functionality of the cynical feedback server without being too few or too many, striking a good balance for the intended scope.
The tool surface covers key areas: idea critique, code explanation, frontend review, marketing review, refactoring, PR review, general code review, and usage tracking. No obvious gaps for the domain of cynical analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
AI code review for GitHub PRs with an MCP autofix loop for Claude Code and Cursor
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/w1ckedxt/cynical-sally'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
