# io.github.donggyun112/codecanvas (pypi · codecanvas-mcp)

Python code intelligence for coding agents: call paths, control flow, and change impact.

- Trust score: 76/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-21

## Components

- pypi · `codecanvas-mcp`: 76/100 (this document), [markdown](https://verifymcp.io/servers/donggyun112-codecanvas/codecanvas-mcp.md), [page](https://verifymcp.io/servers/donggyun112-codecanvas/codecanvas-mcp)

## Channel facts

- Registry: `pypi`
- Package: `codecanvas-mcp`
- Version: `0.1.20`
- Transport: `stdio`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-21.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it.
  - 1 of 34 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 32/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - License check failed: no license is declared.
  - Actively maintained (last published 8 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 66/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 3114 tokens (~239/item across 13 items; 13 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 97/100
  - Stability observed for 29 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 67/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "simulate_state_transition" implies "execute" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 14 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the io.github.donggyun112/codecanvas MCP server?

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

### Claude

```bash
claude mcp add donggyun112-codecanvas -- uvx codecanvas-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "donggyun112-codecanvas": {
      "command": "uvx",
      "args": [
        "codecanvas-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "donggyun112-codecanvas": {
      "command": "uvx",
      "args": [
        "codecanvas-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add donggyun112-codecanvas -- uvx codecanvas-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "donggyun112-codecanvas": {
      "type": "local",
      "command": [
        "uvx",
        "codecanvas-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add donggyun112-codecanvas --command uvx --arg codecanvas-mcp
```

### Hermes

```yaml
mcp_servers:
  donggyun112-codecanvas:
    command: "uvx"
    args: ["codecanvas-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "donggyun112-codecanvas": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "codecanvas-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add donggyun112-codecanvas -t stdio -c uvx -a codecanvas-mcp
```

### Other

```json
{
  "mcpServers": {
    "donggyun112-codecanvas": {
      "command": "uvx",
      "args": [
        "codecanvas-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-21 (score 76, +1)

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

### 2026-09-19 (score 75, +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.

### 2026-09-17 (score 74, +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.

### 2026-09-15 (score 73, +1)

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

### 2026-09-13 (score 72, +36)

- [security improvement] Injection markers: unverified → pass
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] MCP protocol: unverified → pass
- [functional improvement] Stability: unverified → 0.70

### 2026-09-12 (score 36, −35)

- [security regression] Tool safety: pass → unverified
- [security regression] Stability: 0.63 → unverified
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional] First check of Schema quality: unverified
- [functional] Package version: 0.1.17 → 0.1.20

### 2026-09-10 (score 71, +1)

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

### 2026-09-08 (score 70, +1)

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

## MCP tools (13)

### `list_entrypoints` (~271 tokens)

Map where a codebase starts — list its API/HTTP routes, CLI scripts,
public library exports, and entry-point functions. Reach for this first to
get the lay of an unfamiliar project: what endpoints exist, which handler
serves each route, where execution begins.

For a library, `kind="export"` is its public API surface, taken from each
distributed package's `__all__` and `[project.scripts]` and resolved to
where each name is defined. Every export is tagged with its distribution.

On large projects the result is capped, so narrow it: `filter` is a
case-insensitive substring matched over method/path/handler/id/tags
(e.g. "login", "StateGraph", or a package name), and `kind` keeps one kind
("api", "script", "export", "function"). When the list is truncated the
note names every package that has exports, so a symbol you cannot see is
still one `filter` away. Test-fixture entrypoints (handlers under `tests/`,
\`test_*.py`) are hidden by default; set `include_tests=True` to keep them.

Input parameters:

- `filter`
- `include_tests` (boolean)
- `kind`
- `project_path`

### `find_symbols` (~229 tokens)

Find project functions, methods, and classes by name, qualified name,
scope, acronym, or docstring meaning. Results explain matched tokens,
character spans, and likely symbol role. Continue with `next_cursor`;
choose `search_mode` name, semantic, or hybrid.

\`semantic` is concept-expanded lexical matching over identifier words plus
docstrings — related wordings reach each other (throttle/limiter,
parallel/concurrency), but it is not an embedding search, so a query
sharing no vocabulary with the code will not find it. Every row reports
\`match.coverage`: the fraction of the query's content words the symbol
accounts for. Ranking multiplies by coverage, so a partial overlap can
never outrank a full one — raise `min_score` to cut partial hits.

Input parameters:

- `cursor`
- `include_tests` (boolean)
- `kind`
- `limit` (integer)
- `min_score` (number)
- `path`
- `project_path`
- `query` (string, required)
- `search_mode` (string)

### `project_status` (~54 tokens)

Inspect the active analysis root, Python file count, disk-cache state,
and nested Python project roots. Use this when results look polluted or
incomplete and you may need a narrower `project_path`.

Input parameters:

- `project_path`

### `who_calls` (~209 tokens)

Find the callers of a function — who calls it, its upstream usages and
references, the reverse call graph, and what would break if you change its
signature. Complements `call_tree`, which walks the opposite direction
(downstream, what the function reaches).

\`function` accepts a qualified name, bare name, file:line, or a
scope-skipping suffix like `Class.nested` (an enclosing scope omitted). `depth=1`
(default) returns direct callers; `depth=N` walks up to N hops of
transitive callers, tagging each with its `depth` and the `callee` it
calls on the traced path. Cycles/recursion terminate safely. On heavily
called functions the result is capped, so `filter` (case-insensitive
substring over caller/location/callee) narrows it before truncation.

Input parameters:

- `depth` (integer)
- `filter`
- `function` (string, required)
- `project_path`

### `what_does` (~203 tokens)

Get a quick summary of what a function does without reading its source
— its signature, docstring, side effects (whether it touches the database
or makes HTTP calls), the exceptions it can raise, and a risk rating. Use
it to triage an unfamiliar function before deciding whether to dig into
\`function_flow` or the full source. `function` = qualified name, bare name,
file:line, or a scope-skipping suffix like `Class.nested`.

\`calls` and `effects.direct` cover this function's own call sites, and
\`risk` scores only those. `effects.transitive` names what it reaches
through callees, each attributed to the callee that carries it via
\`effects.via` — so a thin wrapper scoring risk 0 still shows the database
write underneath it. Use `call_tree` for the full downstream picture.

Input parameters:

- `function` (string, required)
- `project_path`

### `logic_flow` (~139 tokens)

Start here to understand an unfamiliar function's logic in one compact
call. Combines symbol resolution, signature and summary, branch outline,
guarded outcomes, downstream project calls, effects, and repository-relative
citation locations. Prefer this over separately calling `find_symbols`,
\`what_does`, `function_flow`, `reaching_conditions`, and `call_tree`; use
those only when this response is truncated, ambiguous, or needs one focused
detail. `depth` bounds downstream calls and defaults to two hops.

Input parameters:

- `depth` (integer)
- `function` (string, required)
- `include_tests` (boolean)
- `project_path`

### `analyze_impact` (~189 tokens)

Assess the blast radius of a change — given a diff or git ref, list the
changed functions and which entry points/public surfaces they affect
(HTTP routes, scripts, or public function fallbacks). Reach for this when
reviewing a PR or before merging, to see what a set of edits could break
downstream.

Pass `diff_text` for an inline diff, or `git_ref` to diff against a ref.
Entry points whose handler is under a test path are hidden by default
(consistent with `list_entrypoints`); set `include_tests=True` to keep
them. Non-Python changed files are reported under `skipped_files`. Prefer
\`affected_entrypoints`; `affected_endpoints` is a legacy compatibility
alias.

Input parameters:

- `diff_text`
- `git_ref`
- `include_tests` (boolean)
- `project_path`

### `function_flow` (~102 tokens)

Understand how a function works internally without reading the full
source. `flow` is a structured branch tree with explicit `subject`, `scope`,
\`condition`, and `nested_subjects`; `outline` is a compatibility rendering.
For exact return/raise guards, use `reaching_conditions`. `function` accepts
a qualified name, bare name, file:line, or scope-skipping suffix.

Input parameters:

- `function` (string, required)
- `project_path`

### `verify_claim` (~283 tokens)

Verify a qualified reachability claim before summarizing it.

Use `<source> reaches <target>`, optionally prefixed with context such as
\`root task-mode`. The result combines static call paths, structured
\`function_flow`, and `reaching_conditions`, returning `true`, `false`, or
\`uncertain` plus a counterexample/qualification. Inferred-only paths never
receive a true verdict.

Condition qualifiers on the prefix are evaluated, not ignored:
\`dry-run publish reaches _call_api`, `wake=false deliver reaches _send`,
and `without OPENAI_API_KEY analyze reaches run_ai` each get checked
against the guards on every path, and a guard requiring the opposite makes
the verdict `false` with that guard as the counterexample.
\`applied_qualifiers` lists the conditions actually modelled. A condition no
guard constrains lands in `unsupported_qualifiers`, caps the verdict at
\`uncertain`, and sets `safe_to_summarize: false` — report it as
unevaluated rather than answering as if it held. Unknown prefix syntax,
such as `priority=urgent` or a bare `banana`, is returned as an input error
with `safe_to_summarize: false`.

Input parameters:

- `claim` (string, required)
- `max_depth` (integer)
- `project_path`

### `reaching_conditions` (~180 tokens)

Find out under what conditions a function reaches each of its returns
and raises — the guard/path conditions (the enclosing if/elif/else,
except, and loop tests) leading to each outcome. Reach for this when
hunting a bug in branching logic or asking "why does this hit the error
path?": it surfaces error-path vs success-path asymmetries (e.g. a success
response returned from an except handler), plus cyclomatic complexity and
any unreachable/dead code. `target`: omit for all return/raise; or
"return" / "raise" / "line:N" to focus. `function` = qualified name,
bare name, file:line, or a scope-skipping suffix like `Class.nested`.

Input parameters:

- `function` (string, required)
- `project_path`
- `target`

### `validate_state_schema` (~183 tokens)

Check a function's state dict/object usage against expected fields.

Use this when a bug depends on domain state shape rather than call graph
reachability alone. `state_schema` may be JSON-schema-like
(`{"properties": {...}, "required": [...]}`) or a simple field mapping.
The tool reports state reads/writes, dict-shaped returns, schema-extra
fields, and returns missing required fields. `state_var` must match the
function parameter that receives the whole state mapping; these tools are
designed for node-style functions such as `def node(state)`. This is a
focused repro aid: it turns custom state assumptions into checkable evidence,
but still does not conclusively prove runtime behavior.

Input parameters:

- `function` (string, required)
- `project_path`
- `state_schema` (object, required)
- `state_var` (string)

### `simulate_state_transition` (~471 tokens)

Execute focused state-transition repro cases in isolated processes.

Pass explicit `cases` for exact domain states, or omit them to generate a
small schema-shaped set from `state_schema`; generated cases do not derive
branch predicates, so use `function_flow`/`reaching_conditions` plus explicit
cases when branch coverage matters. Built-in invariants include `no_exception`,
\`return_is_mapping`, `return_has_required_keys`,
\`no_unknown_return_keys`, and `state_preserves_required_keys`. Results
include return values, state mutations, exceptions, captured output, and
per-case violations. Exceptions are always reported; include `no_exception`
when they should fail a case. `timeout_seconds` limits function execution;
\`import_timeout_seconds` separately limits fixture hydration and module setup.
Cases may use allowlisted `$type` fixtures such as `langchain.AIMessage` and
\`langchain.ToolMessage`. Use `overrides` to replace a dependency at its runtime
lookup path with one explicit `return_value`, `return_sequence`, or `raise`
behavior. Override calls and unused overrides are reported per case. This
executes trusted project code in a separate process, not a security sandbox:
filesystem, network, subprocess, and import-time side effects remain possible
and cannot be contained or overridden by this tool.
\`state_var` must match the parameter receiving the whole state mapping.
Module-level sync and async node-style functions are supported in this MVP.

The worker runs on the project's virtualenv interpreter when one is found
(`<project>/.venv` or `venv`, then the same in the parent directory),
otherwise on this server's interpreter — which under `uvx` cannot import the
project's dependencies. Set `python_executable` to choose explicitly. Every
result reports the interpreter used under `worker`; check it first when a
case fails with an unexpected ImportError.

Input parameters:

- `cases`
- `function` (string, required)
- `import_timeout_seconds` (number)
- `invariants`
- `max_cases` (integer)
- `overrides`
- `project_path`
- `python_executable`
- `state_schema` (object, required)
- `state_var` (string)
- `timeout_seconds` (number)

### `call_tree` (~301 tokens)

Trace everything a function reaches downstream — the forward transitive
call tree, N hops deep, in one call instead of hopping node-by-node. Reach
for this to see what a function ends up doing and which side effects it
triggers transitively. The complement of `who_calls`, which walks the
opposite direction (upstream, who calls it).

Each node carries its `depth`, the `via` caller on the traced path, effect
flags (db/http/raises/stub) with `effect_scope: "direct"` — a node's flags
are always its own, never its subtree's — and risk. The top-level
\`effects` splits the queried function's own effects (`direct`) from those
it only reaches through callees (`transitive`, attributed by `via`). Only
project-internal functions are nodes; library calls show up as the
parent's effect tags. Cycle-safe
(dedup by name). Callees resolving into a test path are dropped by default
(usually a misresolution); set `include_tests=True` to keep them. `filter`
narrows by substring before the cap. `function` = qualified name, bare
name, file:line, or a scope-skipping suffix like `Class.nested`.

Input parameters:

- `depth` (integer)
- `filter`
- `function` (string, required)
- `include_tests` (boolean)
- `project_path`

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/donggyun112-codecanvas/codecanvas-mcp#diagnostics

## Score history

- 2026-09-21: 76
- 2026-09-20: 75
- 2026-09-19: 75
- 2026-09-18: 74
- 2026-09-17: 74
- 2026-09-16: 73
- 2026-09-15: 73
- 2026-09-14: 72
- 2026-09-13: 72
- 2026-09-12: 36
- 2026-09-11: 71
- 2026-09-10: 71
- 2026-09-09: 70
- 2026-09-08: 70
- 2026-09-07: 69
- 2026-09-06: 69
- 2026-09-05: 68
- 2026-09-04: 68
- 2026-09-03: 67
- 2026-09-02: 67
- 2026-09-01: 66
- 2026-08-31: 66
- 2026-08-30: 62
- 2026-08-29: 62
- 2026-08-28: 62
- 2026-08-27: 47
- 2026-08-26: 62
- 2026-08-25: 61
- 2026-08-24: 61
- 2026-08-23: 61

## Common questions

### What is the io.github.donggyun112/codecanvas MCP server?

io.github.donggyun112/codecanvas is an MCP server listed in the public MCP registry as io.github.donggyun112/codecanvas. Python code intelligence for coding agents: call paths, control flow, and change impact. This page covers its PyPI package (codecanvas-mcp).

### Is the io.github.donggyun112/codecanvas MCP server safe to use?

io.github.donggyun112/codecanvas scores 76 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 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.donggyun112/codecanvas MCP server expose?

io.github.donggyun112/codecanvas exposes 13 tools: list_entrypoints, find_symbols, project_status, who_calls, what_does, and 8 more. Their descriptions and schemas cost roughly 2,814 tokens of context every time the server is loaded.

### Is the io.github.donggyun112/codecanvas MCP server still maintained?

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

## Links

- PyPI project: https://pypi.org/project/codecanvas-mcp/
- Socket report: https://socket.dev/pypi/package/codecanvas-mcp
- Repository: https://github.com/donggyun112/codecanvas
- Changelog RSS feed: https://verifymcp.io/servers/donggyun112-codecanvas/codecanvas-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/donggyun112-codecanvas/codecanvas-mcp.json
- HTML version of this page: https://verifymcp.io/servers/donggyun112-codecanvas/codecanvas-mcp