dev-error-explainers
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| explain_errorA | Explain a concrete developer error message or log excerpt and return its documented cause and fix. Call it when the user pastes (or you captured from a terminal/browser console) an actual error, for example:
Returns a short human-readable diagnosis (cause, why, ranked fixes with code, official source links) plus the same result as structured JSON. If nothing is recognised it answers "No known error recognised — nothing guessed"; then rely on your own reasoning. Fully offline and deterministic: no network, no LLM, same input gives the same output. Secrets it can recognise (URL passwords, Bearer/Basic tokens, JWTs, token/key query parameters) are masked in the output. |
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
There is only one tool, so there is no possibility of overlap or misselection between tools. Its purpose (diagnose a concrete developer error message) is clearly stated and distinguishable from any generic reasoning the agent might do.
The single name explain_error follows a clean verb_noun convention and is self-descriptive. There are no other names to conflict with, so consistency is trivially satisfied.
One tool is borderline thin for a server surface, even though it is well-scoped to a single capability. A single-tool server offers no granularity if callers want, e.g., just the structured or just the lookup.
For its narrow stated purpose (explain a pasted error and return cause, fixes, and structured JSON) the surface is self-contained, including an explicit no-match fallback. Coverage is only as broad as its offline known-error database, but no lifecycle operations are obviously missing.