Gungnir MCP Server is a local, read-only MCP server for trusted Gungnir project intelligence, native compiler validation, and pinned documentation; the provided schema exposes only gungnir_status.
Report server version, group, capabilities, and trust state without exposing project paths.
Per the README, also discover toolchains, inspect project structure/counts, list bounded .gnr modules, run fixed gungnirc --check validation, and verify C++ IR via --verify-ir.
Read 18 bundled static docs/SDK resources pinned to Gungnir v1.0.2.
It cannot build apps, generate C++, run migrations, mutate files, accept custom compiler flags/paths, or operate outside trusted roots.
Provides compiler-backed validation and verification for C++ projects built with the Gungnir C++23 web framework: runs bounded gungnirc --check diagnostics on .gnr modules or whole projects and performs read-only C++ IR verification, returning structured, sanitized diagnostics and metadata.
Click on "Deploy 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., "@Gungnir MCP Server check the Gungnir server status and available capabilities"
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.
A Model Context Protocol (MCP) server for the Gungnir C++23 web framework and its .gnr language.
Developer preview: Group 9, version 0.9.0. Local stdio server supporting modern and legacy MCP protocols, trusted project configuration, native SDK discovery, structural project intelligence, and native compiler validation via gungnirc --check and read-only C++ IR verification via gungnirc --verify-ir. Includes pinned, version-aware official documentation resources and validated local SDK capability metadata. Application builds, C++ generation, migrations and file mutations remain unavailable.
Node.js 24, npm, a compatible MCP stdio host.
Install a trusted Gungnir SDK with gungnirc to use compiler validation. Project intelligence and status remain usable without it.
Configure an explicit trusted project root for source validation.
Related MCP server: grok-mcp
npm ci
npm run lint
npm run typecheck
npm run build
npm test
npm run pack:checkRun the compiled server from your MCP host with an explicitly trusted project, for example:
node dist/index.js --project-root "/work/inventory" --trusted-root "/work"An MCP stdio server waits for client messages and reserves stdout for protocol traffic. Use npx @modelcontextprotocol/inspector node dist/index.js to inspect a server started without project access.
Tool | Function |
| Server version, group, capabilities, trust state |
| Read-only Gungnir CLI, compiler, SDK and CMake discovery |
| Trusted Gungnir project marker/profile, structure and counts |
| Bounded relative |
| Native structured project or single-file |
| Structured-project or indexed-source C++ IR verification; returns metadata and redacted verifier results |
Calling gungnir_check with {} validates an explicitly trusted structured project. With {"file":"app/models/User.gnr"}, it checks one indexed, project-relative file, using compatibility mode when the project is legacy. Compiler errors return codes, locations and sanitized messages, not raw source excerpts or absolute paths.
Only fixed gungnirc --check and gungnirc --verify-ir operations are permitted. No caller-supplied compiler flags, executable paths, output targets or working directories are accepted.
Group 9 registers 18 static resources through MCP resources/list and resources/read, with no HTTP requests at runtime:
16 official framework guides at gungnir://docs/1.0.2/<topic> (including grammar, expressions, models, controllers, routing, ORM, authentication, validation, views, migrations and SDK packages).
gungnir://docs/catalog — JSON catalog with exact official source URLs, immutable commit and blob hashes.
gungnir://sdk/capabilities — sanitized SDK version, profile and adapter flags from an operator-selected local SDK manifest.
The official documents are pinned to Gungnir v1.0.2, bundled for offline reading and Git-blob-hash verified before serving. Unsupported version URIs, arbitrary paths, resource templates and wildcard reads are not accepted. The SDK resource requires GUNGNIR_MCP_SDK_ROOT or GUNGNIR_CMAKE_PREFIX; unlike toolchain discovery, it never guesses an SDK from PATH or executes native binaries.
Select the trusted SDK using GUNGNIR_MCP_SDK_ROOT, or GUNGNIR_CMAKE_PREFIX, otherwise use a trusted absolute PATH. Explicit SDK overrides do not silently fall back to another compiler. Native version and check operations run through the bounded, no-shell subprocess runner.
Important: Native compilation checks necessarily read trusted source files and execute a local gungnirc binary. Only enable them for projects and toolchains you trust. Canonical filesystem checks and bounded scans are not a race-free OS sandbox.
Read Documentation resources, IR verification, Compiler validation, Process runner, Project intelligence, Configuration, Security and the 16-group roadmap.
CI uses Node.js 24 on Windows 2025 and Ubuntu 24.04. No automatic npm publication or deployment. MIT license.
Report the server's available read-only capabilities and trust state without exposing project paths.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose two useful traits: the call is read-only and it deliberately omits project paths (a privacy guarantee). It says nothing about what the returned capabilities/trust data look like or what triggers a non-success response.
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?
A single tightly written sentence with no filler. The key constraint (read-only) and the privacy guarantee are both front-loaded.
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?
There is no output schema, so the description is the only place an agent could learn what 'capabilities' and 'trust state' contain, and it stays abstract. For a trivial zero-parameter status tool this is adequate to select it, but not enough to anticipate the response.
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?
The tool takes zero parameters, so there is nothing for the description to clarify beyond that; the baseline of 4 applies. The description does not misleadingly imply any inputs.
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?
States a specific verb ('Report') and resource ('the server's available read-only capabilities and trust state'), which tells an agent this is a status/introspection tool. It is not quite 5 because 'trust state' is undefined jargon the agent cannot resolve from the description alone.
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?
Usage is only implied: an agent can infer this is the tool to call to learn what the server can do before other operations. There is no explicit 'call this when...' statement and no stated prerequisites or exclusions, though with no sibling tools there is no alternative to disambiguate against.
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.
v0.3.0gungnir_statusScored across 1 tool
With only a single tool there is no risk of misselection between tools, so ambiguity is effectively zero. It loses a point only because there is no second tool to establish clear boundaries or confirm the scope of the surface.
The name 'gungnir_status' is a clear, readable snake_case resource_action pattern. There is only one name, so consistency across the set cannot really be demonstrated, but nothing is inconsistent or vague.
A single status-reporting tool is extremely thin for a server that implies a broader capability/trust domain. It offers no actionable operations, making the surface feel under-scoped rather than deliberately minimal.
The only operation reports read-only capabilities and trust state; there is no tool to actually invoke any capability, query details, or perform a lifecycle action. Agents hitting this server will reach a dead end if they intend to do anything beyond discovery.
Public read-only MCP server for Genvernium product and developer resources.
Read-only developer, date, finance, and text utilities. Authless remote MCP server by Clean.tools.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Ovanek MCP: Model Context Protocol server for Ovanek platform tools; writes are dry-run by default.
