MCP server for AccuKnox CSPM (Cloud Security Posture Management) that provides tools to search and filter cloud infrastructure assets, retrieve AI/ML model security vulnerabilities, and manage security findings.
AccuKnox MCP server has 4 tools with significant definition quality issues. Two tools are duplicates (search_assets appears twice with nearly identical definitions), reducing effective tool count to 3 unique tools. Descriptions are present and reasonably detailed (150-300 chars), but parameter descriptions lack depth and constraint guidance. Input schemas are well-formed with proper types, but several parameters lack sufficient constraint documentation (enums, ranges, formats). Output schemas are not explicitly documented, responses are formatted as text strings rather than structured objects, making downstream tool chaining difficult for agents. Error handling guidance is absent. The server exposes significant security concerns: it accepts optional date filters and filters without validation constraints, and includes an include_endpoint parameter that may expose internal infrastructure details. Tool composition is reasonable (search and vulnerability lookup are separate), but the duplicate search_assets tool suggests maintenance issues.
Provide a unified list of available data types for all finding-related tools. Select the data type to provide finding details for tools.
READ-ONLY: Get AI/ML model security vulnerabilities summary. Retrieves a comprehensive summary of security issues across: - ML Models (machine learning models) - LLM Models (large language models) - Datasets Shows breakdown by severity: Critical, High, Medium, Low Args: include_endpoint: If True, includes the API endpoint URL in the response Returns: Formatted vulnerability report with severity breakdown and recommendations Examples: - "Show me model vulnerabilities" - "What security issues do my AI models have?" - "List all model security problems" - "Show vulnerabilities with endpoint URL" → include_endpoint=True
READ-ONLY: Search and filter cloud infrastructure assets. Args: asset_id: Filter by specific asset ID type_name: Filter by asset type name type_category: Filter by category (sCommon categories: Configuration, User, Models, Block Storage, CI/CD, Datasets, Container, Audit logging, IaC_github-repository) label_name: Filter by label name region: Filter by cloud region cloud_provider: Filter by provider (aws, azure, gcp) return_type: "list" (default) or "count" limit: Maximum results to return (default: 10) detailed: Include vulnerabilities and compliance data deployed: Optional[bool]. Set to True for deployed models, False for undeployed models, or None (default) to ignore deployment status. present_on_date_after: Filter assets present on or after this date. Format: YYYY-MM-DD. Defaults to two days ago if not provided. present_on_date_before: Filter assets present on or before this date. Format: YYYY-MM-DD. Defaults to now if not provided include_endpoint: If True, includes the API endpoint URL in the response Returns: Formatted asset list, count, or model statistics Examples: - "How many Models do I have?" → type_category="Models", return_type="count" - "Show me deployed models" → deployed=True - "Show me Container assets" → type_category="Container" - "List AWS assets" → cloud_provider="aws" - "Show assets with security details" → detailed=True - "Show assets with endpoint URL" → include_endpoint=True
Duplicate tool definition: search_assets appears twice (tools 1 and 3) with near-identical descriptions and schemas. This violates the single-responsibility and composition patterns and indicates maintenance debt.
Output schemas not documented. Tools return formatted text strings (e.g., 'Formatted asset list', 'Formatted vulnerability report') rather than structured JSON objects. Agents cannot reliably parse responses or extract fields needed for downstream tool calls (e.g., asset_id, vulnerability counts). This breaks tool chaining.
Date parameters (present_on_date_after, present_on_date_before) lack constraint documentation. Descriptions state 'Format: YYYY-MM-DD' but do not specify validation (e.g., must be a valid date, cannot be in future, must be after present_on_date_after). Agents may pass malformed dates without guidance on recovery.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
READ-ONLY: Search and filter cloud infrastructure assets. Args: asset_id: Filter by specific asset ID type_name: Filter by asset type name type_category: Filter by category (sCommon categories: Configuration, User, Models, Block Storage, CI/CD, Datasets, Container, Audit logging, IaC_github-repository) label_name: Filter by label name region: Filter by cloud region cloud_provider: Filter by provider (aws, azure, gcp) return_type: "list" (default) or "count" limit: Maximum results to return (default: 10) detailed: Include vulnerabilities and compliance data deployed: Optional[bool]. Set to True for deployed models, False for undeployed models, or None (default) to ignore deployment status. present_on_date_after: Filter assets present on or after this date. Format: YYYY-MM-DD. Defaults to two days ago if not provided. present_on_date_before: Filter assets present on or before this date. Format: YYYY-MM-DD. Defaults to now if not provided ctx: FastMCP Context (injected automatically) Returns: Formatted asset list, count, or model statistics Examples: - "How many Models do I have?" → type_category="Models", return_type="count" - "Show me deployed models" → deployed=True - "Show me Container assets" → type_category="Container" - "List AWS assets" → cloud_provider="aws" - "Show assets with security details" → detailed=True
Enum parameters (cloud_provider, return_type, type_category) are documented as strings with examples in descriptions, but not declared as formal enums in the schema. E.g., cloud_provider description says 'Filter by provider (aws, azure, gcp)' but the schema lists type:'string' with no enum constraint. Agents may pass invalid values.
data_type_selection has an empty input schema ({}) with a vague description ('Provide a unified list of available data types for all finding-related tools. Select the data type to provide finding details for tools.'). It is unclear what this tool does, when to call it, or what it returns. The description does not explain the action, prerequisite, or return value.
include_endpoint parameter appears in multiple tools and is poorly documented. It is described as 'If True, includes the API endpoint URL in the response' but does not explain why an agent would want internal endpoint URLs or whether this exposes sensitive infrastructure details. Security implications not addressed.
No error handling guidance. Descriptions and schemas do not indicate what happens on invalid input (e.g., malformed date, invalid cloud_provider, asset not found). No recovery suggestions or error classifications (retryable vs. fatal). Agents lack guidance on next steps after failures.
Parameter 'limit' in search_assets lacks min/max bounds. Schema specifies default:10 but does not constrain maximum. An agent could request limit:999999, potentially causing memory exhaustion or API timeout. Description should state 'Maximum results to return (1-1000, default: 10)' with schema minItems/maxItems.
Parameter 'deployed' in search_assets has ambiguous documentation: 'Optional[bool]. Set to True for deployed models, False for undeployed models, or None (default) to ignore deployment status.' The description conflates optional (can omit) with tri-state (True/False/None). JSON Schema represents optional parameters via 'required' array, not union types. This confuses agents about valid inputs.