This server exposes 8 tools for MCP/LLM integration orchestration but suffers from critical definition gaps across all dimensions. Tool names lack clarity (McpCallTool, McpListToolsTask, LlmAgent are vague about action/scope); descriptions are present but generic (averaging ~100 chars, below the 194 char production baseline); parameter schemas are minimally documented with missing type constraints and validation rules; output schemas are not documented; error handling provides no recovery guidance. The server itself operates via HTTP (fastmcp), which is transport-compliant, but tool definitions are fragmented across task classes with no visible input schema registration in MCP format. Critical pattern violations: tool names do not follow verb_noun convention consistently; parameter descriptions are surface-level (e.g., 'MCP server configuration' repeated 5 times with no clarification of required fields, format, or constraints); no enum constraints for known-set values; no indication of which tools modify state vs. read-only (despite marking some WRITE/READ_ONLY in metadata, this is not communicated in descriptions); output field naming and chaining requirements not documented; error scenarios (connection failure, timeout, malformed input) mentioned in code but not reflected in tool descriptions as recovery guidance.
Tools (8)
LlmAgentwriteauthsource verified45/100
Executes an AI agent that can access multiple MCP servers to complete complex tasks requiring tool use
LlmChatread onlyauthsource verified50/100
Provides a chat interface with an LLM that maintains conversation history and supports user interaction within a task
API key and secrets exposed in parameter descriptions. 'server' and 'model' parameters describe configuration as containing 'api key', 'auth details' in plaintext descriptions. Tool parameter descriptions should NEVER mention secrets. This violates secret-injection pattern and risks leaking credentials into LLM context and logs.
Parameter 'server' described identically across 5 tools as 'MCP server configuration containing url, transport type, and authentication details' with no specification of required/optional fields, format constraints, or validation rules. LLMs cannot infer structure from generic description. Should specify: {url: string, transport: 'sse'|'http', auth?: {type: string, token?: string}}.
No input schemas visible for any tool. Tool definitions lack structured JSON Schema with type, required, properties, enum constraints. Parameter descriptions exist but schemas are not formally defined in MCP registration. This prevents structured tool calling and forces LLMs to guess valid formats.
Output schemas not documented for any tool. Code shows result extraction and property setting (set_output_property('result', ...), set_output_property('tools', ...)) but no formal documentation of return types, field names, or structures. LLMs cannot chain tools without knowing what fields to extract.
State-modifying tools (McpCallTool with WRITE risk, LlmAgent) lack idempotency guarantees and confirmation/dry-run patterns. McpCallTool can execute any remote tool (create, delete, update) but provides no dry-run, confirmation step, or idempotency documentation. Agents may accidentally trigger irreversible operations.
Error handling provides no recovery guidance. Code catches exceptions (TimeoutError, JSONDecodeError, RuntimeError) but tool descriptions do not document error scenarios or suggest next steps. E.g., 'Tool execution timed out after X seconds, consider reducing input size or retrying with a longer timeout' would guide the agent.
Parameter naming inconsistencies. 'McpToolLookupScript' accepts '_ci' (config item) while others accept 'server', no documentation of why or how they differ. 'LlmAgent' uses numbered parameters (mcpServer1, mcpServer2, mcpServer3) instead of an array, signaling incomplete design and making multi-server scenarios awkward.
No enum constraints for known-set values. 'server.transport' can be 'sse' or 'http' (visible in code) but not documented or constrained in description. 'model.provider' likely has known values (OpenAI, Google, Azure) but none are listed. LLMs hallucinate unsupported values without explicit enums.
LlmAgent accepts up to 3 MCP servers but no documentation of selection strategy, priority, or how tools are routed across servers. Agents may misallocate tools or call the wrong server repeatedly.
LlmAgent
Remove 'api key' and 'authentication details' from parameter descriptions. Instead, document: 'Server configuration (url, transport type). Authentication is managed server-side via environment variables or vault; do not include secrets in parameters.'
Add recovery guidance to tool descriptions. Example for McpCallTool: 'Calls a specified MCP tool on a remote MCP server. If the connection times out, verify the server URL and network access. If the tool returns an error, check that the input parameters match the tool's schema (run list_mcp_tools first to inspect available tools).'
Replace numbered server parameters in LlmAgent with a single 'mcp_servers' array parameter: { type: 'array', items: { type: 'object', properties: { name: { type: 'string' }, config: { type: 'object' } } }, description: 'List of MCP servers the agent can access. Each server will be queried in order when the agent needs a tool.' }. Document the agent's strategy: 'The agent will first attempt the primary server; if no matching tool exists, it will try secondary servers in order.'
Add enum constraints to 'transport' parameter: { type: 'string', enum: ['http', 'sse'], description: 'Transport protocol: http for standard JSON-RPC over HTTPS, sse for Server-Sent Events (streaming, preferred for agentic patterns).' }
Document state-modifying behavior for McpCallTool and LlmAgent: 'This tool executes a remote operation that may create, update, or delete data. Ensure the remote tool is safe to retry (idempotent). If uncertain, use test_mcp_connection to validate the remote tool first, or run a dry-run variant if available.'
Add _mcp_readOnlyHint and _mcp_destructiveHint tool annotations (MCP 2026-07-28 spec) to mark McpCallTool and LlmAgent as potentially destructive, guiding agent planning and confirmation behavior.
Document timeout behavior for LlmChat: 'If the chat session exceeds maxIdleTimeout seconds without user input, the session is closed and conversation history is cleared. The agent must start a new session. Default 300 seconds; range 10 - 3600.'
Add per-tool error classification (retryable, user-fixable, fatal). Example: 'Connection timeout (retryable: true, message: Retry with a longer timeout or verify server availability), Invalid input (retryable: false, user-fixable: true, message: Check parameter format against tool schema), Unauthorized (retryable: false, user-fixable: false, message: Verify authentication credentials).'
Specify limits and pagination for tools that return lists (e.g., McpListToolsTask, LlmAgent result). Document: 'This tool returns up to 100 tools by default. If the remote server has more, pagination is not supported, contact the server maintainer to filter results by category or tag.'
Clarify 'ping' behavior in McpTestConnection: 'Sends a minimal request to the remote MCP server to verify connectivity and basic availability. Does not test tool functionality or permissions. Returns success if the server responds within timeout seconds; otherwise, returns a connection error with diagnostic details.'