error-transport-context

Preserve service request context across MCP and CLI error envelopes.

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

87%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is concise, well-structured, and actionable with concrete types, fields, and file paths, but the workflow lacks an explicit validation checkpoint despite touching compatibility-sensitive error fields.

Suggestions

Add a verification step, e.g. "After changes, run existing error-envelope tests to confirm error/errorMessage/isError and new fields serialize correctly in both MCP and CLI."

Consider a short ordered checklist (stamp -> mirror in ExcelToolsBase -> mirror in CliErrorOutput -> verify) to make the apply sequence explicit.

Note which compatibility fields are asserted by existing tests so Claude knows what must not regress.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence: short Context line and tight bullet guidance with no padding or explanation of basic concepts (e.g. what MCP or error envelopes are), matching the level-3 anchor where every token earns its place. Quotes: "Put shared diagnostics on ServiceResponse, not in host-specific wrappers." / "Prefer additive fields over message rewrites so existing clients keep working."	3 / 3
Actionability	Guidance names concrete types and fields (ServiceResponse, command, sessionId, ExcelToolsBase, CliErrorOutput, error/errorMessage/isError) and points to specific source files; per the code-vs-instruction note, an instruction-only skill need not contain code when guidance is this specific, so it reaches level 3. Quotes: "Stamp failed responses with the originating command and sessionId at the service boundary" / "src/ExcelMcp.McpServer/Tools/ExcelToolsBase.cs: include command and sessionId in serialized error JSON."	3 / 3
Workflow Clarity	Patterns are logically ordered (shared diagnostics -> stamp at boundary -> mirror across transports -> additive) and Examples give concrete locations, but there is no explicit validation or verification checkpoint (e.g. run existing tests to confirm compatibility), so it sits at level 2 with an implicit sequence and no checkpoints rather than the explicit-feedback-loop level 3. Quotes: "Mirror new shared fields in ExcelToolsBase and CliErrorOutput while keeping existing compatibility fields" / "Do not remove existing error fields that current tests or clients already consume."	2 / 3
Progressive Disclosure	No bundle files exist (references/scripts/assets absent) and the skill is under 50 lines, organized into four well-signaled sections (Context, Patterns, Examples, Anti-Patterns); per the simple-skills note this reaches level 3 with well-organized sections and no need for external references.	3 / 3
	Total	11 / 12 Passed

Description

57%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is specific and distinctive within a narrow niche, but lacks an explicit 'Use when...' trigger clause and relies on somewhat technical jargon, leaving the when-to-use implicit.

Suggestions

Add an explicit trigger clause, e.g. "Use when improving diagnostics in the MCP/CLI error seam without altering Core or COM behavior."

Include a couple of natural user-facing terms (e.g. "error messages", "failure responses") alongside the technical "error envelopes" wording.

Optionally enumerate the concrete actions (e.g. "stamp command and sessionId on failed responses, mirror fields across transports") to lift specificity to 3.

Dimension	Reasoning	Score
Specificity	The phrase "Preserve service request context across MCP and CLI error envelopes" names a concrete action (preserve request context) and the target domain (MCP/CLI error envelopes), but lists only one action rather than multiple specific actions, matching the level-2 anchor that names a domain and some actions but is not comprehensive.	2 / 3
Completeness	It states what the skill does ("Preserve service request context...") but provides no explicit "Use when..." trigger guidance, so per the judging guideline a missing trigger clause caps completeness at 2; it is not level 3 because the when is entirely absent, and not level 1 because the what is clearly stated.	2 / 3
Trigger Term Quality	Terms like "MCP", "CLI", and "error" are domain-relevant keywords a developer would say, but "service request context" and "error envelopes" lean technical and miss common natural variations, fitting the level-2 anchor of some relevant keywords with missing variations rather than the fully jargon-free level-1 case.	2 / 3
Distinctiveness Conflict Risk	The niche is sharply scoped to preserving request context across MCP and CLI error envelopes, with triggers (MCP, CLI, error envelopes) unlikely to overlap with unrelated skills, matching the level-3 anchor of a clear niche with distinct triggers.	3 / 3
	Total	9 / 12 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: sbroenne/mcp-server-excel
Commit: b268be5

Reviewed: 7 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.