> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kipmox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tools

> The two kipmox Agent tools — analyze_code and verify_fix — their inputs, verdicts, and how they use your custom rules.

kipmox Agent exposes two MCP tools. Your agent calls them; you don't invoke them by hand. This page is the reference for what each takes and returns.

Both tools work on **Apex** (`.cls`, `.trigger`), **LWC JavaScript** (`.js`), and **LWC templates** (`.html`), and both require a paid kipmox plan with Agent access.

## analyze\_code

Runs kipmox's deterministic Salesforce static-analysis rules over a piece of code and returns structured findings. Use it before writing or reviewing Salesforce code; after applying a fix, call [`verify_fix`](#verify-fix).

**Inputs**

| Field | Type | Description |
| - | - | - |
| `code` | string | The full source of the file to analyze. |
| `language` | `"apex"` \| `"javascript"` \| `"html"` | File language — `apex` (`.cls`/`.trigger`), `javascript` (LWC `.js`), or `html` (LWC template). |
| `filePath` | string | The file path, e.g. `force-app/main/default/classes/AccountService.cls`. Used for reporting and to scope LWC rules. |

**Returns** — a list of findings, each with a `findingId`, `ruleId`, `line`, `message`, and a deterministic remediation hint, plus a short summary.

<Note>
  **LWC rules only fire when the `filePath` contains `/lwc/`.** Pass the real project path (not a bare filename) so LWC-specific rules apply correctly.
</Note>

## verify\_fix

Deterministically verifies a proposed fix **before it's applied** — independently of the model that wrote it. It re-runs the rules on the original vs proposed code, detects regressions and band-aid fixes (code commented out to fake a pass), flags behavioural and contract changes, and returns a verdict.

**Inputs**

| Field | Type | Description |
| - | - | - |
| `findings` | array | The findings this fix was meant to resolve — each `{ findingId, ruleId, line? }`, taken from `analyze_code`. |
| `originalCode` | string | The full original file content, before the fix. |
| `proposedCode` | string | The full proposed file content, after the fix — verified **before** you apply it. |
| `language` | `"apex"` \| `"javascript"` \| `"html"` | File language. |
| `filePath` | string | The file path — used for rule scoping and to locate the project/ruleset. |
| `rawModelResponse` | string *(optional)* | The raw model response, for extra structural validation of the fix. |

### Verdicts

`verify_fix` returns one of four verdicts. The overall verdict is **worst-status-wins** across every check and tier, and it never reports a finding as *resolved* if it couldn't actually be re-checked.

| Verdict | Meaning |
| - | - |
| **checks-passed** | The targeted rules no longer fire and nothing new broke. Still worth a glance before applying. |
| **review-recommended** | The checks couldn't fully clear the fix — read it before applying. |
| **validation-failed** | A check proved the fix is wrong, regressed, or introduced an error. Don't apply as-is. |
| **unable-to-verify** | The fix couldn't be validated (for example, a malformed response), so no checks ran. |

<Info>
  A clean loop tells the agent to **rewrite and re-verify** until the verdict is `checks-passed` — for example: *"…fix the issues, then verify with kipmox; if it doesn't pass, revise and verify again."*
</Info>

### What it catches

* **Rule re-run** — the same rules that flagged the issue, run again on the proposed code.
* **Regressions** — new issues introduced elsewhere by the change.
* **Band-aid fixes** — code commented out or deleted to fake a resolution rather than actually fixing it.
* **Change signals** — behavioural and contract changes (e.g. SOQL/DML shifts, Apex signature changes) worth a human's eyes.

For the full picture of the checks and how they map to confidence and risk, see [How Fixes Are Verified](/trust/how-fixes-are-verified).

## Custom rules

When your project has a **Salesforce Code Analyzer** configuration, kipmox uses it — running your ruleset (including custom PMD rules) **on top of** kipmox's native rules, and applying it when it *verifies* a fix, not just when it analyzes.

* kipmox **auto-detects** your `code-analyzer.yml` from the file's project. If it can't find it, set `KIPMOX_ANALYZER_CONFIG` to its path.
* Custom-ruleset checks need the **Salesforce CLI** with the `code-analyzer` plugin and **Java 11+**. Without them, kipmox degrades to its native rules — it never fails the tool.
* Override the CLI binary with `KIPMOX_SF_CLI`, or the rule selector with `KIPMOX_RULE_SELECTOR`.

<Note>
  Custom-ruleset analysis is applied when a config is present, keeping `analyze_code` fast by default. `verify_fix` always runs both tiers when the toolchain and project allow, so your own rules are enforced on the fix.
</Note>

<CardGroup cols={2}>
  <Card title="Code Analysis Rules" icon="list-check" href="/reference/code-analysis-rules">
    The native Salesforce rules kipmox ships with
  </Card>

  <Card title="Troubleshooting" icon="life-ring" href="/agent/troubleshooting">
    Custom rules not applying, and other issues
  </Card>
</CardGroup>