Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
ICE Locator MCP exhibits moderate definition quality with significant gaps. All 5 tools have basic verb-starting names (search_*, generate_*) and explicit JSON schemas, but suffer from sparse parameter descriptions, incomplete error guidance, and missing output schema documentation. The server attempts structured input validation but lacks LLM-facing descriptions that explain WHEN to use each tool vs. its peers, and HOW to handle failures. Parameter descriptions exist but are often generic (e.g., 'Response language (default: en)' provides no usage guidance). No tool annotations (readOnly/destructive hints) are present despite the read-only nature of all tools being security-relevant. The 'bulk_search_detainees' tool shows attempt at composition (batch variant) but lacks per-item error reporting. Overall, this reads as a competent API wrapper with basic MCP translation, not LLM-optimized tooling.
No output schemas documented for any of the 5 tools. LLMs cannot plan downstream operations or extract required fields without knowing the response structure.
Parameter descriptions are generic and lack LLM-facing constraints. E.g., alien_number has no format spec, search_criteria in generate_search_report has no type constraint, and fuzzy_search lacks explanation of matching thresholds. Rubric:C states 'Describe the expected format, range, and allowed values directly in the parameter description.'
No tool annotations (readOnlyHint, idempotentHint) present. All 5 tools are read-only according to the feature list, but LLMs cannot infer this without annotation. Spec Alignment (2026-07-28) rewards tool annotations as a current pattern.
Recommendations
Document output schema for each tool. For search tools, specify: { detainees: [{ id, first_name, last_name, date_of_birth, country_of_birth, alien_number, ... }], total_count, next_cursor?, timestamp } or similar. For generate_search_report, specify: { report_content: string, format: string, byte_size: number, generated_at: ISO8601 }.
Expand tool descriptions from 45 - 55 chars to 150 - 250 chars, explicitly stating: (1) WHAT the tool does, (2) WHEN to use it vs. similar tools, (3) prerequisites/assumptions, (4) example use case. E.g., 'Use search_detainee_by_alien_number when you have the A-number (e.g., A12345678) for faster, exact-match lookup. If you only have partial names or DOB, use search_detainee_by_name with fuzzy_search=true. If the query is a natural-language sentence (e.g., "Find John who was detained in 2023"), use smart_detainee_search.'
Add enum constraints to parameter descriptions and schema. E.g., report_type: enum('legal', 'advocacy', 'statistical'); format: enum('markdown', 'html', 'pdf'). For alien_number, add pattern: '^A\d{1,9}$' and description: 'Alien registration number in format A##### (e.g., A12345678).'
Add tool annotations. Wrap each tool definition with { readOnlyHint: true } or { idempotentHint: true } to signal safety properties to the LLM.
Document error recovery for all tools. E.g., 'If no results found, return: { detainees: [], total_count: 0, suggestion: "Try search_detainee_by_alien_number if you have the A-number, or use fuzzy_search=true for partial name matching." }' and 'If alien_number format is invalid, return: { error: "Invalid A-number format. Must match A###### (e.g., A12345678)" }.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Error handling absent from tool descriptions. No guidance on what to do if search returns no results, if alien_number format is invalid, or if report generation fails. Rubric:E states 'Error responses must tell the LLM what to do next.'
Tool selection guidance missing. 'search_detainee_by_name', 'search_detainee_by_alien_number', and 'smart_detainee_search' overlap in function (all search for a detainee). LLM cannot distinguish when to call which without explicit guidance in descriptions.
bulk_search_detainees lacks documented per-item error reporting. Rubric:D states 'When processing multiple items, return per-item success/failure.' continue_on_error=true implies partial failures are possible, but the output schema does not document success/failure tracking.
Enum constraints missing for open-ended parameters. generate_search_report's report_type and format lack enum declarations, allowing LLMs to hallucinate values like 'report_type: xml' or 'format: docx'.
generate_search_report
Add length bounds and validation guidance to numeric/string parameters. E.g., fuzzy_search description: 'Enable fuzzy name matching (default: true). When true, matches within 80% similarity are returned; when false, only exact matches.' max_concurrent description: 'Maximum concurrent searches (1 - 5, default 3). Higher values increase throughput but may trigger rate limits.'
For bulk_search_detainees, document per-item results structure. E.g., 'Returns array of results, each with { request_index, status: "success"|"not_found"|"error", detainee?: {...}, error_message?: "..." }. If continue_on_error=true, partial results are included.'
For generate_search_report, document max result size and truncation policy. E.g., 'If results exceed 100 items, report includes top 50 by relevance and notes truncation.'
Consider renaming 'smart_detainee_search' to 'search_detainee_natural_language' to be more specific about the tool's function and reduce LLM ambiguity.