Gungnir MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| gungnir_statusA | Report the server's available read-only capabilities and trust state without exposing project paths. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.