Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This STDIO-only MCP server has significant definition gaps. Tool names are reasonable (run_sop, publish_sop, submit_sop_feedback, list_resources, read_resource), but descriptions are thin and parameter documentation is sparse. Input schemas are present but minimal, most parameters lack detailed type constraints, format guidance, or range limits. Error handling guidance is absent. The tool composition is functional but does not follow best practices for chaining and discoverability. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear destructive operations (publish_sop, submit_sop_feedback). Return value documentation is not visible in the provided code.
Tools (5)
list_resourcesread onlysource verified53/100
List all available SOPs and resources
publish_sopwrite50/100
Create a new Standard Operating Procedure with linting validation
read_resourceread onlysource verified53/100
Read the contents of a specific SOP or resource
run_sopread only50/100
Execute a Standard Operating Procedure step-by-step
No tool annotations (destructiveHint, idempotentHint, readOnlyHint) despite clear semantic differences. publish_sop and submit_sop_feedback are destructive write operations; run_sop should be marked readOnly. Without annotations, agents cannot reason about side effects or idempotence.
Parameter descriptions are minimal. 'sop_name' (string) appears in multiple tools but lacks guidance: is it a filesystem path, a display name, or a UUID? 'step_output' in run_sop provides no format hint. 'cursor' in list_resources has no explanation of how pagination works or what cursor values are valid.
Tool descriptions are under 200 characters and lack context about when to use each tool. run_sop description ('Execute a Standard Operating Procedure step-by-step') does not explain prerequisites (must call list_resources first?), what happens on error, or what step_output should contain. publish_sop mentions 'linting validation' but gives no detail about what lint rules apply.
Recommendations
Add tool annotations: mark publish_sop and submit_sop_feedback with destructiveHint=true, mark run_sop and read-only tools with readOnlyHint=true. Mark publish_sop and submit_sop_feedback with idempotentHint=false if repeated calls with identical input produce duplicate records.
Expand tool descriptions to 100-200 characters. For run_sop: 'Execute an SOP step-by-step. Call list_resources first to discover available SOPs. Provide the current step number and output from the previous step. Returns next step instructions or completion status.' For publish_sop: 'Create or update an SOP with Markdown content. Performs linting validation (lint rules: [specify]). Rejects content that violates SOP structure requirements. Returns success/failure with violation details if rejected.'
Document parameter formats and constraints in descriptions. For 'current_step': 'Zero-indexed step number (0 for first step). Must not exceed the total number of steps in the SOP.' For 'cursor': 'Opaque pagination token returned in the previous response. Pass null or omit for the first page.' For 'sop_content': 'Markdown text (max 100KB). Must include [required sections: title, steps, notes]. Validated against lint rules on submission.'
Add minimum and maximum bounds to numeric parameters. current_step: minimum 0, maximum inferred from SOP length or documented max (e.g., 1000).
Document error responses with recovery guidance. For run_sop: 'Returns error if step number exceeds SOP length or if step execution fails. If failed, review step prerequisites and previous output, then retry or call read_resource to see full SOP context.' For publish_sop: 'Returns error with lint violation list (e.g., ["Title section missing", "Step 3: no instructions"]) if validation fails. Fix violations and retry.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No input validation constraints visible. 'current_step' is an integer with no bounds, what happens if the agent passes step=-1 or step=99999? 'cursor' has no regex or format. sop_content in publish_sop accepts any string, should it validate Markdown syntax, length limits, or required sections?
Error handling and recovery guidance is absent. If run_sop fails on a step, what should the agent do? Retry? Skip? Abort the SOP? If publish_sop detects lint errors, what is the response structure, does it list violations or just reject silently? If list_resources returns empty, is that success or failure?
No output schema documentation visible. Tools are declared but return types and field structures are not documented in the provided source. Agents cannot plan downstream calls without knowing whether read_resource returns raw Markdown, parsed JSON, or enriched metadata.
Tool composition requires agents to discover the right sequence. To execute an SOP, must the agent call list_resources first? If so, this should be documented in run_sop's description as a prerequisite. Currently, an agent could call run_sop blindly without knowing available SOPs.
Pagination in list_resources uses a 'cursor' string parameter with no documentation of format, lifecycle, or exhaustion. Standard approach: return next_cursor in response (or null when exhausted) and document cursor lifecycle in description.
Parameter naming could be more explicit. In submit_sop_feedback, 'feedback' is generic, should it be 'improvement_suggestion' or 'feedback_text'? In list_resources, 'cursor' should be prefixed with a context hint like 'page_cursor' or 'resource_cursor' to avoid ambiguity when agents have multiple cursors in memory.
Add prerequisites and composition hints to descriptions. For run_sop: 'Prerequisite: call list_resources to obtain a valid sop_name. Each step depends on the previous step\'s output, do not skip steps.' For publish_sop: 'After publishing, call list_resources to verify the SOP is discoverable, and read_resource to confirm content.'
Clarify parameter naming for consistency and discoverability. Rename 'feedback' to 'feedback_text' or 'improvement_suggestion' to avoid confusion with generic 'feedback' loops. Rename 'cursor' to 'pagination_cursor' or 'next_cursor' for clarity.
Add idempotency guarantees or clarify non-idempotency. If publish_sop with the same sop_name and sop_content is safe to call twice (idempotent update), state this. If it creates a duplicate version or errors, state that too so agents retry appropriately.
Document the lint rules enforced by publish_sop. Provide a link or embedded list: 'Lint rules: [required-title, required-steps, max-step-length-2000, no-circular-refs]. Call sop-lint CLI offline to validate before publishing.' This prevents agent confusion when linting fails.