io.github.donggyun112/codecanvas
PYPI · CODECANVAS-MCP · SCANNED SEP 21
Python code intelligence for coding agents: call paths, control flow, and change impact.
Available components
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
- 1 of 34 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency32
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 8 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability66
- AI-judged instruction clarity (excellent).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management97
- Stability observed for 29 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 Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 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. See how to fix → Fail
- An AI judge read all 14 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
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.
pypi · codecanvas-mcp
claude mcp add donggyun112-codecanvas -- uvx codecanvas-mcp
{
"mcpServers": {
"donggyun112-codecanvas": {
"command": "uvx",
"args": [
"codecanvas-mcp"
]
}
}
} {
"servers": {
"donggyun112-codecanvas": {
"command": "uvx",
"args": [
"codecanvas-mcp"
]
}
}
} codex mcp add donggyun112-codecanvas -- uvx codecanvas-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"donggyun112-codecanvas": {
"type": "local",
"command": [
"uvx",
"codecanvas-mcp"
],
"enabled": true
}
}
} openclaw mcp add donggyun112-codecanvas --command uvx --arg codecanvas-mcp
mcp_servers:
donggyun112-codecanvas:
command: "uvx"
args: ["codecanvas-mcp"] {
"McpServers": {
"donggyun112-codecanvas": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"codecanvas-mcp"
]
}
}
} assistant mcp add donggyun112-codecanvas -t stdio -c uvx -a codecanvas-mcp
{
"mcpServers": {
"donggyun112-codecanvas": {
"command": "uvx",
"args": [
"codecanvas-mcp"
]
}
}
} 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.
- 21 Sept 26 +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.
- 19 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.
- 17 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.
- 15 Sept 26 +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.
- 13 Sept 26 +36
- Injection markers: unverified → pass ▲ security
- Tool coverage: unverified → 100 ▲ functional
- MCP protocol: unverified → pass ▲ functional
- Stability: unverified → 0.70 ▲ functional
- 12 Sept 26 −35
- Tool safety: pass → unverified ▼ security
- Stability: 0.63 → unverified ▼ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
- Package version: 0.1.17 → 0.1.20 functional
- 10 Sept 26 +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.
- 8 Sept 26 +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.
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 21 Sept 2026 · Analysed pypi/codecanvas-mcp@0.1.20
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 34 packages
| Packages resolved | 34 |
|---|---|
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
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 →
analyze_impact ~189
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.
| Name | Type | Req | Description |
|---|---|---|---|
| diff_text | – | – | – |
| git_ref | – | – | – |
| include_tests | boolean | – | – |
| project_path | – | – | – |
No output schema declared.
No examples provided.
call_tree ~301
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`.
| Name | Type | Req | Description |
|---|---|---|---|
| depth | integer | – | – |
| filter | – | – | – |
| function | string | yes | – |
| include_tests | boolean | – | – |
| project_path | – | – | – |
No output schema declared.
No examples provided.
find_symbols ~229
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | – | – | – |
| include_tests | boolean | – | – |
| kind | – | – | – |
| limit | integer | – | – |
| min_score | number | – | – |
| path | – | – | – |
| project_path | – | – | – |
| query | string | yes | – |
| search_mode | string | – | – |
No output schema declared.
No examples provided.
function_flow ~102
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.
| Name | Type | Req | Description |
|---|---|---|---|
| function | string | yes | – |
| project_path | – | – | – |
No output schema declared.
No examples provided.
list_entrypoints ~271
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.
| Name | Type | Req | Description |
|---|---|---|---|
| filter | – | – | – |
| include_tests | boolean | – | – |
| kind | – | – | – |
| project_path | – | – | – |
No output schema declared.
No examples provided.
logic_flow ~139
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.
| Name | Type | Req | Description |
|---|---|---|---|
| depth | integer | – | – |
| function | string | yes | – |
| include_tests | boolean | – | – |
| project_path | – | – | – |
No output schema declared.
No examples provided.
project_status ~54
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`.
| Name | Type | Req | Description |
|---|---|---|---|
| project_path | – | – | – |
No output schema declared.
No examples provided.
reaching_conditions ~180
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`.
| Name | Type | Req | Description |
|---|---|---|---|
| function | string | yes | – |
| project_path | – | – | – |
| target | – | – | – |
No output schema declared.
No examples provided.
simulate_state_transition ~471
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cases | – | – | – |
| function | string | yes | – |
| import_timeout_seconds | number | – | – |
| invariants | – | – | – |
| max_cases | integer | – | – |
| overrides | – | – | – |
| project_path | – | – | – |
| python_executable | – | – | – |
| state_schema | object | yes | – |
| state_var | string | – | – |
| timeout_seconds | number | – | – |
No output schema declared.
No examples provided.
validate_state_schema ~183
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.
| Name | Type | Req | Description |
|---|---|---|---|
| function | string | yes | – |
| project_path | – | – | – |
| state_schema | object | yes | – |
| state_var | string | – | – |
No output schema declared.
No examples provided.
verify_claim ~283
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`.
| Name | Type | Req | Description |
|---|---|---|---|
| claim | string | yes | – |
| max_depth | integer | – | – |
| project_path | – | – | – |
No output schema declared.
No examples provided.
what_does ~203
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.
| Name | Type | Req | Description |
|---|---|---|---|
| function | string | yes | – |
| project_path | – | – | – |
No output schema declared.
No examples provided.
who_calls ~209
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.
| Name | Type | Req | Description |
|---|---|---|---|
| depth | integer | – | – |
| filter | – | – | – |
| function | string | yes | – |
| project_path | – | – | – |
No output schema declared.
No examples provided.
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.