Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The server implements 12 tools with mixed quality. Naming follows verb_noun conventions (list_databases, run_query, cloud_list_organizations) which is good. All tools have descriptions, though many are generic and lack the specificity needed for robust LLM decision-making. Critical gaps: input schemas visible but inconsistently documented; parameter descriptions are present but often lack constraint details (min/max, enum values); no output schemas documented anywhere; error handling is missing (no guidance on retryability, user-fixable vs fatal classification); security concerns around query execution and cloud API access are not addressed; parameter relationships and dependencies undocumented. The fastmcp framework is used but there's no evidence of response shaping, pagination support, or result limiting for list operations. Tool composition is reasonable (separate cloud vs on-prem concerns) but lacks chaining IDs and related context in responses. This is a C-grade server: functional definitions with significant gaps in robustness.
run_query tool lacks critical safeguards: no output schema documented, no query timeout specified, no guidance on retryability or error recovery. Agents have no visibility into what data is returned or how to handle failed queries. SQL injection risk unaddressed.
cloud_create_service has 18 parameters with inconsistent descriptions. Many lack min/max bounds (e.g., num_replicas accepts 1-20 but this is only stated in description text, not as JSON Schema constraints). Complex enum constraints (provider, tier, region) are not formalized, they appear as plain text descriptions, forcing LLMs to parse and remember valid values.
No output schemas documented for any tool. LLMs cannot know what fields to expect in responses, making downstream tool chaining impossible and forcing agents to discover response structure via trial and error. E.g., cloud_list_organizations returns a 'list of organizations', but what fields does each organization have? How should an agent extract organization_id for cloud_get_organization?
Recommendations
Document complete output schemas for all 12 tools in JSDoc/docstring format. For cloud_list_organizations, specify: returns [{organization_id: string (UUID), name: string, ...fields}], total_count: integer, has_more: boolean, next_cursor: string|null}. For run_query, specify: returns {columns: string[], rows: array of arrays, execution_time_ms: integer}.
Add pagination to all list_* tools: add limit (default 20, max 100), offset/cursor, and include total_count in response. Document result limits in tool descriptions: 'Returns up to 20 organizations. Use offset/limit for pagination.'
Formalize enum constraints as JSON Schema enums rather than free-form text. E.g., for cloud_create_service: 'provider': {type: 'string', enum: ['aws', 'gcp', 'azure']}, 'tier': {type: 'string', enum: ['development', 'production']}. Add minLength/maxLength and pattern for string fields.
Add min/max bounds to numeric parameters in JSON Schema. E.g., num_replicas: {type: 'integer', minimum: 1, maximum: 20}. Include these in the description text as well: 'Number of replicas (1 - 20, default 1).'
Implement query timeout (e.g., 30s default) and document it: 'run_query executes with a 30-second timeout. Queries exceeding this will return a timeout error. Consider LIMIT or WHERE clauses to reduce execution time.'
Add SQL injection and command injection safeguards to run_query. Validate that the query does not contain destructive operations (DROP, DELETE, ALTER, TRUNCATE) unless explicitly allowed. Log all queries with user/agent ID, timestamp, and execution time for audit trails.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Update basic service details like service name or IP access list.
list_databasesread onlyauthsource verified75/100
List available ClickHouse databases.
list_tablesread onlyauthsource verified76/100
List available ClickHouse tables in a database. Returns detailed information about tables including schema, comments, row counts, and column information.
list_* tools (list_databases, list_tables, cloud_list_organizations, cloud_list_services) have no pagination parameters (limit, offset, page_size, cursor). No return count or total. Without pagination, these tools risk returning thousands of items and exhausting context windows.
Destructive operations (cloud_create_service, cloud_update_organization, cloud_update_service) lack confirmation or dry-run support. Agents making mistakes will directly create resources or update cloud configurations with no rollback. No tool provides compensation (delete/rollback) for failed multi-step operations.
No error handling or recovery guidance. Tools do not document which errors are retryable (network timeouts) vs user-fixable (invalid organization_id) vs fatal (permission denied). Agents cannot reason about retry logic or next steps.
Security: run_query tool accepts arbitrary SQL from the agent with no input validation, logging, or query categorization. Agents could execute DROP TABLE, INSERT, or ALTER commands if given those instructions. No audit trail, no rate limiting, no query timeout protection.
Parameter naming inconsistency: cloud_* tools use 'organization_id' and 'service_id' (UUID strings), but descriptions do not clearly state this is a UUID or how agents should obtain these IDs. Natural identifiers (organization name, service name) are not accepted, forcing agents to call cloud_list_* first to discover IDs.
Descriptions are generic and lack WHEN to use guidance. E.g., 'List available ClickHouse databases' does not explain when to call this vs run_query with SHOW DATABASES. Many descriptions are under 100 characters and provide minimal context for LLM tool selection.
Tool composition gap: create/update tools return minimal responses (no indication of success, no new resource IDs). cloud_create_service should return the created service_id, organization_id, and connection details so agents can immediately use the service. Current response structure unknown.
Document error responses with recovery guidance. E.g., 'Error: Invalid organization_id. Available organizations: [list]. Try cloud_list_organizations to find the correct ID.' Categorize: 'This error is retryable (network timeout), recommend retry with exponential backoff.'
Add confirmation/dry-run support to destructive tools. cloud_create_service should accept a 'dry_run' parameter (default false) that validates the request without creating the service. For updates, return a preview of changes and ask user confirmation via MRTR (Multi Round-Trip Requests) before committing.
Accept natural identifiers (organization_name, service_name) alongside UUIDs. Internally resolve names to IDs, or document clearly: 'organization_id must be a UUID. Use cloud_list_organizations to find the organization_id for a given name.'
Enhance descriptions with WHEN and WHY. E.g., 'List all databases in the connected ClickHouse instance. Use this before querying to discover available data. Equivalent to SHOW DATABASES, but returns structured output.'
Implement rate limiting and document it: 'run_query is rate-limited to 100 queries per minute per agent. Exceeding this returns a 429 error with Retry-After header. Reduce parallelism or cache results.'
Design tools to return chaining IDs. cloud_create_service must return the new service_id, organization_id, region, and endpoint so agents can immediately call cloud_get_service or connect. Don't force an extra lookup.
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) for clarity: list_* and run_query (read-only) should have readOnlyHint=true; cloud_create_service and cloud_update_* should have destructiveHint=true.
Document parameter relationships. E.g., for cloud_create_service: 'If min_replica_memory_gb is set, max_replica_memory_gb must be >= min_replica_memory_gb. Both must be multiples of 4.'
Split cloud_update_organization into separate tools or add conditional parameter documentation. Currently, 'private_endpoints' parameter is vague, is it a replacement or merge operation? Document: 'private_endpoints (object): Configuration to add/remove endpoints. Structure: {add: [{...}], remove: [ids]}. If omitted, existing endpoints are unchanged.'