otter-kr
This server exposes a single read-only, idempotent research tool that performs deterministic Python and Git evidence gathering on a repository and rejects unsupported operations.
Repository inspection: Provide
repository_root(absolute or runtime-relative) and anoperationname; optional parameters includepath,term,limit,lines,left_path,right_path, andsince_unix_time.Python evidence: Tracked-file inventory, parse health, names, imports, tests, complexity, repeated literals/groups, structural duplicates, type discriminations, neighborhoods (exact/structural/historical/behavioral), graph topology, and seed-scoped carrier guards.
Composite operations: Seed evidence, term-change evidence, representation inventories, and review packets.
Git evidence: Bounded history, snapshots, hotspots, normalized co-change (global/file/pair scope), branch additions, temporal/commit-message distributions, topic commits and hunks, first-parent topic walks and families, rename identity, and line origins.
Safety and boundaries: Does not execute target code, infer semantics, score quality, or recommend refactorings; invalid/unupported requests get structured rejections.
Deterministic output: Reports include explicit query bounds, stable ordering, source locations, warnings, and provenance.
Provides evidence operations for Git repositories, including bounded history, snapshots, hotspots, co-change analysis, branch additions, commit-message distributions, topic commits, rename identity, and line origins.
Provides evidence operations for Python source code, including tracked-file inventory, parse health, names, imports, tests, complexity, repeated literals, structural duplicates, type discriminations, neighborhoods, and graph topology.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@otter-krFind all occurrences of 'payment_processor' in /home/user/project"
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.
otter-kr
Deterministic source-repository evidence for coding agents, exposed through FastMCP. The evidence layer answers what exists in a repository; the calling agent remains responsible for interpretation and engineering judgment.
Current capability
One stateless research tool dispatches deterministic Python and Git evidence operations. Current
Python evidence covers tracked-file inventory and parse health, names, imports, tests, complexity,
repeated literals and groups, structural duplicates, type discriminations, exact/structural/
historical/behavioral neighborhoods, graph topology, and seed-scoped carrier guards. Composite
operations project seed evidence, term-change evidence, representation inventories, and review
packets without adding design judgments.
Git evidence covers bounded history, snapshots, hotspots, normalized co-change at global/file/pair scope, branch additions, temporal and commit-message distributions, topic commits and hunks, first-parent topic walks and families, rename identity, and line origins. Reports retain explicit query bounds, stable ordering, source locations, warnings, and provenance. Unsupported or invalid requests return structured rejections rather than widening the analysis silently.
The product remains Python-only and evidence-only: it does not import or execute target code,
infer semantic concepts, assign quality scores, or recommend refactorings. The detailed admission
boundaries and remaining research work live in BACKLOG.md.
Related MCP server: semhood
Develop with uv
Install the pinned environment and run all checks:
uv sync
uv run pytest
uv run ruff check .
uv run ruff format --check .Run the stdio server:
uv run otter-krAn MCP client can launch it from any directory with an entry like this (replace the path):
{
"mcpServers": {
"otter-kr": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/otter-kr",
"run",
"otter-kr"
]
}
}
}Call research with repository_root set to an absolute or runtime-relative repository directory,
an admitted operation, and that operation's explicit query fields. For example,
python.names requires term, while bounded Git operations require since_unix_time and limit.
Design boundary
Repository analysis lives in framework-independent modules under src/otter_kr. The MCP server
only validates transport inputs and presents structured results. Language is explicit in each
report, leaving room for analyzers for other languages without changing the evidence contract.
Available Tools
1 toolresearchResearch a repositoryCRead-onlyIdempotent
Dispatch admitted research operations and reject the remainder.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| term | No | ||
| limit | No | ||
| lines | No | ||
| left_path | No | ||
| operation | Yes | ||
| right_path | No | ||
| repository_root | Yes | ||
| since_unix_time | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so this is known to be a safe, repeatable operation. The description adds the behavioral detail that unsupported operations are rejected rather than silently ignored, which is useful but not elaborated in terms of error handling or authorization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no filler, but the phrase 'Dispatch admitted research operations and reject the remainder' is stilted and under-specified. It is concise in word count but not structured in a way that clearly separates core purpose from constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 0% schema description coverage, and no enums or examples, the description is far too incomplete for an agent to select it and invoke it correctly. The output schema exists, but input semantics are almost entirely undocumented, so the tool cannot be used reliably from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the 9 parameters. It only vaguely alludes to 'operations,' but gives no meaning for repository_root, term, path, limit, lines, since_unix_time, or the required operation values, so an agent cannot construct a correct call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Research a repository' supplies a general purpose, and the description adds that only 'admitted research operations' are dispatched while others are rejected. However, 'admitted research operations' is never defined, and the verb 'dispatch' is vague about what actually happens to the repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There are no sibling tools or alternative routes mentioned, and the description does not explain when an agent should choose this tool or what conditions make an operation 'admitted.' The reader is left to infer the intended usage from the title.
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.
1 tool update
v0.1.0- First observed
research
TDQS
Scored across 1 tool
With only one tool, there is no possibility of overlap or misselection. The single tool is unambiguous as the only entry point.
The lone tool name 'research' is a bare word and does not establish a predictable verb_noun convention. There is no inconsistency, but there is also no coherent pattern to evaluate.
One tool is on the thin side, but the narrow admission/dispatch purpose could plausibly be served by a single operation. The surface feels minimal rather than well-scoped.
The server only dispatches admitted research operations and rejects the remainder. There are no tools for submitting, admitting, listing, or tracking research operations, so the surface is severely incomplete for a research workflow.
Maintenance
Related MCP Connectors
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Related MCP Servers
- AlicenseDqualityCmaintenanceProvides deterministic Python codebase symbol exploration using AST parsing, with tools for definition lookup, signatures, references, call chains, and class hierarchy queries.6MIT
- AlicenseNot gradedqualityCmaintenanceAST-aware semantic code search engine for AI agents, enabling code retrieval by intent with call-graph context and optional LLM enrichment.1MIT
- FlicenseNot gradedqualityAmaintenanceProvides efficient code navigation and graph-based analysis for AI agents, enabling symbol resolution, callers, implementations, and type schemas with minimal token usage.-
- FlicenseNot gradedqualityCmaintenanceEnables coding agents to query a local-first code intelligence graph of Python repositories—covering functions, classes, modules, and their relationships—via MCP, supporting subgraph retrieval, caller lookup, and impact analysis without re-reading the codebase.-