A desktop application that integrates LLM capabilities with MCP (Model Context Protocol) servers, enabling chat-based interaction with configurable language models and MCP server management
PuenteLLM MCP has significant definition quality gaps. Tool descriptions are minimal and lack actionable context. Input schemas are present for some tools but lack parameter-level descriptions. Output schemas are not documented. The server implements 6 tools focused on MCP server gallery management, but definitions are sparse and do not follow production-quality patterns. Spanish descriptions do not mitigate the need for complete English LLM-optimized documentation. No error handling guidance, no parameter constraints (e.g., enums), and no indication of idempotency or state-modifying behavior beyond Risk labels.
Tools (6)
add_mcpwritesource verified57/100
Añade un nuevo servidor MCP a la galería.
get_mcpread onlysource verified52/100
Obtiene detalles extendidos de un servidor MCP específico.
health_checkread onlysource verified30/100
Endpoint de salud del servicio.
list_mcpsread onlysource verified37/100
Obtiene la lista de todos los servidores MCP disponibles.
remove_mcpdestructivesource verified48/100
Elimina un servidor MCP de la galería.
search_mcpsread onlysource verified51/100
Busca servidores MCP en la galería por término y etiquetas.
Tool descriptions are too brief (<50 characters for most tools). 'Obtiene detalles extendidos de un servidor MCP específico' (Spanish) does not explain WHEN to call this vs list_mcps, WHAT fields are returned, or how to use the response. LLM selection and planning suffer from incomplete context.
No output schemas documented. Callers do not know what fields get_mcp, list_mcps, or search_mcps return. Without documented return types, agents cannot plan downstream tool calls or extract the correct fields.
list_mcpsget_mcp
Recommendations
Expand all tool descriptions to 80 - 200 characters. For each tool, explicitly state: (1) What it does, (2) When to use it instead of similar tools, (3) What data it returns. Example: 'get_mcp: Returns full details of an MCP server (manifest, version, tags, checksums). Call this after list_mcps to inspect a specific server before adding it to your system. Returns: id, name, description, manifest_url, version, tags, checksum, signature_url.'
Add property-level descriptions to the 'server' object in add_mcp. Specify which fields are required, allowed formats, constraints. Example: 'id (string, required, 3-50 chars, alphanumeric + underscore): Unique identifier for the server. name (string, required): Human-readable name. manifest_url (string, required, valid HTTP URL): HTTPS endpoint where the MCP manifest.json is hosted.'
Document the output schema for all tools. For list_mcps, specify: 'Returns an object with servers (array of objects, each with id, name, description, version, tags) and total_count (integer). If results exceed 50, implement pagination with limit and offset parameters.'
Add enumerated values for status fields and constrained fields. If tags are meant to be drawn from a controlled list (e.g., 'llm-focused', 'data-integration', 'utility'), declare: 'tags (array of strings, each from: llm-focused | data-integration | utility | experimental | deprecated)'.
Implement error responses with recovery guidance. For remove_mcp: '404 Server Not Found → Try search_mcps() to find the correct server_id. 409 Conflict → Another process may be modifying the gallery; retry in 1 second.' For add_mcp: '400 Invalid URL → manifest_url must be a valid HTTPS endpoint with a responding manifest.json.'
Destructive operations (remove_mcp) lack confirmation/dry-run support. No guidance for agents on idempotency or retry behavior. LLMs may accidentally call remove_mcp twice, causing silent failures or confusion.
Parameter 'q' in search_mcps is under-specified. No indication of length limits, regex patterns, or expected format. Parameter 'tags' accepts a string but should clarify: is it comma-separated? Space-separated? A single tag? An array? Free-form string invites invalid input.
No error handling or recovery guidance. If remove_mcp fails or get_mcp returns 404, there is no hint for the agent: was the ID wrong? Should it search first? Is the operation retryable? Absence of error classification leaves agents stuck.
Tool names do not clearly signal state modification. While Risk labels (WRITE, DESTRUCTIVE) exist in metadata, descriptions do not explicitly state 'This tool modifies the gallery' or 'This operation cannot be undone'. LLM behavior depends on textual cues, not hidden metadata.
Pagination is not mentioned. If list_mcps or search_mcps can return large result sets, there is no limit parameter, offset/page parameter, or total count in the response. Risk of context window explosion or incomplete data.
add_mcp property 'tags' is declared as array but no per-item type or allowed values are shown. Should 'tags' contain only strings? Are there reserved tags? Unconstrained arrays invite hallucinated invalid values.
add_mcp
Add idempotency and retry guidance. State: 'This operation is [idempotent | non-idempotent]. If the call times out, it is safe to retry.' For add_mcp, consider: 'If server_id already exists, the call returns 409 and the existing record is returned (idempotent by server_id).'
Implement pagination for list_mcps and search_mcps. Add parameters: limit (integer, default 20, 1-100), offset (integer, default 0). Response includes total_count and a next_offset hint. Document the limit in tool descriptions.
For search_mcps, clarify the 'tags' parameter format. Specify: 'tags (string): Comma-separated tag values or a single tag. Example: "llm-focused,data-integration". If any tag matches, the server is included (OR logic).' Or switch to an array type for clarity.
Implement a dry-run or preview mode for remove_mcp. Add a parameter: 'confirm (boolean, default false). If false, returns a preview of what would be deleted (id, name, currently_dependent_tools). If true, executes the deletion. Prevents accidental destruction.'
Add a 'WHEN TO CALL' section to each description. Example for health_check: 'Use this before initiating MCP operations to confirm the gallery service is available. Returns response_time_ms and status. Typical use: agent startup or periodic monitoring.'
Document chaining. For search_mcps followed by get_mcp, ensure search_mcps returns the server_id. For add_mcp, return the newly created server object (id, name, version, manifest_url) so the agent can immediately reference it in subsequent calls.