Skip to main content
Glama
tottinge

otter-kr

by tottinge
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

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

Operation-specific stateless tools expose deterministic Python and Git evidence operations. The legacy research tool remains as a compatibility router for clients that cannot yet select typed tools directly. 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, seed-scoped carrier guards, and external field affinity. 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

Evidence layer for refactoring skills

otter-kr is intended to provide citeable, deterministic evidence for otter-skills and other refactoring skills. It reports facts such as locations, counts, relationships, and history; an LLM or human uses those facts to make and validate design decisions. The MCP deliberately does not replace the reasoning, representation, testing, or refactoring skills that consume its evidence.

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-kr

An 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"
      ]
    }
  }
}

Prefer the operation-specific tools, such as python_inventory, python_names, and git_history. Each typed tool names its required inputs directly: python_names requires term, while bounded Git tools require since_unix_time and limit. The compatibility research router accepts the same admitted operations and fields for older clients.

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 tool
researchResearch a repositoryC
Read-onlyIdempotent

Dispatch admitted research operations and reject the remainder.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNo
termNo
limitNo
linesNo
left_pathNo
operationYes
right_pathNo
repository_rootYes
since_unix_timeNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.3/5.0
Behavior3/5

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.

Conciseness3/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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. 1 tool updatev0.1.0
    • First observedresearch
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.5/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of overlap or misselection. The single tool is unambiguous as the only entry point.

Naming Consistency3/5

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.

Tool Count3/5

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.

Completeness1/5

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

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-ast-explorer

    LovRanRan
    A
    license
    D
    quality
    D
    maintenance
    Provides deterministic Python codebase symbol exploration using AST parsing, with tools for definition lookup, signatures, references, call chains, and class hierarchy queries.
    6
    MIT

  • semhood

    AhmeedGamil
    A
    license
    Not graded
    quality
    C
    maintenance
    AST-aware semantic code search engine for AI agents, enabling code retrieval by intent with call-graph context and optional LLM enrichment.
    1
    MIT

  • RepoImpact MCP Server

    ManaswiniGupta
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables LLMs to analyze Python repositories structurally via AST and call graphs, providing code search, symbol lookup, change-impact analysis, workflow tracing, and explanation without embeddings.
    -