Critical gaps across all three tools. Tool definitions are inferred from docstrings in mcp_tools.py rather than explicit MCP schema registration. No visible input schemas, parameter type definitions, or structured output schemas. Descriptions exist but are generic (avg ~60 chars) and lack actionable guidance for LLM selection. The fs_* tool is delegated to an external server with no local schema visibility. contrast_search_applications and contrast_get_route_coverage lack parameter documentation, type constraints, and error recovery guidance. No evidence of pagination, result limits, or chaining IDs. Security: Contrast credentials passed via environment variables (correct), but no per-tool permission declarations or audit logging visible.

• Define explicit JSON Schema for each tool's input parameters. For contrast_search_applications, specify: search_query (string, required, 1-256 chars), search_type (enum: name|tags|language), limit (integer, 1-50, default 20), offset (integer, default 0). Include descriptions for each.
• Document output schemas. E.g., contrast_search_applications returns {applications: [{id, name, tags, languages, routes}], total_count, next_offset}. Ensure application_id is included so downstream tools can chain.
• Add error recovery guidance to descriptions. E.g., 'Returns empty list if no matches found. If searching by name, try partial matches or search_by_tags instead.'
• Implement pagination with limit and offset parameters. Cap results at 20-50 items per call. Document the limit in the tool description.
• Add tool annotations (readOnlyHint: true for all three, since they are read-only per the risk assessment) to signal to clients that these tools are safe to call without confirmation.