Jarroba Tools

Jarroba Tools MCP

Local MCP servers (stdio) that give an AI the deterministic tools of Jarroba Tools so it computes answers instead of inventing them. Everything runs on your machine: the host launches the server as a subprocess and talks over stdin/stdout. There is no network, no endpoint, no account.

The tools reuse the same logic as the web app — the services, without Angular — so there is no second implementation to drift.

Four packages, because context is not free

Loading all 149 tools costs ~61,100 tokens of context before you type anything, in a client that loads every tool definition up front (Cursor and most others; Claude Code with Tool Search turned off). That is Claude Code's own count: measured with /context on 0.1.7 (120 tools: 41,996 tokens) and extrapolated with npm run tokens. Claude Code's Tool Search, on by default, only loads a definition when it is about to be used: there the whole catalogue costs a few hundred tokens. GitHub's official MCP server is the usual example of the problem; Cursor caps out around 40 tools. A catalogue of 149 is not "more complete", it is more expensive — and the model also *chooses* worse, because the usual failure of a big catalogue is not a missing tool, it is calling the one next to it.

So pick the one you actually want:

All four come from the same source. The filter is the JARROBA_MCP_DOMAINS environment variable and each binary sets its own as a default, not a cage: install mcp-logs and add JARROBA_MCP_DOMAINS=logs,core if you want the general-purpose tools too. Domains: core, calc, diagram, kg, db, ai, logs, queue, project, tests, api, chip, chem, access, archsim, security, experiments, business, forecast. (payroll, its name in 0.3.0, still works.)

A newer complement, not a replacement: Tool Search

Since January 2026 Claude Code defers full tool schemas by default and loads them only when the model decides to search for them — Anthropic reports large context savings on big catalogues in their own benchmarks. That does not make the package split above pointless: under deferral, tool *names* and the server's own instructions still load at session start, so a 103-tool server still costs more baseline than an 11-tool one, and not every MCP client defers automatically (some require the caller to opt a tool in explicitly; older or other clients load everything upfront regardless). It is also why every server here now sets a concise instructions field — under deferral, that field is the only text that tells the model *when* to search here at all.

Install

// Claude Desktop (claude_desktop_config.json), Cursor, Cline, VS Code…

{ "mcpServers": { "jarroba-logs": { "command": "npx", "args": ["-y", "@jarroba/mcp-logs"] }, "jarroba-tests": { "command": "npx", "args": ["-y", "@jarroba/mcp-tests"] } } }

# Claude Code

claude mcp add jarroba-logs -- npx -y @jarroba/mcp-logs

npx downloads the package to your machine and runs it there. Nothing is uploaded.

---

What is actually different here

Most of this catalogue is arithmetic a model gets wrong. Two parts of it are something else.

Reading a log that does not fit in your context

The log tools accept a file path, not just pasted text. That is the whole point: a production or CI log is tens or hundreds of MB and will never fit in a tool call — but the server runs in Node, so it can open the file itself and hand back only what fits. An agent debugging a red CI run cannot read the log; it can ask questions about it.

• `log_analyze` — format, number of events (a 40-line stack trace counts as one), levels, time range, errors with their root cause resolved, most frequent patterns.
• `log_reduce` — cut to a character budget keeping errors with their full trace, the window before, and whatever appears only once. Repeats collapse to [xN].
• `log_patterns` — group lines into templates (Drain): "connected to 10.0.0.1" and "connected to 10.0.0.7" are one message. Also returns the rare ones, which is usually what you wanted.
• `log_trends` — answers *when did it start*, comparing each pattern against itself rather than total volume. Returns what spiked, what is new, and what stopped appearing — the last one raises no counter anywhere and is often the worse news.
• `log_around` — what else clustered around a moment. What started before is a candidate explanation; what came after is usually a consequence.
• `log_distinguish` — what sets a group of events (the errors, by default) apart from the rest: the field=value pairs over-represented in it, like the version all the failures share.
• `log_stacktrace` — Java/JVM, Python, Node, Go, .NET, Rust, Ruby, PHP: the Caused by chain, the root cause, and the first frame of your code.
• `log_lint` — whether the log is *well written*: secrets printed, one line flooding the file, timestamps with no time zone, the clock going backwards, no request id.
• `log_convert` — JSON / logfmt / syslog 5424 / CSV / OpenTelemetry / ECS, saying up front what the conversion loses.
• `log_rotation` — put rotated logs in time order. Rotation numbering runs backwards against time, and alphabetically app.log.10 sorts before app.log.9. Use it first, or you read them backwards.
• `log_profile_check` / `log_profile_suggest` — a reusable profile describing how your team's logs look. check returns every error with its exact field so a model can correct itself.

Tools that contradict the caller

Told to *"make the tests pass"*, an agent has two roads: diagnose the bug, or widen the matcher / drop the assertion / skip the case. The second is cheaper. A better model does not fix that and neither does asking nicely in a prompt — it needs a judge outside the model. This is the only part of the catalogue that exists to disagree with whoever calls it. Run it on your own work.

• `test_audit` — case by case, what a test file *actually* asserts: which assert about a value, which only check that something exists, which assert nothing, which are disabled — with the evidence for each verdict. TypeScript, JavaScript, Python, Java, Go.
• `test_diff_audit` — compare two versions and say whether the change weakened the safety net: widened matchers, vanished assertions, cases that stopped running.
• `test_cases` — from a type to the cases worth writing, saying which technique applies and why (boundary values mean nothing without an ordering, so a boolean does not get them), plus the five that matter most if you only have time for five.
• `test_debt` — every disabled test with its age, from git blame. None of these appears in a coverage report, because for the runner they do not exist.

It does not accuse lightly: a matcher it does not recognize comes back as "indeterminate", never as "asserts nothing". If your team has a home-made expect(), declare it in dialects.

---

The rest of the catalogue

Available in @jarroba/mcp, or by widening JARROBA_MCP_DOMAINS.

Diagrams (`diagram`, 8) — JTD is a JSON format for an AI to author a diagram. diagram_svg renders it in plain Node so the model can actually see the drawing; the incremental builder (diagram_new / _add / _preview) lets it build in pieces and look in a loop, which is the only way it can judge its own output. mermaid_validate runs Mermaid's own parser (the version the web uses) on Mermaid code and returns the error with its line, column and expected tokens — models write Mermaid that does not render (unquoted parentheses, end as an id, a % in a pie) and fix it on their own once they see the parser's error. It parses only; the parser ships as a separate file loaded on first use, so it costs nothing until then.

Databases (`db`, 9) — SQL text becomes a real schema by executing the DDL in an ephemeral PostgreSQL (pglite), not by guessing with regular expressions: translate a dump from MySQL/SQLite/SQL Server/Oracle, review the design, generate docs or entity classes. Three of them look at the data, not the structure: which join path actually returns rows, which foreign keys the data supports (counted, not guessed), and row-level-security checks that catch the silent failures — plus a simulation of what a given role can really see, inside a transaction that is rolled back. db_query_check runs a query against your schema — does it run, which columns and types it returns — and, given compareWith, finds the smallest data where two queries disagree (the NOT IN with a NULL), with its INSERTs. db_migration_measure runs a migration on top of your schema and measures the lock each statement actually takes (pg_locks), whether it rewrites or fully scans the table, and writes the safer version (CONCURRENTLY, NOT VALID + VALIDATE, lock_timeout…) — instead of guessing lock levels. Pass your application's queries and it also says which ones the migration breaks or changes.

Knowledge graphs (`kg`, 4) — SPARQL 1.1, SHACL and a "semantics as code" layer over Oxigraph (WASM, no server), so a metric like "revenue" is computed from the agreed definition rather than a query someone invented.

AI about AI (`ai`, 8) — deterministic and model-free, which is what makes them useful here: an AI can review its own system prompt, prepare a RAG corpus, run its own answer through a claim/source check, verify the eval suite it just wrote, or audit the catalogue of an MCP server it is deciding whether to install — and, given the tools/list it approved earlier, catch a "rug pull" (tools that changed after approval) — without spending a model call. And before recommending a practice it learned in training, practice_check tells it whether that practice still holds — superseded by what, since when, how sure — from a dated register; given its knowledge cutoff, only what changed after it. Two for serving: llm_memory says whether a model fits a GPU (weights by quantization, the KV cache that grows with context, the longest context that fits and the decode speed ceiling), and semantic_cache_threshold picks a semantic cache's similarity threshold from pairs measured with your own embedding model.

Project workshop (`project`, 11) — simulate make without running it and say why each target rebuilds; compare a real make log against that prediction (a target rebuilt when the simulation said "cached" is the signature of an undeclared dependency); git check-ignore -v without git, including where git and Docker disagree about the same file; and which Docker layers a change invalidates. dora_metrics computes the four DORA metrics from gh run list JSON (and git log for lead time), says why each failed deploy counts as failed, and classifies the team against every State of DevOps report 2019-2024 — saying "ambiguous" when a report's table does not decide. maven_plan says what mvn runs in a project without running Maven — reactor order, phase by phase, and where each goal comes from (packaging, your pom, the parent, a profile) — verified goal by goal against real mvn logs; gradle_plan reads a --dry-run output and gives each task's Maven equivalent. code_smells finds eight code smells in JS/TS (long function, long parameter list, conditional on type, message chain, large class, feature envy,