UNPKG

defect-inspection-tools-mcp-server

Version:

Defect inspection tools server handling defect detection, analysis, and reporting with AI/ML capabilities for quality control

242 lines (197 loc) 11 kB
import { logger } from "../utils/logger.js"; export class PromptHandler { constructor(server) { this.server = server; } // List of available prompts getPromptList() { return [ { name: "defect_server_operating_instructions", description: "general instructions for the user to work with the Defect system", arguments: [] } ]; } async handleGetPrompt(name, arguments_) { try { if (name === "defect_server_operating_instructions") { return this.getGeneralInstructions(arguments_); } else { throw new Error(`Unknown prompt: ${name}`); } } catch (error) { logger.error(`Error calling prompt ${name}:`, error); throw error; } } getGeneralInstructions(arguments_) { const maritimeInstructions = `# Maritime Defect & Inspection Management Server - Operational Guide ## Core Workflow Patterns ### 1. Vessel Defect Status Overview Scenario: Get comprehensive defect status for vessel Step 1: get_vessel_details("Vessel Name") → Get IMO if needed Step 2: get_summary_of_defects(imo="[IMO]") → High-level defect overview Step 3: list_defects_by_stage(imo="[IMO]", stage="OPEN,OPEN OVERDUE") → Critical open items Step 4: universal_defect_search(query="*", filters={"imo": IMO, "riskCategory": "High"}) → Priority defects Result: Complete vessel defect picture with priority actions ### 2. Inspection Due Date Planning and Previous inspection details Scenario: Plan upcoming inspections, preparation and previous inspection details Step 1: get_sire_reports_from_ocimf(imo="[IMO]") → SIRE inspection status Step 2: get_cdi_reports_from_ocimf(imo="[IMO]") → CDI inspection status Step 3: get_vir_status_overview(imo="[IMO]") → VIR schedule Step 4: get_internal_audit_summary(imo="[IMO]") → Internal audit planning Step 5: get_psc_inspection_defects(imo="[IMO]") → PSC history Result: Complete inspection calendar with preparation requirements ### 3. Overdue Defect Management Scenario: Address overdue defects for commercial acceptance Step 1: list_defects_by_stage(imo="[IMO]", stage="OPEN OVERDUE") → All overdue items Step 2: universal_defect_search(query="*", filters={"imo": IMO, "stage": "OPEN OVERDUE", "riskCategory": "High,Medium"}) → Priority overdue Step 3: list_defects_by_status(imo="[IMO]", currentStatus="READY OFFICE REVIEW") → Items pending closure Step 4: For each critical defect, get corrective actions and closure plans Result: Prioritized overdue defect closure plan ### 4. Inspection Preparation Workflow Scenario: "SIRE inspection in 30 days - prepare vessel" Step 1: get_sire_reports_from_ocimf(imo="[IMO]") → Last SIRE inspection details Step 2: list_defects_by_stage(imo="[IMO]", stage="OPEN") → All open defects Step 3: universal_defect_search(query="*", filters={"imo": IMO, "source": "OCIMF", "stage": "OPEN"}) → SIRE-related items Step 4: list_defects_by_inspection_type(imo="[IMO]", inspectionType="SIRE INSPECTION") → Historical SIRE defects Result: SIRE inspection readiness assessment with action items ## Tool Combination Rules ### Always start with vessel identification: - get_vessel_details() first if vessel name provided without IMO - Use IMO consistently across all subsequent defect searches ### For defect status assessment: - get_summary_of_defects() provides high-level overview first - list_defects_by_stage() for specific stage filtering - universal_defect_search() for complex queries requiring multiple filters ### For inspection management: - Use inspection-specific tools (get_sire_reports, get_cdi_reports, etc.) for current status - Combine with historical defect searches for trend analysis - Always check overdue items before upcoming inspections ### For urgent/critical situations: - Filter by stage="OPEN OVERDUE" for immediate attention items - Filter by riskCategory="High" for safety-critical defects - Use currentStatus filters for items pending specific actions ## Common Maritime Defect Questions & Patterns "What's the defect status of [Vessel]?" → get_summary_of_defects() → list_defects_by_stage(stage="OPEN,OPEN OVERDUE") "When is the next SIRE inspection?" → get_sire_reports_from_ocimf() → get_cdi_reports_from_ocimf() "Show overdue defects" → list_defects_by_stage(stage="OPEN OVERDUE") → smart_defect_search(filters={"stage": "OPEN OVERDUE", "riskCategory": "High,Medium"}) "Main engine problems across fleet" → smart_defect_search(query="main engine", filters={"stage": "OPEN", "riskCategory": "High"}) "Prepare for PSC inspection" → get_psc_inspection_defects() → list_defects_by_stage(stage="OPEN") → smart_defect_search(filters={"source": "PSC"}) ## Data Interpretation Guidelines ### Priority Indicators: - stage="OPEN OVERDUE" = immediate action required - riskCategory="High" = safety/commercial risk - currentStatus="READY OFFICE REVIEW" = pending closure - isExtended=true = deadline extensions granted ### Critical Fields for Decision Making: - targetDate, reportDate for timeline management - riskCategory, stage for prioritization - source, inspectionType for inspection regime compliance - finding, correctiveAction for technical details ### Inspection Planning Priorities: - Days remaining until due dates - Open defects from previous inspections - High-risk items requiring immediate attention - Historical patterns for similar vessels ## Error Prevention - Always get schema first using get_defect_table_schema("defect") before complex searches - Validate vessel IMO through get_vessel_details for vessel name queries - Use appropriate date formats (YYYY-MM-DD) for date range filters - Combine multiple tools for comprehensive defect pictures rather than relying on single queries - Cross-reference inspection sources (SIRE, PSC, CLASS) for complete compliance view`; const messages = [ { role: "user", content: { type: "text", text: `${maritimeInstructions}` } } ]; return { messages: messages }; } getCasefileInstructions(arguments_) { const casefileInstructions = ` Role You are an intelligent assistant responsible for structuring and maintaining casefiles for operational tasks. These tasks involve actions executed on specialized servers. Your primary objective is to document and categorize each completed task within a predefined casefile structure. The relevant casefile category will always be specified as input. ⸻ Objectives 1. Maintain structured documentation for server-level task executions. 2. For each new task, ensure it is appended to the specified casefile or initiates a new casefile if necessary, but only if the new information differs from the last recorded entry. 3. Guarantee consistency in casefile organization and avoid redundant entries. ⸻ Operational Workflow 1. Task Execution • Task execution is assumed to be complete before casefile management. 2. Casefile Assignment • The casefile category will be provided as part of the query or command. • Retrieve any existing casefile for the specified category and IMO number. 3. Filing Logic • If Casefile Exists: • Compare: Before appending a new page, carefully compare all relevant operational information in the new task data with the most recent entry in the casefile. • Determine Material Change: Only consider appending a new page if the new task data reflects a material, operationally relevant difference from the previous entry. Material differences may include (but are not limited to): • Change in equipment, system, or process status or condition (e.g., operational → under repair, satisfactory → warning) • Updates to due dates, deadlines, or scheduled actions • Identification of new or resolved issues, including overdue actions • Changes in overall compliance, operational risk, or regulatory status • Addition, removal, or update of any asset, equipment, or component not previously documented • Significant changes in findings, conclusions, or recommendations • New review, inspection, or action date if it represents a change in operational context (not a routine repeat with unchanged status) • Decision: • If any such material difference exists, append a new page with the updated summary and detailed report.Updated Summary should only include the new information that is different from the previous entry. • If there are no material differences—i.e., the new information is substantively identical, or only rephrases/repeats previous facts—do not append or update the casefile. • If Casefile Does Not Exist: • Create the casefile using the provided category name and metadata. • Add the initial page entry with the current task data. ⸻ Casefile Metadata Standards • casefileName: The provided category name . • title: Task or operation name. • casefileSummary: Brief operational synopsis. • currentStatus: Concise state descriptor (e.g., "Completed", "In Progress"). • importance: Always set to 80 ("Important, timely"). • role: Set to "other". • tags: Extracted operationally-relevant keywords (optional). ⸻ Key Rules • Avoid duplicate or redundant task entries. • Only create new casefiles when none exist for the specified category/IMO number. • Do not append or update if the new task data matches the previous entry in all relevant fields. • Maintain concise, actionable, and traceable documentation. ⸻ Critical Success Factors 1. Accurate retrieval and comparison of the most recent casefile entry. 2. Immediate and structured filing post-task execution—but only if new data is different from the last entry. 3. Zero tolerance for categorization errors or untracked tasks. ⸻ Casefile Structure • Index: Event summaries. • Pages: Task entries and details. • Plan: (Optional; not actively referenced in this workflow) ⸻ Operational Mandate Your function is to seamlessly translate completed server tasks into persistent operational records by leveraging the specified casefile architecture. Create or update a casefile only when new information differs from the last entry, ensuring traceability and compliance—without redundancy.`; const messages = [ { role: "user", content: { type: "text", text: `${casefileInstructions}` } } ]; return { messages: messages }; } } //# sourceMappingURL=index.js.map