rf-log-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RF_LOG_MCP_DB | No | Override the default SQLite database path for storing parsed results. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| parse_resultB | Parse a Robot Framework output.xml or RF 7.2+ output.json file and index it. |
| get_viewC | Get one supported view using a numeric run id or an already-parsed file path. |
| search_messagesC | Search indexed messages using a numeric run id or an already-parsed file path. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: get_view retrieves a specific view, parse_result processes and indexes files, and search_messages queries indexed messages. There is no overlap in functionality, and the descriptions clearly differentiate their roles, making misselection unlikely.
All tool names follow a consistent verb_noun pattern (get_view, parse_result, search_messages) with clear, descriptive verbs and nouns. The naming is uniform throughout, using snake_case consistently without any deviations or mixed conventions.
With only 3 tools, the set feels thin for a Robot Framework log management server, as it might lack operations like updating or deleting parsed data. However, the tools cover core parsing and querying functions, making it borderline appropriate but potentially limited in scope.
The tools provide basic parsing and search capabilities, but there are notable gaps: no update or delete operations for indexed data, and no tools for managing multiple runs or views beyond retrieval. This could lead to dead ends in workflows requiring data modification or broader management.