The MCP server includes comprehensive logging to track all tool calls, SQL queries, and responses. This makes it easy to debug and monitor what the Azure OpenAI model is sending to your MCP tools and what data is being returned.
- File:
logs/mcp_server_YYYYMMDD_HHMMSS.log(timestamped for each server instance) - Terminal: Also outputs to stderr (visible in your terminal while running)
YYYY-MM-DD HH:MM:SS - module_name - LEVEL - message
Every tool invocation logs:
- Tool name being called
- Input parameters (including SQL queries)
- Database connection details
- Query execution results
- Output data (with sampling for large results)
- Any errors with full context
Logs:
- SQL query received from the LLM
- Database path being accessed
- Column names returned
- Number of rows in result set
- First 3 rows of data (for debugging)
- First 500 characters of formatted output
- Any SQL execution errors
Logs:
- Database connection status
- Record count from health check query
- Success/failure status
- Error details if health check fails
tail -f logs/mcp_server_*.logls -t logs/ | head -1 | xargs -I {} cat logs/{}grep "INPUT SQL Query" logs/mcp_server_*.loggrep "ERROR" logs/mcp_server_*.loggrep "TOOL CALLED" logs/mcp_server_*.log- INFO: Normal operations, tool calls, query execution
- ERROR: Failures, exceptions, database connection issues
Logs are stored with timestamps and are not automatically deleted. You may want to periodically clean up old log files:
# Remove logs older than 7 days
find logs/ -name "mcp_server_*.log" -mtime +7 -delete- All SQL queries executed
- Sample data from query results
- Database paths
- Error messages with technical details
Recommendations:
- Keep log files secure and restrict access
- Do not commit log files to version control (add
logs/to.gitignore) - Review logs before sharing for debugging
- In production environments, consider sanitizing sensitive data from logs
- The current code includes a note about avoiding raw error exposure to LLMs in production
-
SQL Syntax Errors
- Search for "SQL EXECUTION ERROR"
- Review the "Failed query was" line to see the exact SQL
-
Database Connection Issues
- Look for "Health check FAILED"
- Check database path in connection logs
-
Empty Results
- Check "Rows returned: 0" entries
- Review the SQL query to ensure it's correct
-
Tool Not Being Called
- If you don't see "TOOL CALLED" entries, the LLM may not be using your tools
- Review tool descriptions to ensure they're clear
2025-10-29 14:23:45 - __main__ - INFO - ================================================================================
2025-10-29 14:23:45 - __main__ - INFO - TOOL CALLED: run_SQLquery_duprez_archive
2025-10-29 14:23:45 - __main__ - INFO - INPUT SQL Query: SELECT title, broadcast_date FROM audio_files LIMIT 5
2025-10-29 14:23:45 - __main__ - INFO - Connecting to database: /home/angusf/_source/MCPLocal/DuPrezDB/archive.db
2025-10-29 14:23:45 - __main__ - INFO - Query executed successfully. Columns: ['title', 'broadcast_date']
2025-10-29 14:23:45 - __main__ - INFO - Rows returned: 5
2025-10-29 14:23:45 - __main__ - INFO - First 3 rows (if available): [('Programme A', '2020-01-15'), ('Programme B', '2020-02-20'), ('Programme C', '2020-03-10')]
2025-10-29 14:23:45 - __main__ - INFO - OUTPUT (length: 245 chars):
Query executed successfully. 5 rows returned.
+--------------+----------------+
| title | broadcast_date |
+--------------+----------------+
| Programme A | 2020-01-15 |
...