Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The PMS Analysis Reports MCP server presents a domain-specialized toolkit with 11 read-only tools for vessel maintenance and fuel analysis. While tool names follow action-verb conventions (get_, search_, export_) and basic parameter structures are present, the evaluation reveals significant gaps in schema completeness, parameter descriptions, and output documentation that prevent higher scores. All tools are READ_ONLY, which simplifies error handling but does not excuse missing parameter details. Average tool quality: 52/100.
Output schemas are not documented. Tools return strings (CSV, JSON text) or undefined structures without explicit field definitions. LLMs cannot plan downstream operations or extract structured data.
Document output schemas for all tools. Specify whether results are returned as JSON-parsed objects, CSV strings, or plain text, and list all expected fields with types. Example: universal_fuel_analysis_search should return {results: [{vesselName: string, sampleId: string, ...}], total_count: integer, page: integer, has_next: boolean}.
Convert enum parameters to formal JSON Schema enums. Change 'question_no' from type 'integer' to type 'integer' with enum: [7, 30, 112, 116, 128, 177, 261]. Change 'category' to enum: [forms_related_to_main_engine, ...]. This prevents LLM hallucination.
Add min/max bounds to numeric parameters. Change 'page' to minimum: 1, default: 1. Change 'per_page' to minimum: 1, maximum: 250, default: 50. Add bounds to 'limit' in get_historical_engine_performance.
Rewrite tool descriptions to answer: (1) What does it do? (2) When should I use it instead of similar tools? (3) What format is the output? Example: 'Search Fuel Oil Analysis records by vessel name, fuel type, or test lab. Returns paginated results with up to 250 records per page. Use this to find specific fuel samples; for exports, use export_fleet_pms instead.'
Replace example values in descriptions with formal constraints. Change 'filter_by: Typesense filter syntax (e.g. "imo:9334722 && bunkerDate:>=2024-01-01")' to 'filter_by: Typesense filter syntax. Field names are case-sensitive. Dates use YYYY-MM-DD format. Example fields: imo, bunkerDate, fuelType. See Typesense docs for full syntax.'
Add recovery guidance to error responses. When a vessel/fleet is not found, return 'No vessels found for fleet IMO {fleet_imo}. Verify the IMO number is correct. Call search_vessel_by_name if you only have the vessel name.'
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 7 points across a rubric change (v1 → v2)
51/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
51
2026-07-28+
v2
2026-03-09
F
44
-
v1
read onlyauthsource verified62/100
Retrieve PMS information for a vessel by question type.
Universal search for ALL Planned Maintenance System (PMS) operations.
Provides full-text search, filtering, and pagination over the PMS maintenance collection.
Enum parameters not declared as JSON Schema enums. 'question_no' accepts specific integers (7, 30, 112, etc.) but is defined as type 'integer' without enum constraint. 'category' and 'engine_name' similarly lack formal enum declarations, inviting hallucinated values.
No error recovery guidance. Tools return raw error strings (e.g., 'No vessels found for fleet IMO: {fleet_imo}') without suggesting next steps. No per-tool guidance on retryability or recovery actions.
Pagination support inconsistent. Universal search tools (universal_fuel_analysis_search, etc.) accept 'page' and 'per_page' but return unstructured text with no metadata (total_count, has_next, next_page). Export tools return CSV strings without pagination. Agents cannot determine if more results exist.
Tool descriptions are generic domain summaries rather than LLM-optimized action specs. E.g., 'Universal search for ALL Fuel Oil Analysis operations' does not explain WHEN to use this vs. other search tools, what the expected input format is, or what fields the output contains.
Result limits not enforced or stated in descriptions. 'export_fleet_pms' caps at 10,000 records internally but does not advertise this limit to agents. Agents cannot reason about whether truncation occurred.
Tool implementations delegate to helper functions (combined_mongotools_with_single_category_mapping, etc.) that are not visible in provided source. Schemas and error handling logic cannot be verified. Actual behavior may diverge from documented descriptions.
Return structured pagination metadata in all search tool responses. Include total_count, current_page, per_page, and has_next_page. Example: {results: [...], total_count: 523, current_page: 1, per_page: 50, has_next_page: true}.
Document maximum result limits in tool descriptions. State: 'Returns up to 250 results per page. To export all records, use export_fleet_pms.' Ensure export tools document their 10,000-record cap and return a warning if results are truncated.
Verify and expose helper function schemas. Ensure combined_mongotools_with_single_category_mapping and related functions explicitly declare their output structure. Consider inlining critical logic or providing a separate schema document.
Add parameter relationships documentation. Clarify that 'question_no' is dependent on the tool context (get_vessel_pms_information accepts different values than get_fleet_pms_forms_fuel_information). Document this in each tool's description.