This server renders source code or git diffs as syntax-highlighted images (SVG or PNG) for easy visual sharing.
render_code: Convert source code snippets in 40+ languages (TypeScript, Rust, Python, Go, JavaScript, CSS, HTML, SQL, etc.) into beautiful images with full syntax highlighting.
render_diff: Render unified git diffs with color-coded additions (green) and deletions (red), plus language-aware highlighting within diff hunks.
Output formats: SVG (crisp, scalable, copyable) or PNG (raster, for platforms without SVG support).
Themes: Choose from 18 bundled themes, including dark options (github-dark, nord, dracula, one-dark-pro, catppuccin-mocha) and light options (github-light, solarized-light, catppuccin-latte).
Customization: Configure font size, padding, line numbers, window title, and code area width.
Auto-detection: Language is automatically identified from code content, shebangs, or diff file headers.
Config file: Set default options via ~/.code-shotrc.
Allows rendering source code as beautiful images (SVG/PNG) with syntax highlighting, line numbers, and diff rendering, directly from the Hermes AI assistant.
Click on "Install 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., "@code-shot Render this Python code as a PNG with line numbers."
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.
MCP server that renders source code as beautiful images. Perfect for AI agents to show code visually to humans on mobile devices, or for sharing syntax-highlighted snippets.
Generated from this TypeScript snippet with theme: github-dark and title: greet.ts:
function greet(name: string): string {
const message = `Hello, ${name}!`;
return message;
}
console.log(greet('world'));Related MCP server: Code Screenshot Generator
render_codeRender source code as SVG or PNG with full syntax highlighting.
Param | Type | Default | Description |
| string | required | Source code to render |
| string | auto-detect | Language (ts, rust, py, go, js, and 40+ more) |
| string |
| Color theme (nord, dracula, catppuccin, one-dark-pro, etc.) |
| string | — | Window title bar text (e.g. filename) |
| boolean |
| Line number gutter |
| number |
| Font size in px |
|
|
| SVG is crisp & copyable; PNG is raster |
| number | auto | Code area width in characters |
| number |
| Padding in px |
render_diffRender a git unified diff with color-coded additions/deletions and language-aware syntax highlighting.
Param | Type | Default | Description |
| string | required | Unified diff content ( |
| string | auto-detect | Language for highlighting within hunks. Auto-detected from |
... | — | — | Same options as |
Diff lines are highlighted with:
@@ hunk headers → blue background
+ additions → green background (#1b4520 dark / #dafbe1 light)
- deletions → red background (#4f1818 dark / #ffebe9 light)
Syntax highlighting is applied per-hunk in the detected language — not just plain diff markup.
18 bundled themes:
Dark | Light |
github-dark | github-light |
nord | one-light |
one-dark-pro | material-theme-lighter |
dracula | min-light |
dracula-soft | solarized-light |
catppuccin-mocha | catppuccin-latte |
material-theme | vitesse-light |
min-dark | — |
solarized-dark | — |
vitesse-dark | — |
46 tests across two runners:
npm test # Build → MCP integration tests (cobasaja) → Unit tests (node --test)5 MCP integration tests (tests/code-shot.test.ts) — tool discovery, rendering, error cases
37 unit tests (tests/*.node-test.ts) — renderSvg structure, diffToLines parsing, guessLanguage heuristics
Add to ~/.hermes/config.yaml:
mcp_servers:
code-shot:
command: "npx"
args: ["-y", "@thesimonharms/code-shot"]Or from local build:
mcp_servers:
code-shot:
command: "node"
args: ["/path/to/code-shot/dist/index.js"]Set defaults via ~/.code-shotrc (JSON):
{
"theme": "nord",
"show_line_numbers": true,
"font_size": 14,
"padding": 16
}Also checked (in order): ~/.code-shotrc > ~/.code-shotrc.json > ~/.config/code-shot/config.json.
Tool call arguments override config file values.
{
"mcpServers": {
"code-shot": {
"command": "node",
"args": ["/path/to/code-shot/dist/index.js"]
}
}
}npm install
npm run build # tsc
npm test # build + cobasaja + node --testShiki tokenizes the code with full syntax highlighting (grammars for 40+ languages)
SVG renderer builds a pixel-perfect SVG with monospace positioning, window chrome, line numbers, and diff markers
Optional PNG via @resvg/resvg-js for platforms that don't support SVG natively
Language auto-detection via shebang parsing and code heuristics (18 language patterns)
Diff language detection from diff --git a/file.ext b/file.ext headers
No browser, no DOM, no headless Chromium — pure math-based SVG generation.
MIT
Render source code as a syntax-highlighted image (SVG or PNG). Perfect for AI agents to show code visually to humans on mobile devices.
The output is an SVG string by default (crisp, copyable, small). Set output_format='png' for a raster image (written to a temp file).
Supports 40+ themes including github-dark, github-light, nord, dracula, one-dark-pro, catppuccin, material-theme, and more.
Supports 40+ languages via shiki: TypeScript, Rust, Python, Go, JavaScript, JSX/TSX, CSS, HTML, JSON, YAML, Markdown, SQL, Dockerfile, GraphQL, Ruby, PHP, Java, C/C++, C#, Swift, Kotlin, Scala, Lua, Perl, R, Elixir, Haskell, Zig, Nim, Solidity, Move, TOML, XML, shell/bash, PowerShell, and more.
When you call this tool, include the full code and tell the user the image is being rendered.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The source code to render as an image | |
| language | No | Programming language for syntax highlighting. Auto-detected if omitted. | auto |
| theme | No | Color theme name. Popular: github-dark, github-light, nord, dracula-soft, one-dark-pro, catppuccin-mocha, material-theme, min-dark, solarized-dark, vitesse-dark. | github-dark |
| title | No | Optional title shown in a window title bar (e.g. the filename) | |
| show_line_numbers | No | Show line numbers in the gutter | |
| font_size | No | Font size in pixels | |
| output_format | No | Output format. 'svg' produces crisp, copyable vector output. 'png' produces a raster image saved to a temp file. | svg |
| width | No | Width of the code area in characters. Default: fits the longest line. | |
| padding | No | Padding around the code block in pixels |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: default output is SVG string, PNG saves to temp file, supports 40+ themes and languages. It does not mention side effects or rate limits, but these are unlikely for a render tool.
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 well-structured with a clear first sentence followed by bullet-like lists of themes and languages. It is concise but includes all necessary details without redundancy.
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 the tool's complexity (9 parameters, no output schema), the description covers essential aspects: output format, supported themes/languages, and usage guidance. It lacks mention of return value structure but that is acceptable without an output schema.
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 100%, so the baseline is 3. The description adds context about output format behavior but does not significantly enhance parameter meaning beyond the schema definitions.
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 description clearly states the tool renders source code as a syntax-highlighted image (SVG or PNG) for showing code visually to humans. It distinguishes from sibling tool 'render_diff' by focusing on code rather than diffs.
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?
The description provides clear context: 'Perfect for AI agents to show code visually to humans on mobile devices' and instructs to include full code and notify the user. It could explicitly compare with 'render_diff' but overall offers good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a git unified diff as a beautiful syntax-highlighted image (SVG or PNG). Shows additions in green and deletions in red with diff markers.
Perfect for PR reviews, sharing code changes on mobile, or visualising what changed between two versions.
Accepts standard git diff output (unified format). Automatically parses @@ hunk headers and renders additions/deltions with appropriate backgrounds.
The output is SVG by default. Set output_format='png' for a raster image.
| Name | Required | Description | Default |
|---|---|---|---|
| diff | Yes | The unified diff content (e.g. output of `git diff` or `git show`). Should include @@ hunk headers and +/- markers. | |
| theme | No | Color theme name | github-dark |
| title | No | Optional title shown in a window title bar | |
| show_line_numbers | No | Show line numbers in the gutter | |
| font_size | No | Font size in pixels | |
| output_format | No | Output format. 'svg' or 'png'. | svg |
| padding | No | Padding around the code block in pixels |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Describes input format (standard git diff output), parsing of @@ hunk headers, and color coding. Lacks details on error handling or non-XSS, but overall transparent.
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?
Well-structured with clear front-loaded purpose. Slightly verbose, and contains a typo ('deltions' instead of 'deletions'), but overall concise.
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?
Explains inputs well, but missing details on output (e.g., whether result is a URL, base64, or file). No output schema, so description should cover this.
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 coverage is 100% with descriptions. Description adds minor context (e.g., diff structure, output_format='png' shorthand) but does not significantly augment schema.
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?
Clearly states verb ('Render') and specific resource ('git unified diff as a beautiful syntax-highlighted image (SVG or PNG)'). Distinguishes from sibling 'render_code' by focusing on diffs.
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?
Provides explicit use cases ('PR reviews, sharing code changes on mobile, visualising changes'). Does not exclude alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0render_coderender_diffEach tool targets a distinct input: render_code handles source code blocks, while render_diff handles unified diffs. No overlap in purpose.
Both tools follow the verb_noun pattern (render_code, render_diff), maintaining a consistent naming convention.
Two tools is minimal but appropriate for the narrow domain of code visualization; each tool serves a clear and distinct purpose.
The server covers the primary use cases of rendering code and diffs as images. Minor gaps like batch rendering or line numbers are not essential but would be nice additions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate images, GIFs, and PDFs from HTML, URLs, or templates — from your AI agent.
Generate and vectorize clean, editable SVG graphics from text, images, or both.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/thesimonharms/code-shot'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
