What can you do with this server?

The Code Auditor MCP server lets AI agents enforce architectural invariants, analyze codebases, search code, and manage development tasks. Here's what you can do: Code Auditing * Start background audits (start_audit): Launch async audit jobs with configurable analyzers (SOLID, DRY, documentation, React, data-access), severity thresholds, worker counts, and partitioning strategies * Poll audit status (audit_status): Check progress of a running audit job * Fetch audit results (audit, audit_results): Retrieve paginated violations from completed audits * Quick health check (audit_health): Get a fast codebase health score with key metrics and optional code map generation * Enforce rules including import-ban, call-constraint, module-boundary, naming, ast-pattern, style-mechanism, and no-raw-values Code Search & Navigation * Search indexed code (search_code): Query functions and React components using natural language plus operators (e.g., calls:, dep:, hook:, unused-imports, complexity:) * Find definitions (find_definition): Look up the exact definition location of a specific function or React component Index Management * Sync the code index (sync_index): Update, clean up, or fully reset the analysis-derived data index (function index, cached audits, code maps) Analyzer Configuration * Set/get/reset analyzer config (set_analyzer_config, get_analyzer_config, reset_analyzer_config): Persist, retrieve, or restore custom thresholds and rules for specific analyzers Code Maps * List/get code map sections (list_code_map_sections, get_code_map_section): View or retrieve specific sections (overview, files, dependencies, documentation) from a generated code map Task Management * Manage project tasks (project_tasks): Full CRUD for a persistent per-project task queue with priorities, labels, subtasks, blocked-by relationships, due dates, and text search Setup & Guidance * Generate AI config files (generate_ai_config): Scaffold configuration files for AI coding assistants (Cursor, Copilot, Claude, Windsurf, etc.) * Get workflow guide (get_workflow_guide): Retrieve recommended workflows for scenarios like initial setup, React development, code review, and maintenance

Which integrations are available for this server?

Generates configuration files to integrate GitHub Copilot with the code auditor, allowing Copilot to access code analysis and intelligent suggestions.

How do I use code-auditor-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@code-auditor-mcp Find all functions that validate user input" 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.

code-auditor-mcp

by BenAHammond

Overview Schema Related Servers Score Discussions

TypeScript

Local

The Code Auditor MCP server lets AI agents enforce architectural invariants, analyze codebases, search code, and manage development tasks. Here's what you can do:

Code Auditing

Start background audits (start_audit): Launch async audit jobs with configurable analyzers (SOLID, DRY, documentation, React, data-access), severity thresholds, worker counts, and partitioning strategies
Poll audit status (audit_status): Check progress of a running audit job
Fetch audit results (audit, audit_results): Retrieve paginated violations from completed audits
Quick health check (audit_health): Get a fast codebase health score with key metrics and optional code map generation
Enforce rules including import-ban, call-constraint, module-boundary, naming, ast-pattern, style-mechanism, and no-raw-values

Code Search & Navigation

Search indexed code (search_code): Query functions and React components using natural language plus operators (e.g., calls:, dep:, hook:, unused-imports, complexity:)
Find definitions (find_definition): Look up the exact definition location of a specific function or React component

Index Management

Sync the code index (sync_index): Update, clean up, or fully reset the analysis-derived data index (function index, cached audits, code maps)

Analyzer Configuration

Set/get/reset analyzer config (set_analyzer_config, get_analyzer_config, reset_analyzer_config): Persist, retrieve, or restore custom thresholds and rules for specific analyzers

Code Maps

List/get code map sections (list_code_map_sections, get_code_map_section): View or retrieve specific sections (overview, files, dependencies, documentation) from a generated code map

Task Management

Manage project tasks (project_tasks): Full CRUD for a persistent per-project task queue with priorities, labels, subtasks, blocked-by relationships, due dates, and text search

Setup & Guidance

Generate AI config files (generate_ai_config): Scaffold configuration files for AI coding assistants (Cursor, Copilot, Claude, Windsurf, etc.)
Get workflow guide (get_workflow_guide): Retrieve recommended workflows for scenarios like initial setup, React development, code review, and maintenance

Code Auditor

Architectural invariants enforced inside your AI agent's edit loop. When the agent writes code that breaks a project rule, Code Auditor catches it and blocks the edit. The agent sees the rule's message and fixes itself.

Install

npm install -g code-auditor-mcp
code-audit install --agent all

Two commands to install everywhere. code-audit install --agent all copies the skill to every AI coding tool on your machine. Use --agent for specific tools.

What you get per tool: the skill (SKILL.md), MCP server access, and hook wiring where the tool supports it (blocking on Claude Code and Codex, advisory on Cursor).

code-audit install --list   # see the support matrix

Claude Code users can also install via plugin:

claude plugin marketplace add BenAHammond/code-auditor-mcp
claude plugin install code-auditor

The hook auto-installs the auditor on first use via npx.

Related MCP server: OpenCodeHub MCP Server

Prompt examples

"Index the codebase and run a full audit, then walk the violations file-by-file with code-audit next-file."

"Create a .codeauditor.json that bans lodash imports and prevents src/languages/ from importing anything in src/analyzers/."

"Run a full audit, fix the highest-priority file, and repeat code-audit next-file until the tree is clean."

"Sync the code index and audit only what changed vs main."

"Add an ast-pattern rule that blocks new Function(...)."

"Add a naming rule requiring hooks in src/hooks/ to start with use."

"Add a call-constraint so chargeCustomer() in src/services/payment.ts can only be called from src/api/."

Rule kinds

Seven kinds. The agent writes them to .codeauditor.json. Bad configs fail the audit, not silently.

Kind	What it blocks
`import-ban`	Banned module imports
`call-constraint`	Function calls from unauthorized files
`module-boundary`	Imports across module boundaries
`naming`	Exported symbols not matching a pattern
`ast-pattern`	AST nodes matching an ast-grep pattern
`style-mechanism`	Unapproved style mechanisms per file/glob
`no-raw-values`	Hardcoded values for specific CSS properties

Works with your agent

One skill, one CLI, one MCP server. Every agent gets the same audit engine — the hook contract is the only difference.

Agent	Skill	Hooks / Blocking	MCP	Verified
Claude Code	Plugin or `code-audit install`	Yes — blocking	Yes	2026-07-19
Cursor	`code-audit install --agent cursor` (project-only)	Advisory	Yes	2026-07-19
Codex	`code-audit install --agent codex` + plugin	Yes — blocking	Yes	2026-07-19
Gemini CLI	`code-audit install --agent gemini`	No	Yes	2026-07-19
VS Code / Copilot	`code-audit install --agent agents`	No	Yes	2026-07-19
Other SKILL.md tools	`code-audit install --agent agents`	No	Yes	2026-07-19

Hook behavior: Blocking means the diff-scoped changed gate is tripped — an invariant rule that declares gating: true (a binary, per-rule flag, independent of severity) blocks the edit from landing (the agent sees the violation and fixes inline). Advisory means violations are reported through the strongest available feedback channel but the edit has already occurred. Cursor's afterFileEdit hook is fire-and-forget with no output consumption. MCP is available everywhere for shell-less use.

Findings: Deterministic vs Advisory

Code Auditor's built-in rules fall into two categories:

Category	Meaning	Examples
Deterministic	Structural fact — an engineer would act on every finding	`single-responsibility` (300-line functions), `solid/method-complexity` (cyclomatic complexity > 20), `solid/class-size` (40+ method classes), `dependency-inversion` (concrete imports where an interface exists)
Advisory	Heuristic signal — may be wrong depending on domain	`sql-injection-risk` (AST-level string-pattern matching without type info), `missing-org-filter` (domain-specific — assumes SaaS tenant isolation), `unknown-table` (requires user-provided schema), `dry/duplicate` (token-identical blocks)

Deterministic rules ship at critical or warning. Advisory rules ship at warning or suggestion. Rules proven near-zero precision on a real corpus are disabled by default (off) — users opt in when the rule matches their domain.

Recalibration

Built-in severity defaults are recalibrated from real-corpus triage. The current defaults reflect measurement on three corpora: this tool's own codebase, Gin, and Excalidraw. Six data-access rules that produced near-zero precision across all three corpora are disabled by default.

Every disabled rule documents what corpus it would be useful on. Users can restore any rule via severityOverrides in .codeauditor.json:

{
  "severityOverrides": {
    "sql-injection-risk": "warning",
    "missing-org-filter": "critical",
    "loop-query": "warning"
  }
}

Severity overrides apply globally (before per-directory path profile caps). Setting a rule to "off" removes it from the output entirely.

SQL Injection Detection

The sql-injection-risk rule is disabled by default (off) after recalibration. On the self-audit corpus, it produced 0% precision — the analyzer misinterpreted TypeScript pattern-matching code (string constants like 'SELECT', 'FROM', 'WHERE' used for the tool's own SQL detection) as database queries. On the Gin and Excalidraw corpora, precision was also near zero.

When to re-enable it: your project's SQL is constructed via string concatenation or template literals in functions whose sole purpose is query assembly. The rule detects those patterns. For codebases using ORMs or parameterized queries exclusively, the rule produces noise.

To re-enable and block on SQL injection:

{
  "severityOverrides": {
    "sql-injection-risk": "critical"
  }
}

With sql-injection-risk: critical (and the rule marked gating), your agent's hook will block edits that introduce AST-level SQL injection patterns.

Style Intelligence

Code Auditor indexes every style declaration in your project — CSS, SCSS, Tailwind, inline styles, and CSS-in-JS. The styles analyzer reads global distributions and flags fragmentation that no single-file linter can see.

7 detectors, 10 rule IDs:

Detector	What it finds
Value drift	Near-duplicate color values (delta-E < 2.0) and exact-value outliers where one value dominates
Off-scale	Margin/padding/gap/font-size values not on the inferred project scale
Undefined class	`className` values with no matching CSS selector or Tailwind utility
Token bypass	Hardcoded values that match a design token but don't reference it
Mechanism fragmentation	Same `(property, value)` delivered via ≥ 3 mechanisms (CSS, inline, Tailwind)
Declaration-set similarity	Two CSS rule blocks with > 90% identical declarations
Z-index sprawl	Project-wide z-index inventory — too many distinct values or orphan singletons

The analyzer reads from a project-wide SQLite index, so scoped runs (changed files only) still compare against the full project baseline. A fresh #273828 drift color in a scoped run is caught against the full corpus of #1e2328 values.

Style invariant rules:

{
  "rules": [
    {
      "kind": "style-mechanism",
      "message": "Only Tailwind in src/components/",
      "allow": ["tailwind"],
      "path": "src/components/**"
    },
    {
      "kind": "no-raw-values",
      "message": "No raw colors in src/pages/ — use design tokens",
      "properties": ["color", "background-color"],
      "path": "src/pages/**"
    }
  ]
}

Style search operators — search by property, value, mechanism, or token:

code-audit search "css:margin-top value:16px"          # specific value
code-audit search "mechanism:inline css:color"          # inline color declarations
code-audit search "token:--color-primary"                # bypassing a design token

The React analyzer also gains raw-element detection: if your project has a Button wrapper, raw <button> usages outside Button's definition become warnings.

License

MIT

Available Tools

16 tools

auditA

Fetch paginated results for a completed audit by resultId (or auditId alias). This tool never starts a new audit.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of violations to return per page (default: 50, max: 100)
`offset`	No	Violation offset for pagination (default: 0).
`auditId`	No	Backward-compatible alias for resultId.
`resultId`	No	Result ID returned by audit_status when the background audit job completes.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses it never starts an audit, but lacks details on error conditions, authentication, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences, no fluff, front-loaded with the key action and resource.

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?

Covers pagination and purpose, but lacks description of return value format and how it fits with sibling tools like audit_results. Missing output schema further limits completeness.

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?

Schema coverage is 100%, so the description adds minimal value. The alias info is a small addition, but most parameter details are already in 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 clearly states the action ('Fetch paginated results'), the resource ('completed audit'), and differentiates from starting a new audit. It also explains the alias between resultId and auditId.

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 says to use for completed audits and that it never starts a new audit, but does not explicitly compare with sibling tools like audit_results or audit_status, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

audit_healthC

Quick health check of a codebase with key metrics

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	The directory path to check	/app
`threshold`	No	Health score threshold (0-100) for pass/fail
`indexFunctions`	No	Automatically index functions during health check
`analyzerConfigs`	No	Analyzer-specific configuration overrides (e.g., SOLID thresholds, DRY settings)
`generateCodeMap`	No	Generate and return a human-readable code map as part of the health check results

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description alone must disclose behavior. It only states 'quick health check' with no information about side effects, permissions, or what 'key metrics' include. The read-only nature is implied but 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no fluff. However, given 5 parameters and no annotations, a bit more structural context (e.g., 'Returns a health score and key metrics') would improve usability.

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?

With 5 parameters (including a nested object), no output schema, and 15 sibling tools, the description is too minimal. It does not explain return values, how 'health check' differs from full audit, or what constitutes 'key metrics.'

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?

All 5 parameters are fully described in the schema (100% coverage), so the description does not need to repeat them. It adds no extra context beyond the schema, meeting the baseline.

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 a 'quick health check of a codebase with key metrics,' clearly specifying a lightweight audit verb and resource. It vaguely differentiates from sibling 'audit' and 'start_audit' but does not explicitly contrast with full audits.

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 alternatives like 'audit' or 'start_audit.' There is no mention of context, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

audit_resultsA

Fetch paginated violations for a completed audit result by resultId.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of violations to return per page (default: 50, max: 100).
`offset`	No	Violation offset for pagination (default: 0).
`resultId`	Yes	Result ID returned by audit_status when status is completed.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the full burden. It indicates fetch (read) operation but does not disclose pagination limits or error conditions beyond what the schema provides. Some value is added by specifying 'completed audit result'.

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 sentence with no redundant words. It efficiently conveys the core purpose.

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?

Given the simple nature (3 parameters, no nested objects) and lack of output schema, the description adequately specifies the core functionality. It could be more complete by noting return format or error handling, but it is sufficient for basic usage.

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?

Schema has 100% coverage with clear descriptions for all 3 parameters. The tool description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.

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 verb 'fetch' and resource 'paginated violations for a completed audit result by resultId'. It effectively distinguishes from sibling tools like audit (which runs audits) and audit_status (which checks completion status).

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 after a failed audit result is completed via the phrase 'completed audit result', but it does not explicitly state when to use or avoid this tool, nor suggest alternatives like audit_status for checking completion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

audit_statusA

Get current status for a previously started background audit job. Returns resultId when completed.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes	Job ID returned by start_audit.

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses it returns status and resultId when completed, but lacks error handling info (e.g., what if job unknown). Adequate but 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?

Single sentence, front-loaded with key purpose, no unnecessary words. Every part earns its place.

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?

With one parameter and no output schema, the description covers essential semantics. Could mention return format or error states, but sufficient for a simple status tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description 'Job ID returned by start_audit' adds critical context beyond schema structure, linking it to a sibling tool.

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 verb 'Get', the resource 'current status for a previously started background audit job', and the return value 'resultId when completed'. It distinguishes from siblings like start_audit and audit_results.

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 states to use after start_audit ('previously started background audit job'). No explicit when-not-to-use, but context from sibling tools implies alternatives. Clear enough for a simple polling step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_definitionA

Find the exact definition of a specific function or React component

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Function or component name to find
`filePath`	No	Optional file path to narrow search

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full burden. It does not disclose whether the tool is read-only, what happens if the name is not found, or any other behavioral traits.

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?

Single sentence, concise, and front-loaded with the core functionality. No wasted words.

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 is minimal. For a simple 2-parameter tool, it provides the essential purpose but lacks details on return format or error handling. No output schema compensates.

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?

Schema coverage is 100%, and the description adds no extra meaning beyond the parameter descriptions. Baseline score of 3 is appropriate.

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?

Description clearly states the tool finds the exact definition of a function or React component, specifying the verb and resource. It distinguishes from siblings like search_code which is broader.

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?

No explicit when-to-use or alternatives are provided. The purpose implies usage for finding definitions, but no guidance on when to prefer this over search_code or other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_ai_configA

Generate configuration files for AI coding assistants

ParametersJSON Schema

Name	Required	Description	Default
`tools`	Yes	AI tools to configure (cursor, continue, copilot, claude, zed, windsurf, cody, aider, cline, pearai)
`outputDir`	No	Output directory for configuration files	.

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states that the tool generates config files, without disclosing any behavioral traits such as side effects (e.g., overwrites), required permissions, or error conditions. This is insufficient for a generation 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 a single, clear sentence with no wasted words. It is appropriately sized and front-loaded with the core action.

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?

While the description adequately communicates the basic function, it lacks details about output behavior (e.g., what files are created, whether existing files are overwritten). For a tool with no output schema, this omission reduces completeness.

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 both parameters with descriptions, so schema coverage is 100%. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.

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 verb 'generate' and the resource 'configuration files for AI coding assistants'. It is specific and distinct from sibling tools which focus on auditing and code analysis, making the purpose unambiguous.

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 does not provide explicit guidance on when to use this tool versus alternatives or prerequisites. Usage is implied from the name and context of siblings, but no direct when-to-use or when-not-to-use information is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_analyzer_configB

Get current configuration for an analyzer

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	No	Optional project path to get project-specific config
`analyzerName`	No	Specific analyzer name, or omit to get all configs

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description only says 'Get' implying read-only, but does not disclose side effects, permissions, or error behavior. Minimal behavioral disclosure.

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?

Single sentence, front-loaded with verb, no extraneous words. Efficient and clear.

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?

Description covers basic purpose but lacks details on output format or meaning of 'configuration'. Given low complexity and no output schema, it is adequate but not thorough.

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?

Schema coverage is 100% with descriptions. The description adds modest context by noting 'Optional' and 'omit to get all', but largely restates 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?

Description clearly states verb 'Get' and resource 'configuration for an analyzer'. It distinguishes from siblings like set_analyzer_config and reset_analyzer_config.

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 vs alternatives, or when to include optional parameters. Missed opportunity to clarify typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_code_map_sectionB

Retrieve a specific section of a previously generated code map

ParametersJSON Schema

Name	Required	Description	Default
`mapId`	Yes	The map ID returned from a previous audit with code map generation
`sectionType`	Yes	The section type to retrieve (e.g., overview, files, dependencies, documentation)

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fails to disclose behavioral traits such as idempotency, side effects, or required permissions. It only states the retrieval action.

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?

Single sentence, no redundancy, and front-loaded with the core action. Every word is necessary.

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?

Lacks details on return value structure (no output schema), prerequisites, or any additional context needed for a retrieval tool.

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?

Schema has 100% coverage with descriptions for both parameters, but the tool description adds no additional semantic value beyond what the schema already provides.

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?

Clearly states the action (Retrieve) and the resource (specific section of a code map), distinguishing it from sibling 'list_code_map_sections' which lists sections.

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?

Implies usage context ('previously generated code map') but does not explicitly state when to use versus siblings or provide exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_workflow_guideA

Get recommended workflows and best practices for using code auditor tools effectively

ParametersJSON Schema

Name	Required	Description	Default
`scenario`	No	Specific scenario: initial-setup, react-development, code-review, find-patterns, maintenance. Leave empty to see all.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It correctly implies read-only behavior but doesn't explicitly state that no mutations occur or describe the return format. Minimal but not misleading.

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?

Single sentence, zero fluff, front-loaded with the action and resource. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple with one optional parameter and no output schema. The description adequately covers purpose and usage context.

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?

Schema coverage is 100%; the only parameter 'scenario' has a description listing valid values. The description adds no extra meaning beyond the schema, hence baseline 3 is appropriate.

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 retrieves recommended workflows and best practices for code auditor tools, using a specific verb ('get') and resource. It distinguishes from sibling tools like 'audit' or 'config' tools which perform actions rather than provide guidance.

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 for learning best practices but lacks explicit guidance on when to use this tool versus alternatives like 'audit' or 'find_definition'. No when-not or alternative references are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_code_map_sectionsB

List all available sections for a code map

ParametersJSON Schema

Name	Required	Description	Default
`mapId`	Yes	The map ID returned from a previous audit

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without any annotations, the description carries the full burden. It only states 'List', implying a read operation, but does not disclose any behavioral details such as rate limits, data freshness, order of sections, or dependencies beyond the mapId. For a simple list tool, more context would be helpful.

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 purpose with no unnecessary words. Every word contributes.

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 description is too minimal for a tool with one required parameter and no output schema. It does not explain the format of the returned sections, prerequisites (valid audit), or relationship to sibling tools, leaving the agent to infer.

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?

Schema coverage is 100% with the parameter description matching the schema. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 'List all available sections for a code map' clearly states the verb (list) and resource (sections for a code map), distinguishing it from sibling tools like get_code_map_section which likely retrieves a single section.

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 is provided on when to use this tool versus alternatives like get_code_map_section. The parameter description hints at a prerequisite (mapId from previous audit), but no explicit when/when-not or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

project_tasksA

Manage a persistent per-project task queue. Tasks and analyzer configs survive sync_index reset; reset clears function index, cached audits, code maps, and schema overlays (no ghost code references). Use delete to remove a task.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Delete mode: reject (default), detach subtasks, or cascade descendants.
`dueAt`	No	ISO 8601 due datetime for create; omit or null in patch to clear.
`label`	No	Filter/search by label value.
`limit`	No	Max tasks to return for list (default 500, max 1000).
`patch`	No	For update: partial fields (title, description, status, priority, labels, metadata, parentTaskId, source, blockedBy, dueAt, sortOrder, relatedFiles, relatedSymbols).
`query`	No	Case-insensitive text search across title/description/labels/files/symbols.
`title`	No	Task title. Required for create.
`action`	Yes	list \| list_tree \| create \| get \| update \| complete_task \| delete. list/list_tree/create use projectPath or default to process.cwd(); create needs title; get/update/complete_task/delete need taskId; update needs patch object.
`labels`	No	String tags (e.g. ["audit","refactor"]).
`source`	No	manual \| audit \| mcp. Filter for list; provenance for create; can be set via update patch.
`status`	No	pending \| in_progress \| blocked \| done \| cancelled. Filter for list; initial status for create; can be set via update patch.
`taskId`	No	Stable task id (UUID). Required for get, update, complete_task, delete.
`metadata`	No	Arbitrary JSON object: related file paths, links, audit IDs, etc.
`priority`	No	Optional priority for create/update patch.
`blockedBy`	No	Task IDs this item is blocked by (waiting-on).
`sortOrder`	No	Lower numbers sort first within a project (default 0).
`description`	No	Longer description / notes.
`hasChildren`	No	Filter tasks that do/do not have direct subtasks.
`overdueOnly`	No	Filter tasks with dueAt in the past and not closed.
`projectPath`	No	Project root (resolved). Omit to use the MCP server working directory (same default idea as audit path); response includes projectPathDefaulted when omitted.
`parentTaskId`	No	Optional parent task for subtasks.
`relatedFiles`	No	Repo-relative or absolute file paths tied to the task.
`actionableOnly`	No	Filter tasks that are open and unblocked by open dependencies.
`relatedSymbols`	No	Function, class, or component names for cross-linking.
`blockedByTaskId`	No	Filter tasks blocked by this task ID.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses key behaviors (tasks survive reset, what reset clears) but lacks details on side effects of create, update, or list actions. For a tool with 25 parameters and multiple actions, more behavioral context is needed.

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, front-loading purpose and key behavior. Every sentence adds value with no redundancy. It's concise and efficient.

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 tool's complexity (25 params, multiple actions, no output schema), the description is incomplete. It doesn't explain return values, task object structure, or details for each action. Significant gaps remain.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds marginal value by linking 'delete' to the action parameter, but most parameter meaning is already in the schema. The description does not significantly enhance parameter understanding.

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 manages a persistent per-project task queue, distinguishing it from sibling tools like sync_index. It specifies what survives reset and what is cleared, making the purpose unambiguous.

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 provides a clear usage hint ('Use delete to remove a task') and notes that list/list_tree/create use projectPath or default. However, it does not explicitly differentiate when to use this tool over sibling tools, though the context implies it's for task management.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reset_analyzer_configC

Reset analyzer configuration to defaults

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	No	Optional project path to reset only project-specific config
`analyzerName`	No	Specific analyzer to reset, or omit to reset all

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that config is reset to defaults, but does not explain scope (e.g., affects all users or only current session), reversibility, or whether it prompts confirmation. As a destructive action, this is insufficient.

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?

Extremely concise single sentence that front-loads the purpose. However, for a reset action with optional params, a brief second sentence on the return or confirmation would improve completeness without losing conciseness.

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?

Simple tool with 2 optional params and no output schema. The description lacks critical details: what the return value is (e.g., confirmation, status), what happens to other configs during reset, and any side effects. Additional context is needed for safe invocation.

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?

Schema coverage is 100% with clear param descriptions. The tool description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as schema handles documentation, but description misses interaction details (e.g., what happens if both params are omitted).

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?

Clearly states the verb 'Reset', resource 'analyzer configuration', and target 'to defaults'. It distinguishes from 'set_analyzer_config' (which applies specific values) and 'get_analyzer_config' (read), but does not explicitly name alternatives or contrast.

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 alternatives (e.g., set_analyzer_config for partial changes). No mention of prerequisites, caution, or when not to use. Context must be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_codeA

Search indexed functions and React components with natural language queries. Supports operators: entity:component, component:functional|class|memo|forwardRef, hook:useState|useEffect|etc, prop:propName, dep:packageName, dependency:lodash, uses:express, calls:functionName, calledby:functionName, dependents-of:functionName, used-by:functionName, depends-on:module, imports-from:file, unused-imports, dead-imports, type:fileType, file:path, lang:language, complexity:1-10, jsdoc:true|false

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum results to return
`query`	Yes	Search query with natural language and/or operators. Examples: "Button component:functional", "entity:component hook:useState", "render prop:onClick", "dep:lodash", "calls:validateUser", "unused-imports", "dependents-of:authenticate"
`offset`	No	Offset for pagination
`filters`	No	Optional filters (language, filePath, dependencies, componentType, entityType, searchMode). Set searchMode to "content" to search within function bodies, "metadata" for names/signatures only, or "both" for combined search

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It describes the search functionality and operators but does not mention any limitations, performance characteristics, or the read-only nature of the operation. This leaves some gaps in transparency.

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 dense paragraph that includes both the purpose and a long list of operators. It is front-loaded with the main purpose but could be better structured with bullet points or sections for readability.

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 functionality and parameters adequately. However, it lacks information about the output format or structure, which is important since there is no output schema. For a search tool, this is a notable omission.

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?

Schema coverage is 100%, so the baseline is 3. The description adds significant value by explaining the query operator syntax and providing examples, as well as detailing the filters object and searchMode options. This goes beyond the schema 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 that it searches indexed functions and React components with natural language queries. It provides extensive operator examples, making the tool's purpose highly specific and distinguishable from sibling tools, which are audit-related.

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 provides clear usage examples and operator syntax, guiding when to use the tool. However, it does not explicitly mention when not to use it or provide alternatives, though sibling tools are unrelated so differentiation is implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_analyzer_configA

Set or update analyzer configuration that persists across audit runs

ParametersJSON Schema

Name	Required	Description
`config`	Yes	Configuration object for the analyzer (e.g., thresholds, rules)
`projectPath`	No	Optional project path for project-specific config (defaults to global)
`analyzerName`	Yes	The analyzer to configure (solid, dry, security, etc.)

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavioral traits. It mentions persistence but omits side effects, authorization needs, or error behavior, which are important for a mutation 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?

Single sentence that is front-loaded with action and resource, no redundancy or extra words.

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?

Adequate given the tool's complexity; it states purpose and persistence but does not cover return value or error handling, which would be helpful with no output schema.

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?

Schema coverage is 100% with descriptions for all parameters. Description adds no extra meaning beyond schema, so baseline 3 applies.

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?

Description clearly states the tool sets or updates analyzer configuration, a specific verb+resource. It distinguishes from sibling tools like get_analyzer_config and reset_analyzer_config by highlighting persistence across audit runs.

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?

Implied usage for changing persistent analyzer config, but no explicit guidance on when to use vs alternatives like temporary config changes or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start_auditA

Start a background audit job. Returns immediately with a jobId. Poll audit_status until completed, then fetch pages with audit or audit_results.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	File or directory path to audit (defaults to current directory).	/app
`analyzers`	No	Analyzers to run (default: solid, dry, documentation, react, data-access).
`maxRetries`	No	Retry attempts per shard for retryable failures (default: 1).
`minSeverity`	No	Minimum severity level to report.	warning
`workerCount`	No	Number of worker processes for shard execution (default: min(4, CPU-1)).
`jobTimeoutMs`	No	Maximum wall time for the entire audit job (default 30m, env CODE_AUDITOR_JOB_TIMEOUT_MS, cap 4h). Aborts workers cooperatively then tears down.
`maxPartitions`	No	Maximum number of folder partitions for sharded audits (default: 4).
`indexFunctions`	No	Index functions during audit (default: true).
`maxFilesPerRun`	No	Per worker chunk: if more files match than this, the worker finishes one chunk and the parent queues the rest on another worker (optional).
`retryBackoffMs`	No	Base retry backoff in milliseconds (default: 500).
`shardTimeoutMs`	No	Per-shard timeout in milliseconds (default: 180000).
`analyzerConfigs`	No	Analyzer-specific configuration overrides.
`generateCodeMap`	No	Generate code map artifacts during audit (default: false).
`partitionStrategy`	No	Partition mode: none \| auto \| top-level. auto shards when large source trees are detected.	auto
`shardSoftBudgetMs`	No	Per worker soft wall-clock budget; aborts in-process analysis cooperatively via AbortSignal so the parent can assign the next chunk to a fresh worker.
`analyzerConcurrency`	No	Max analyzers to run in parallel (default: 1).
`partitionThresholdFiles`	No	Minimum discovered files before auto partitioning is enabled (default: 250).

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It correctly indicates asynchronous behavior (returns immediately) and the polling pattern. However, it does not mention potential side effects, resource usage, or required permissions. This leaves some ambiguity for a complex background job.

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 extremely concise—two sentences that efficiently convey the tool's purpose and the expected usage workflow. No unnecessary words or repetition.

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 tool has 17 parameters, no output schema, and no annotations, the description could be more complete. It covers the async workflow but omits important context like what the audit results contain, how to interpret the jobId, or any error handling hints. The schema covers parameters, but the overall process is lightly documented.

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?

Schema coverage is 100% with all 17 parameters described in the input schema. The tool description adds no extra parameter context beyond the schema, which already explains default values, enums, and purpose. Baseline of 3 is appropriate.

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 starts a background audit job, returns a jobId, and provides a workflow (poll audit_status, then fetch pages). This distinguishes it from sibling tools like audit, audit_status, etc., which focus on other aspects.

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 explicitly tells the agent to poll audit_status until completion and then fetch pages with audit or audit_results. However, it does not mention when not to use this tool or contrast with alternatives like a synchronous audit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sync_indexA

Synchronize, cleanup, or reset analysis-derived data (indexed functions, FlexSearch, cached audits, code maps, schema overlays). Project tasks, analyzer configs, and whitelist entries are preserved on reset.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	sync: update index from files; cleanup: remove index rows for deleted files; reset: clear all analysis-derived data (not tasks/config/whitelist)	sync
`path`	No	Optional specific path to sync

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully bears the transparency burden. It discloses that reset preserves project tasks, analyzer configs, and whitelist entries. It explains the three modes (sync, cleanup, reset) and their effects. However, it does not mention authorization needs, rate limits, or side effects beyond the described behavior.

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 with no wasted words. It front-loads the main action and then provides key detail about preservation on reset.

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?

Given the lack of output schema and two parameters, the description covers the core behaviors and what is preserved. It could mention whether the tool is idempotent or if there are any performance implications, but it is sufficient for an agent to understand the tool's function.

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% description coverage, with clear explanations for both parameters. The description does not add additional meaning beyond what the schema provides (e.g., it doesn't elaborate on the path parameter's form or expected values). Baseline 3 is appropriate.

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 (synchronize, cleanup, reset) and clearly identifies the resources (analysis-derived data, indexed functions, FlexSearch, cached audits, code maps, schema overlays). It distinguishes from sibling tools like audit or get_code_map_section by focusing on sync/reset operations.

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 tells what the tool does but does not explicitly state when to use it versus alternatives. However, the context of sibling tools (audit, get_code_map_section, etc.) and the clear mode descriptions implicitly guide usage. No exclusions or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

16 tool updatesv2.6.2Jul 17, 2026
- First observedaudit
- First observedaudit_health
- First observedaudit_results
- First observedaudit_status
- First observedfind_definition
- First observedgenerate_ai_config
- First observedget_analyzer_config
- First observedget_code_map_section
- First observedget_workflow_guide
- First observedlist_code_map_sections
- First observedproject_tasks
- First observedreset_analyzer_config
- First observedsearch_code
- First observedset_analyzer_config
- First observedstart_audit
- First observedsync_index

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose; even closely related tools like audit and audit_results are separated by 'results' vs 'violations', and descriptions clarify usage without ambiguity.

Naming Consistency5/5

All tool names use consistent snake_case and mostly follow a verb_noun pattern (e.g., search_code, start_audit), with no mixing of naming conventions.

Tool Count4/5

With 16 tools, it slightly exceeds the typical 3-15 range, but the comprehensive code auditing domain justifies the count, covering audit lifecycle, config, search, code maps, tasks, and maintenance.

Completeness4/5

Core workflows are well-covered (audit start/status/results, config CRUD, search, code maps), though missing a stop audit or list all audits option, which are minor gaps.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Symvanta A
com.symvanta
Hosted code graph over MCP: exact callers, dependencies, and cross-repo blast radius for AI agents.
251
Maguyva
ai.maguyva
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code Analysis Coding Agents
23
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312
ContextStream BOAuth
io.contextstream
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Knowledge & Memory Developer Tools
30241

Related MCP Servers

ACE-MCP
Code Analysis Search RAG Systems
0215AndrewFeng
A
license
Not graded
quality
B
maintenance
Enables AI clients to perform local code search, indexing, and analysis across Java, JavaScript/TypeScript, .NET/C#, and Python projects through the MCP protocol.
Updated 9 days ago (2026-08-28 03:01 UTC)
1
Apache 2.0
OpenCodeHub MCP Server
Code Analysis Knowledge & Memory
theagenticguy
A
license
Not graded
quality
A
maintenance
Provides code intelligence for AI coding agents by indexing repositories into a hybrid knowledge graph, enabling agents to query dependencies, impact, and context through 28 MCP tools.
Updated 25 days ago (2026-08-12 08:20 UTC)
3
Apache 2.0
Cortex
RAG Systems Vector Databases Knowledge & Memory
Remskill
A
license
Not graded
quality
D
maintenance
Enables AI coding assistants to semantically search and retrieve relevant code patterns, documentation, and implementations from a codebase via MCP tools.
Updated 8 months ago (2026-01-07 13:16 UTC)
7
MIT
codegraph
Code Analysis Developer Tools Knowledge & Memory
bajpayeeritik
A
license
Not graded
quality
B
maintenance
Indexes a codebase into a live symbol graph and serves it via MCP to AI coding tools for context-aware code queries.
Updated 2 months ago (2026-07-08 06:44 UTC)
35
1
MIT

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/BenAHammond/code-auditor-mcp'

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