MCP Tools - Model Context Protocol#
The LIT Platform includes built-in Model Context Protocol (MCP) capabilities that enable dynamic tool creation and execution. This powerful system allows language models to both use existing tools and create new ones on-demand, providing unprecedented flexibility and extensibility.
What is MCP in LIT Platform?#
Model Context Protocol (MCP) is a standardized way for language models to interact with external tools and services. The LIT Platform implements both MCP client and server capabilities:
- MCP Client: Allows LLMs to discover and execute tools
- MCP Server: Provides tools to LLMs and manages tool lifecycle
- Dynamic Creation: LLMs can create new tools during conversations
- Team Isolation: Tools are scoped to specific teams for security
Key Differentiator: Authentic User Context Execution#
Unlike other MCP implementations that run tools under service accounts or with elevated privileges, LIT Platform tools execute with authentic user context. This security-first approach provides:
- True User Identity: Tools execute as the actual authenticated user, not as a system service or root
- Authentic Permissions: Tools have exactly the same access rights as the user would have
- No Privilege Escalation: No need for complex sudo configurations or permission elevation
- Natural Security Boundaries: Leverages existing user authentication and authorization
- Environment-Appropriate Execution:
- Docker deployments: Uses
gosu
to execute as the proper user within containers - On-premises installations: Uses SSH to execute directly on host systems as the user
- Seamless Integration: Tools work naturally with user's existing credentials, SSH keys, and access patterns
This means when an LLM creates a tool to access files, call APIs, or interact with services, it does so with the user's exact permissions and identity - providing both security and functionality without compromise.
Built-in MCP Capabilities#
Automatic Tool Discovery#
The platform automatically discovers and presents available tools to language models:
Available MCP Tools for team 'contoso':
- greeting_tool: A simple greeting tool that says hello
- data_processor: Process CSV files and generate reports
Real-time Tool Execution#
Tools can be executed directly from chat conversations:
User: "Can you process this CSV file and create a summary report?"
LLM: "I'll use the data_processor tool to handle that for you."
[Tool executes automatically]
LLM: "Here's your summary report: [results]"
Team-Specific Tool Isolation#
Each team has its own isolated set of tools stored in /data/{team}/mcp_tools/
. This ensures:
- Security: Teams can only access their own tools
- Organization: Tools are organized by team context
- Flexibility: Each team can have specialized toolsets
Dynamic Tool Creation Workflow#
One of the most powerful features is the ability for LLMs to create new tools during conversations:
1. User Requests Functionality#
2. LLM Recognizes Need for New Tool#
The LLM determines that no existing tool meets the requirements and decides to create one.
3. Tool Development Process#
The LLM creates a new MCP tool following the established patterns:
def invoke(length: int = 12, include_symbols: bool = True,
include_numbers: bool = True) -> str:
"""Generate a secure password with specified requirements.
Args:
length: Length of password (default: 12)
include_symbols: Include special characters
include_numbers: Include numeric characters
Returns:
Generated secure password
"""
# Tool implementation here
4. Immediate Availability#
The tool becomes available immediately without requiring server restarts.
5. Testing and Validation#
The LLM tests the new tool to ensure it works correctly:
LLM: "Let me test the new password generator tool..."
[Executes tool with test parameters]
LLM: "Tool created successfully! Here's your generated password: [result]"
Tool Development Guidelines#
File Structure#
Tools must be saved in the correct team-specific directory:
Tool Format Requirements#
Every MCP tool must follow this structure:
def invoke(**kwargs) -> str:
"""Tool description and purpose.
Detailed description of what the tool does and how to use it.
Args:
param1: Description of parameter 1
param2: Description of parameter 2
Returns:
Description of return value
"""
try:
# Tool implementation
result = process_request(**kwargs)
return str(result)
except Exception as e:
return f"Error: {str(e)}"
Key Requirements#
- Function Name: Must be named
invoke
- Documentation: Comprehensive docstring with Args and Returns
- Type Hints: Use proper type annotations
- Error Handling: Graceful error handling with descriptive messages
- Return Type: Always return a string
- Parameter Validation: Validate input parameters appropriately
Best Practices#
Naming Conventions#
- Use descriptive, snake_case filenames
- File name should reflect tool purpose
- Keep names concise but clear
Documentation Standards#
- Write clear, comprehensive docstrings
- Document all parameters with types and descriptions
- Explain return values and possible errors
- Include usage examples when helpful
Error Handling#
def invoke(input_data: str) -> str:
"""Process input data with proper error handling."""
try:
if not input_data:
return "Error: Input data cannot be empty"
# Process the data
result = complex_processing(input_data)
return f"Success: {result}"
except ValueError as e:
return f"Invalid input: {str(e)}"
except Exception as e:
return f"Processing error: {str(e)}"
Advanced Features#
Tool Chaining#
Tools can be designed to work together:
def invoke(previous_result: str, operation: str) -> str:
"""Chain operations on previous results.
Args:
previous_result: Output from previous tool
operation: Operation to perform on result
"""
# Process chained operation
External Service Integration#
Tools can integrate with external APIs and services:
def invoke(query: str, api_key: str) -> str:
"""Query external service API.
Args:
query: Search query
api_key: API authentication key
"""
# Make external API call
File System Operations#
Tools can read and write files within team boundaries:
def invoke(filename: str, content: str) -> str:
"""Save content to team file storage.
Args:
filename: Name of file to create
content: Content to write
"""
team_path = f"/data/{get_team_name()}/files/"
# File operations
Architecture Details#
MCP Server Integration#
The platform runs an integrated MCP server that:
- Discovers tools automatically from team directories
- Provides tool schemas to LLMs
- Executes tools in isolated environments
- Manages tool lifecycle and updates
Security Model#
- Authenticated User Execution: Tools execute as the authenticated user (via
gosu
in Docker, SSH in on-premises) rather than under service accounts or as root - Keycloak Enterprise Identity: Full integration with enterprise identity management, enabling SSO, federated authentication, and existing security policies
- Team Isolation: Tools are scoped to team boundaries with proper user context maintained through Keycloak
- Natural Permissions: File system and resource access follows the user's actual permissions from your identity provider
- No Privilege Escalation: Tools run within the user's existing security boundaries as defined by enterprise policies
- Superior Audit Trails: Every tool execution is logged with complete user identity context, providing enterprise-grade compliance and accountability
- Enterprise Integration: Seamlessly works with Active Directory, LDAP, and other federated identity systems through Keycloak
- Validation: Input validation and sanitization
- Environment-Appropriate Security: Security model adapts to deployment type while maintaining user identity
Performance Considerations#
- Lazy Loading: Tools are loaded on-demand
- Caching: Tool schemas are cached for performance
- Concurrent Execution: Multiple tools can run simultaneously
- Resource Management: Automatic cleanup and memory management
Troubleshooting#
Common Issues#
Tool Not Discovered#
- Verify file is in correct
/data/{team}/mcp_tools/
directory - Check that
invoke
function exists with proper signature - Ensure docstring follows required format
Tool Execution Errors#
- Review error messages for specific issues
- Validate input parameters and types
- Check for proper error handling in tool code
Permission Issues#
- Verify team membership and directory access
- Check file permissions in tool directory
- Ensure team isolation is properly configured
Debugging Tips#
- Test Tools Independently: Create simple test cases
- Use Logging: Add logging to understand tool behavior
- Validate Inputs: Always validate parameters before processing
- Handle Edge Cases: Consider unusual or invalid inputs
- Monitor Resources: Watch for memory or CPU issues
Examples and Tutorials#
Simple Utility Tool#
def invoke(text: str, operation: str = "uppercase") -> str:
"""Text transformation utility.
Args:
text: Input text to transform
operation: Type of transformation (uppercase, lowercase, reverse)
Returns:
Transformed text
"""
operations = {
"uppercase": text.upper(),
"lowercase": text.lower(),
"reverse": text[::-1]
}
if operation not in operations:
return f"Error: Unknown operation '{operation}'"
return operations[operation]
Data Processing Tool#
def invoke(csv_data: str, operation: str = "summarize") -> str:
"""Process CSV data and generate insights.
Args:
csv_data: CSV formatted data as string
operation: Type of analysis (summarize, statistics, validate)
Returns:
Analysis results
"""
import csv
import io
try:
# Parse CSV data
reader = csv.DictReader(io.StringIO(csv_data))
rows = list(reader)
if operation == "summarize":
return f"Dataset contains {len(rows)} rows with columns: {', '.join(reader.fieldnames)}"
# Additional operations...
except Exception as e:
return f"CSV processing error: {str(e)}"
This comprehensive MCP system enables unprecedented flexibility and extensibility in the LIT Platform, allowing teams to rapidly develop and deploy custom tools that integrate seamlessly with language model workflows.