Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.SurajKGoyal/myopic

PYPI · MYOPIC · SCANNED SEP 20

Code-review MCP: review a GitLab MR or GitHub PR against the whole codebase, not just the diff.

Available components

0 this week 75 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security100
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
  • 7 of 62 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency32
Schema Quality & AI Usability62
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 4542 tokens (~378/item across 12 items; 12 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management87
  • Stability observed for 26 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage67
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 0% of tool parameters carry a description.Fail
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the io.github.SurajKGoyal/myopic MCP server?

io.github.SurajKGoyal/myopic runs locally as a PyPI package, launched with uvx myopic. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · myopic

# add to Claude Code
claude mcp add surajkgoyal-myopic -- uvx myopic
// .cursor/mcp.json
{
  "mcpServers": {
    "surajkgoyal-myopic": {
      "command": "uvx",
      "args": [
        "myopic"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "surajkgoyal-myopic": {
      "command": "uvx",
      "args": [
        "myopic"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add surajkgoyal-myopic -- uvx myopic
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "surajkgoyal-myopic": {
      "type": "local",
      "command": [
        "uvx",
        "myopic"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add surajkgoyal-myopic --command uvx --arg myopic
# ~/.hermes/config.yaml
mcp_servers:
  surajkgoyal-myopic:
    command: "uvx"
    args: ["myopic"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "surajkgoyal-myopic": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "myopic"
      ]
    }
  }
}
# add to Vellum
assistant mcp add surajkgoyal-myopic -t stdio -c uvx -a myopic
// mcp.json
{
  "mcpServers": {
    "surajkgoyal-myopic": {
      "command": "uvx",
      "args": [
        "myopic"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 20 Sept 26 0
    • Package version: 0.1.10 → 0.1.11 functional
  • 19 Sept 26 −2
    • Stability: pass → 0.83 functional
  • 18 Sept 26 +15
    • Malware scan: unverified → pass security
    • Stability: 0.97 → pass security
  • 17 Sept 26 −14
    • Malware scan: pass → unverified security
  • 16 Sept 26 +15
    • Malware scan: unverified → pass security
  • 15 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

  • 14 Sept 26 −15
    • Malware scan: pass → unverified security
  • 13 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 20 Sept 2026 · Analysed pypi/myopic@0.1.11

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem pypi

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend allowlisted hatchling.build

Background: Why install scripts are a supply-chain risk →

Dependencies 62 packages
Packages resolved 62
Stale 7
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 12 exposed · ~3,021 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
code_search ~207

Hybrid semantic + full-text search over an indexed local repository. Embeds the query via Ollama, then runs a combined vector + FTS search with RRF reranking against the LanceDB index built by index_repo. Use this to find existing patterns, conventions, or examples in the codebase before reviewing a new implementation. Requires a running Ollama (the semantic layer is built in) and index_repo to have been run first. Args: query: Natural language or code snippet describing what to find. root: Absolute path to the repository (must have been indexed first). k: Maximum number of results to return (default 8). Returns: {query, root, results[{file_path, symbol, symbol_type, start_line, end_line, text, score?}]} or {"error": "..."} on failure.

NameTypeReqDescription
kinteger
querystringyes
rootstringyes

No output schema declared.

No examples provided.

dependency_impact ~247

Find everywhere a symbol is used in a checked-out repo (the blast radius). The highest-value review signal: before you approve a change to a function, class, or constant, see who depends on it. Uses ripgrep for fast candidate finding, then classifies each usage via tree-sitter AST as call / import / definition / type_reference. Filesystem-based — point it at a LOCAL clone of the repo the MR belongs to, not the MR URL. Args: symbol: Function/class/variable name to trace. root: Absolute path to the local repository clone. file_glob: Optional glob to narrow the search (e.g. "*.py", "src/**/*.ts"). whole_word: Match whole words only (default True). max_results: Cap on references returned (default 50). Returns: {symbol, root, total_references, references[{file_path, line, context, usage_type}], by_type{...}}

NameTypeReqDescription
file_glob
max_resultsinteger
rootstringyes
symbolstringyes
whole_wordboolean

No output schema declared.

No examples provided.

index_repo ~257

Build or incrementally refresh a semantic search index for a local repository. Walks the repo, chunks every supported-language file by AST boundaries, embeds the chunks via a local Ollama server, and stores them in a per-repo LanceDB table. After the first build this is INCREMENTAL: only files whose content changed since the last run are re-embedded, so refreshing is cheap — run it freely (e.g. when index_status reports "stale"). A changed embedding model or force=True does a full rebuild. Requires a running Ollama (the semantic layer is built in; run `myopic doctor` to set it up) at MYOPIC_OLLAMA_URL (default http://localhost:11434) with the model pulled (MYOPIC_EMBED_MODEL). Args: root: Absolute path to the repository to index. force: Rebuild the whole index even if an up-to-date one exists. Returns: {mode, indexed_chunks, files, skipped, changed_files, deleted_files, git_sha, model} on success, or {"error": "..."} on failure.

NameTypeReqDescription
forceboolean
rootstringyes

No output schema declared.

No examples provided.

index_status ~169

Report whether a repo's semantic index is fresh, stale, or absent. Freshness is keyed to the git commit the index was built from — if HEAD has moved on, the index is "stale" and reports how many commits behind. Check this before leaning on semantic results (code_search / mr_review_context): if state is "stale" or "model_mismatch", offer to index_repo(root) first. Args: root: Absolute path to the repository. Returns: {state: absent|fresh|stale|model_mismatch|unknown, root, chunks?, indexed_at?, indexed_sha?, current_sha?, commits_behind?, reason?} or {"error": "..."} if the semantic extra is not installed.

NameTypeReqDescription
rootstringyes

No output schema declared.

No examples provided.

mr_changed_files ~206

List the files changed in a merge request with stats — no diff content. The cheap entry point for large reviews: the payload has no diff content, so it stays small even on a very large MR. Each file reports additions/deletions, new/deleted/renamed flags, and a reviewability flag (lockfiles, generated code, binary assets, and enormous single-file changes are marked reviewable=false with a skip_reason). Files are ordered reviewable-first then largest-change-first, so you can batch the highest-value files straight into mr_diff_lines(url, files_filter=[...]). Args: url: Full GitLab merge request URL. Returns: {mr_number, title, author, branches, commits, diff_shas, files[{file_path, additions, deletions, reviewable, skip_reason, ...}], stats{total_files, reviewable_files, skipped_files, ...}}

NameTypeReqDescription
urlstringyes

No output schema declared.

No examples provided.

mr_diff_lines ~356

Fetch a merge request's diff as structured, line-numbered hunks. Pure data, no LLM. Returns exact file paths, old/new line numbers, and diff content — everything needed to read a change precisely and to compute the diff positions required for inline comments. Token-safe by construction: on a large MR it returns a bounded page of files and lists the rest under "omitted_files" with "truncated": true (never an oversized payload). Noise files (lockfiles, generated, binary) are listed under "skipped_files", not expanded. For unknown-size MRs, call mr_changed_files first, then batch files_filter here. Args: url: Full GitLab merge request URL. files_filter: Optional list of file-path fragments to include. Passing this is a TARGETED fetch — noise-skip and the budget are disabled so you get exactly the files you ask for. lines_filter: Optional map of filename-fragment -> target new-file line numbers; returns compact line_mappings instead of full hunks. max_chars: Token-safety budget for the returned diff body (default 80000). Ignored for targeted fetches. skip_noise: Keep lockfiles/generated/binary out of the body (listed under skipped_files). Default True. Ignored when filtering. Returns: {mr_number, ..., diff_shas, files[...], truncated, omitted_files, skipped_files, stats}

NameTypeReqDescription
files_filter
lines_filter
max_charsinteger
skip_noiseboolean
urlstringyes

No output schema declared.

No examples provided.

mr_diff_sections ~441

Fetch a merge request's diff grouped by enclosing function/class, not raw hunks. AST-aware for new files (full tree-sitter chunking) and hunk-context-aware for modified files (declaration pattern + hunk-header hint). All changed lines (add/del) are always included — nothing dropped, only the framing changes. Prefer this over mr_diff_lines on a large MR (many files or a big diff) since grouping by symbol keeps the payload small without truncating mid-function. Token-safe by construction, same guarantees as mr_diff_lines: on a large MR it returns a bounded page of files and lists the rest under "omitted_files" with "truncated": true. Noise files (lockfiles, generated, binary) are listed under "skipped_files", not expanded. For unknown-size MRs, call mr_changed_files first, then batch files_filter here. Args: url: Full GitLab merge request URL. include_context_lines: Include unchanged surrounding lines in each section. Default False keeps the payload small. files_filter: Optional list of file-path fragments to include. Passing this is a TARGETED fetch — noise-skip and the budget are disabled so you get exactly the files you ask for. max_chars: Token-safety budget for the returned diff body (default 80000). Ignored for targeted fetches. skip_noise: Keep lockfiles/generated/binary out of the body (listed under skipped_files). Default True. Ignored when filtering. Returns: {mr_number, title, author, branches, description, commits, diff_shas, files[{file_path, language, new_file, deleted_file, additions, deletions, sections[{symbol, symbol_type, start_line, end_line, changes}]}], truncated, omitted_files, skipped_files, stats}

NameTypeReqDescription
files_filter
include_context_linesboolean
max_charsinteger
skip_noiseboolean
urlstringyes

No output schema declared.

No examples provided.

mr_post_comments ~294

Post inline review comments to a merge/pull request. WRITE — this mutates the review. The only mutating tool in myopic. Posts each comment one at a time from a queue, immediately visible (no drafts, no bulk-publish), retrying transient failures (HTTP 429/5xx) with exponential backoff — so partial progress survives a failure and self-hosted rate limits are respected. Works on GitLab and GitHub; the backend translates positions. Only call this on the user's explicit request to post — never speculatively. Get exact line numbers first from mr_diff_lines (its lines_filter maps a source line to the diff position). Each comment needs file_path, body, and at least one of new_line (added/unchanged line) or old_line (removed line). Args: url: Full merge/pull request URL. comments: List of {file_path, body, new_line?, old_line?, old_path?}. max_comments: Safety cap per call (default 25); split larger batches. Returns: {url, platform, total, posted, failed, published, publish_error, details[{file_path, line, status, error}]} or {"error": "..."}.

NameTypeReqDescription
commentsarrayyes
max_commentsinteger
urlstringyes

No output schema declared.

No examples provided.

mr_review_context ~282

Graph-first review context: dependency impact per changed symbol, plus optional semantic enrichment. Extracts the top-N most-frequent identifiers from the MR diff, then for each: 1. Runs dependency_impact(symbol, root) — always, no optional extras needed. 2. If the repo has been indexed via index_repo(root), enriches each symbol with related_patterns from a hybrid semantic search against the codebase. The semantic layer is purely additive: a result with semantic_available=false is complete and actionable — dependency impact already covers the blast radius. Use this as a single-call alternative to running dependency_impact separately for each changed symbol. Args: url: Full GitLab merge request URL. root: Absolute path to the local repository clone. max_symbols: Maximum changed symbols to analyze (default 8). Returns: {mr_number, symbols[{symbol, impact, related_patterns?}], symbol_source, semantic_available, root_status?, warning?, index_status?} or {"error": "..."}. A "warning" means `root` isn't checked out to the MR — set it up with `myopic worktree <url> <repo>` and re-run against its path.

NameTypeReqDescription
max_symbolsinteger
rootstringyes
urlstringyes

No output schema declared.

No examples provided.

mr_review_status ~140

Get a merge request's review status: metadata + discussions + resolution. Pure data, no LLM. Collapses several platform API calls into one snapshot of where the review stands — every discussion thread, what's resolved vs open, general comments, and a lightweight file-change summary. Start here to orient before diving into the diff. Args: url: Full GitLab merge request URL. Returns: {mr_number, title, author, branches, state, merge_status, commits, general_comments, discussions[...], summary{resolved, unresolved, ...}, files_changed[...], stats}

NameTypeReqDescription
urlstringyes

No output schema declared.

No examples provided.

mr_verify_review ~214

Check whether each review thread was addressed by nearby diff changes. Joins the review's discussions with its current diff: for every inline comment thread, surfaces the add/del lines within +/-window of the commented line. A thread with no nearby changes is a candidate for "not yet addressed"; one with changes shows exactly what moved near it — a fast re-review pass without re-reading the whole diff. Read-only. Works on GitLab and GitHub (note: GitHub doesn't expose thread resolution via REST, so rely on has_changes there, not the resolved flag). Args: url: Full merge/pull request URL. window: Lines before/after the commented line to scan (default 40). Returns: {mr_number, title, summary{total_threads, resolved, unresolved, threads_with_changes, threads_without_changes}, threads[{..., nearby_changes, has_changes}], threads_no_location[...]}

NameTypeReqDescription
urlstringyes
windowinteger

No output schema declared.

No examples provided.

trace_call_chain ~208

Trace a function's callers and callees across a checked-out repo (AST). Complements dependency_impact: where dependency_impact lists every reference, this builds the directed call graph — where the symbol is defined, what it calls, and what calls it — so you can reason about a change's ripple effects. Tree-sitter-based; point it at a LOCAL clone of the repo. Args: symbol: Function or class name to trace. root: Absolute path to the local repository clone. language: Restrict to one language; auto-detects if omitted. max_depth: Levels of callers/callees to follow (default 1). Returns: {symbol, definition{file_path, line, type}, callees[...], callers[...], stats{files_scanned, parse_errors}}

NameTypeReqDescription
language
max_depthinteger
rootstringyes
symbolstringyes

No output schema declared.

No examples provided.

Common questions

What is the io.github.SurajKGoyal/myopic MCP server?

io.github.SurajKGoyal/myopic is an MCP server listed in the public MCP registry as io.github.SurajKGoyal/myopic. Code-review MCP: review a GitLab MR or GitHub PR against the whole codebase, not just the diff. This page covers its PyPI package (myopic).

Is the io.github.SurajKGoyal/myopic MCP server safe to use?

io.github.SurajKGoyal/myopic scores 75 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the io.github.SurajKGoyal/myopic MCP server expose?

io.github.SurajKGoyal/myopic exposes 12 tools: mr_changed_files, mr_diff_sections, mr_diff_lines, mr_review_status, dependency_impact, and 7 more. Their descriptions and schemas cost roughly 3,021 tokens of context every time the server is loaded.

Is the io.github.SurajKGoyal/myopic MCP server still maintained?

io.github.SurajKGoyal/myopic is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.