samples: add functions and dynamic mcp servers

[cristipufu]

No description provided.

[cristipufu]

/help review

[cristipufu]

/ai generated [2849278409]

Code Review for PR #90

Overview

This PR introduces a new sample server (mcp-functions-server) that allows dynamic creation and execution of Python functions via MCP, and refactors the existing mcp-dynamic-server to simplify and modernize its dynamic tool registration logic. It also updates related metadata and lock files.

---

1. samples/mcp-dynamic-server/server.py

Major Changes

• Refactor: The file is heavily refactored to remove the custom ToolRegistry and instead leverage the internal mcp._tool_manager for dynamic tool management.
• Simplification: The add_tool logic is simplified, and the call_tool function is removed. Now, tools are added directly to the MCP server and can be called as first-class tools.
• Tool Listing: The get_tools function now aggregates tools from both built-in and dynamically added tools via the MCP tool manager.
• Error Handling: Error messages are improved and more concise.

Good Practices

• The refactor reduces code duplication and leverages the MCP server's built-in extensibility.
• Error handling is clear and user-friendly.
• The code is easier to maintain and extend.

Issues/Concerns

• Security: Executing arbitrary code via exec is inherently dangerous. There is no sandboxing or validation of the code, which could allow malicious code execution. This is a critical security risk, even in a sample.
• Input Schema: The input schema is accepted and returned, but there is no validation that the function signature matches the schema, which could lead to runtime errors.
• Removal of call_tool: The removal of the call_tool abstraction means that all tools must now be called directly. This is fine for most use cases, but if you want to keep a generic interface for calling tools by name, you may want to document this change.

---

2. samples/mcp-functions-server/ (New Sample)

Files Added

• server.py: Implements a dynamic function registry, allowing users to add, list, and call Python functions at runtime.
• pyproject.toml, uv.lock: Standard Python project and lock files.
• mcp.json, uipath.json: Configuration files for MCP and UiPath integration.

Good Practices

• The function registry is well-structured and separated from the MCP server logic.
• The API for adding, listing, and calling functions is clear and well-documented.
• Error handling is robust, with helpful messages and usage examples.
• The code is modular and easy to follow.

Issues/Concerns

• Security: As with the dynamic server, using exec to register arbitrary code is a major security risk. There is no sandboxing or restriction on what code can be executed.
• Input Schema Validation: The input schema is stored and returned, but there is no enforcement that the function signature matches the schema, which could lead to runtime errors or confusion.
• Type Safety: The use of Any and lack of type enforcement means that errors may only be caught at runtime.
• Async Consistency: The get_functions tool is async, but add_function and call_function are not. This is not a problem per se, but consistency may be desirable.

---

3. Metadata and Lock Files

• pyproject.toml and uv.lock files are updated/added as expected for new/updated samples.
• mcp.json and uipath.json are well-formed and provide the necessary configuration for MCP/UiPath integration.

---

Summary of Good Practices

• Code is modular, readable, and well-documented.
• Error handling is robust and user-friendly.
• The refactor in the dynamic server reduces code duplication and leverages framework features.

Summary of Issues

• Critical Security Risk: Both servers allow arbitrary code execution via exec with no sandboxing or validation. This is extremely dangerous and should be clearly documented as unsafe for production.
• Input Schema Enforcement: There is no check that the provided input schema matches the function signature, which could lead to runtime errors.
• Type Safety: Lack of type enforcement may lead to runtime issues.

---

Recommendations

1. Add Security Warnings: Clearly document that these samples are for demonstration only and should not be used in production due to the risk of arbitrary code execution.
2. Consider Sandboxing: If possible, use a restricted execution environment or validate code before execution.
3. Input Schema Validation: Add logic to check that the function signature matches the provided input schema.
4. Type Annotations: Consider enforcing or checking type annotations for better safety.
5. Testing: Ensure there are tests for adding, listing, and calling functions/tools, including error cases.

---

Overall, this PR is a strong improvement in terms of code clarity and extensibility, but the security implications of dynamic code execution must be clearly communicated and, if possible, mitigated.