# Evaluating CodeCall

> Compare the same CRM task through direct tool calls and CodeCall. Measure bytes and calls, separate discovery overhead, and record model evaluation independently.

Source: https://frontmcp.dev/learn/evaluating-codecall

[Covers FrontMCP 1.10.10](https://frontmcp.dev/versions#how-pages-are-checked) as of October 22, 2026

Choose CodeCall after measuring the workload you need to support. This evaluation uses the published 47-tool CRM, the same synthetic data and the same deterministic task through direct calls and a server-side script. It checks that both paths return the same answer. It does not measure model tokens, hosted latency, cost or a model's ability to write the script.

<a id="run-the-fixture"></a>

## Run the fixture

[Download the evaluation project](https://frontmcp.dev/downloads/crm-evaluation.tgz), extract it, and follow its README. Dependencies and the fixture are pinned. In the site checkout, run:

```bash
node scripts/evaluate-codecall.mjs --runs=5
```

The harness removes only the plugin registration for the direct baseline. Both servers use the same tool implementations. A scripted client supplies the same selection logic a model would need to produce. The small-catalog control performs a single direct lookup; it avoids pretending every task benefits from script execution.

<a id="read-the-output"></a>

## Read the output

| Field | What it measures | What it cannot establish |
| --- | --- | --- |
| catalog bytes | UTF-8 bytes of JSON tool definitions | Model tokenizer counts or billing |
| direct response bytes | Sum of result envelopes from the underlying calls | Which content a particular client includes in its prompt |
| discovery response bytes | Search and schema response envelopes | Free or zero-overhead discovery |
| CodeCall response bytes | The execution result envelope | Total context use without discovery and request sizes |
| direct calls / execution calls | Requests made by the scripted fixture | Number of model reasoning steps |
| directMs / scriptMs | In-process time after server startup | Cold deployment or hosted-model latency |

Runs are sequential after startup; initial and later calls can differ because of cache state. The output records each sample instead of reducing variability to one flattering number. Compare results before aggregating them. A failed assertion exits unsuccessfully; do not exclude incorrect results from an evaluation.

<a id="add-a-model-evaluation-deliberately"></a>

## Add a model evaluation deliberately

Record the exact prompt, model/version, settings, catalog, client behavior, execution limits, and a fixed task set. Include simple lookups, joins, ambiguous requests and refused operations. Measure actual input/output tokens, tool requests, answer correctness and wall time for repeated cold and warm runs. Keep API price arithmetic dated and separate from those observations.

Publish failures and limits alongside results. Do not extrapolate a fixture's byte reduction to a percentage token saving, security certification or universal speedup. Tool authorization still applies in both paths; read [CodeCall's limits](https://frontmcp.dev/reference/plugins/codecall) before enabling scripts.

<a id="next-step"></a>

## Next step

Inspect [the complete CRM](https://frontmcp.dev/examples/crm-with-codecall), then replace its synthetic data with your own read-only workload. If direct calls already produce a small answer, keep that simpler path.