Labsco
rokasklive logo

OpenGrok Go MCP

β˜… 1

from rokasklive

Source-code intelligence for agents, powered by OpenGrok and Go.

πŸ”₯πŸ”₯πŸ”₯πŸ”₯βœ“ VerifiedFreeQuick setup
opengrok-go-mcp mascot

opengrok-go-mcp

Source-code intelligence for agents, powered by OpenGrok and Go.

I have seen things you people wouldn’t grep. β€” Senior Architect, probably.



Agent-oriented MCP server for searching, navigating, and reading code through OpenGrok.

It turns OpenGrok into a safer code-intelligence surface for LLM agents:

  • capability-gated tools that only appear when the backing OpenGrok feature works
  • paginated search and file reads with stable cursors
  • citation URLs on code results so answers can point back to source
  • warnings for broad, heuristic, truncated, or best-effort results (warnings[] codes plus a legacy warning string)
  • automatic context expansion around search hits with explicit limits
  • full, compact, and experimental gateway tool surfaces for different agent styles

If you are an AI agent reading this repository, start with AGENTS.md for project constraints and agent workflow guidance.

Pre-1.0 note: this MCP server is still evolving. Some tools, responses, and configuration paths may be broken or change before a stable 1.0 release. Please report issues using docs/reporting-issues.md.

When To Use It

Use opengrok-go-mcp when you want an agent to investigate a large indexed codebase without cloning it locally. It works best for finding symbols, reading files, tracing references, narrowing broad searches, and producing answers with source citations.

It is intentionally honest about OpenGrok's limits. OpenGrok provides full-text search plus ctags definitions, not a full semantic call graph or AST engine. For structural questions, use this server to find the right files and symbols, then verify relationships with language-aware tools when needed.

Security

Avoid passing secrets as CLI flags. Use OPENGROK_MCP_API_TOKEN for OpenGrok auth; the server never logs token values.

Operational caveats:

  • HTTP mode does not add inbound client authentication. Keep the default loopback bind address or put it behind trusted network/auth controls.
  • OPENGROK_MCP_INSECURE_SKIP_TLS_VERIFY=true is only for controlled internal instances with broken certificates. Do not use it for public or untrusted hosts.
  • Raw file fallback uses OPENGROK_MCP_WEB_BASE_URL with the same configured credentials. Treat that URL as part of the trusted OpenGrok boundary.
  • Memory tools are full-surface only (stdio). They are process-scoped, ephemeral, and disabled over HTTP because memory is not isolated by client session.
  • Set OPENGROK_MCP_CURSOR_SECRET for shared deployments if cursor integrity matters.

Evaluation

Hermetic stdio evals in evals/ β€” real MCP binary, fake OpenGrok backend, no live instance. CI runs them on every PR (ci.yml). README summaries and Ξ” columns compare against committed baselines in evals/baselines/. Refresh locally with scripts/update-eval-results.sh; the optional pre-push hook (scripts/install-githooks.sh) runs tests and updates those files before you push.

go test ./evals/ -count=1                        # contract + token benchmark
go test ./evals/ -run TestEvalSuite -count=1      # MCP contract only
go test ./evals/ -run TestTokenBenchmark -count=1 # token economy only

How to read the tables below

  • Contract eval β€” hermetic MCP calls against a fake OpenGrok backend; checks outputs, errors, and pagination fields. Ξ” is change vs the committed baseline in evals/baselines/. coverage@K is the fraction of eval cases exercised.
  • Token benchmark β€” same harness, but measures UTF-8 bytes crossing the MCP wire (tool schemas, requests, responses). Est. tokens = bytes Γ· 4 (rough heuristic, not a specific model tokenizer).
  • Surface β€” full (fine-grained tools), compact (4 consolidated tools, default), or gateway (experimental discover + call).
  • ListTools β€” one-time cost when the client loads the tool list and schemas at session start; usually the largest line item on full.
  • Warm total β€” ListTools plus all tool calls in a scenario (request + response bytes). For gateway, warm excludes the one-time opengrok_discover call; cold includes it (first session only). On full and compact, cold = warm.
  • Min–max β€” range across the four replay scenarios (symbol lookup, file browse, multi-step symbol search, search-and-read). Per-scenario breakdown is in the collapsed table.
  • Ξ” on token rows β€” change in estimated tokens vs the last committed baseline (evals/baselines/token_report.json).

Contract eval

Last run: 2026-06-25 Β· direct-call Β· harness docs β†’

10/10 passed Β· 100% (Ξ” Β±0) Β· 100% coverage@K β€” see How to read the tables for Ξ” and coverage@K.

Per-tool scores
ToolScoreCases
get_file_context100% (Ξ” Β±0)1
list_projects100% (Ξ” Β±0)1
list_symbols100% (Ξ” Β±0)1
read_file100% (Ξ” Β±0)1
search_code100% (Ξ” Β±0)4
search_symbol_definitions100% (Ξ” Β±0)1
search_symbol_references100% (Ξ” Β±0)1

Token economy benchmark

Last run: 2026-06-25 Β· deterministic-replay Β· est. tokens = bytesΓ·4 (heuristic, not model-exact)

ListTools dominates session cost on the full surface (18 tools). Compact (4) and gateway (2) register far fewer schemas.

SurfaceListTools (est. tokens)Warm total min–max (est. tokens)
full14k (Ξ” +724)15k–16k (was 14k–15k)
compact6.8k (Ξ” +3.3k)7.7k–10k (was 4.4k–6.8k)
gateway261 (Ξ” Β±0)1.2k–2.3k (was 1.2k–2.1k)

Warm = ListTools + scenario tool traffic. Gateway warm omits one-time discover; full/compact cold = warm. Compact file-exploration skips files.list (no compact op).

Per-scenario warm totals (est. tokens; ListTools + calls)
Scenariofullcompactgateway
Compound symbol16k (Ξ” +911)8.3k (Ξ” +3.5k)1.8k (Ξ” +187)
File exploration15k (Ξ” +779)7.7k (Ξ” +3.3k)1.2k (Ξ” +56)
Symbol investigation (3 calls)16k (Ξ” +927)8.7k (Ξ” +3.5k)2.3k (Ξ” +203)
Search + read15k (Ξ” +834)7.9k (Ξ” +3.4k)1.4k (Ξ” +109)

Ξ” vs baseline from 2026-06-24.

Development

This project uses GitHub Spec Kit for non-trivial feature planning.

For meaningful behavior changes, new MCP tools, schema changes, configuration changes, or changes that affect agent-facing behavior, contributors should start from the project constitution:

  • .specify/memory/constitution.md

Feature work should generally produce:

  • specs/FEATURE/spec.md
  • specs/FEATURE/plan.md
  • specs/FEATURE/tasks.md

Small bug fixes, documentation edits, dependency bumps, and mechanical refactors do not require a full Spec Kit workflow unless they affect the public MCP contract.

All changes must preserve the MCP contract, OpenGrok semantics, security posture, compatibility expectations, and documentation requirements described in the constitution.