IEC 62304 Requirements 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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_requirementA | Create a new software requirement (IEC 62304 Section 5.2.2) Args: req_id: Unique requirement ID (e.g., SWR-001) title: Short descriptive title (10-200 chars) description: Detailed requirement description (min 20 chars) category: functional, performance, interface, safety, security, usability priority: critical, high, medium, low created_by: Name of person creating requirement safety_classification: class_a, class_b, or class_c (default: class_c) rationale: Justification for the requirement (optional) acceptance_criteria: Verification criteria (optional) Returns: Success message with requirement ID Example: create_requirement( req_id="SWR-001", title="User Authentication Required", description="The system shall authenticate users using bcrypt algorithm with minimum 12 rounds before granting access to patient data", category="security", priority="critical", created_by="John Doe", rationale="Required for HIPAA compliance" ) |
| get_requirementA | Retrieve a requirement by ID Args: req_id: Requirement ID (e.g., SWR-001) Returns: Formatted requirement details including traceability links |
| update_requirementA | Update requirement with version control (IEC 62304 Section 8) Args: req_id: Requirement ID to update changed_by: Name of person making change change_reason: Reason for the change (required for audit) title: New title (optional) description: New description (optional) status: New status - draft, reviewed, approved, implemented, verified (optional) priority: New priority - critical, high, medium, low (optional) Returns: Success message with new version number |
| get_requirement_historyA | Get complete version history (IEC 62304 Section 8.1.2) Args: req_id: Requirement ID Returns: Formatted version history with all changes |
| create_traceability_linkA | Create traceability link (IEC 62304 Section 5.1.1) Args: source_id: Source artifact ID (e.g., SWR-001) source_type: requirement, design, test, or risk target_id: Target artifact ID (e.g., DESIGN-001) target_type: requirement, design, test, or risk link_type: derives_from, implements, verifies, mitigates, or relates_to description: Optional link description Returns: Success message with link ID Example: create_traceability_link( source_id="SWR-001", source_type="requirement", target_id="DESIGN-AUTH-001", target_type="design", link_type="implements" ) |
| search_requirementsA | Search and filter requirements Args: status: Filter by status - draft, reviewed, approved, implemented, verified (optional) category: Filter by category - functional, performance, interface, safety, security, usability (optional) safety_class: Filter by safety classification - class_a, class_b, class_c (optional) search_text: Search in title and description (optional) Returns: List of matching requirements |
| generate_traceability_matrixA | Generate complete traceability matrix (IEC 62304 Section 5.1.1) Args: export_path: File path for CSV export (default: docs/traceability_matrix.csv) Returns: Success message with file path |
| generate_srs_documentA | Generate Software Requirements Specification (IEC 62304 Section 5.2.6) Args: export_path: File path for SRS document (default: docs/SRS_Document.md) Returns: Success message with file path |
| get_dashboard_statisticsA | Get requirements dashboard statistics Returns: Formatted statistics summary including counts by status, category, and traceability coverage |
| create_risk_controlA | Create risk control with requirement linkage (ISO 14971 integration) Args: risk_id: Unique risk ID (e.g., RK-001) hazard_description: Description of the hazard severity: Catastrophic, Critical, Marginal, or Negligible probability: Frequent, Probable, Occasional, Remote, or Improbable control_measures: Risk mitigation measures description requirement_id: Linked requirement ID (optional) Returns: Success message with risk ID and calculated risk level |
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 10 tools
Each tool targets a distinct operation: requirement CRUD/history, traceability link creation and matrix generation, SRS export, dashboard stats, and risk control creation. There is no meaningful overlap in purpose, and the argument names reinforce the boundaries.
All tools follow the same snake_case verb_noun pattern (create_requirement, get_requirement_history, generate_srs_document). The consistency makes the action and resource predictable across the entire server.
Ten tools is well-scoped for an IEC 62304 requirements management server, covering creation, retrieval, update, history, search, traceability, export, dashboard, and risk control. No tool feels redundant or unnecessary, and the count stays within the ideal range.
Core requirement lifecycle and traceability workflows are covered, including versioned updates, history, matrix generation, and SRS export. Minor gaps exist for deletion/obsoletion of requirements and full risk-control management (only create_risk_control is provided), but these are workable within the stated regulatory context.