Loading ToolBench
Model Context Protocol (MCP) server for Dynatrace providing tools to query vulnerabilities, problems, monitored entities, and interact with Dynatrace APIs and Davis CoPilot
Server has 15 tools with consistent naming (verb_noun pattern), good descriptions for most tools, and complete input schemas with types and descriptions. However, there are significant gaps in output schema documentation, missing parameter validation details, and no documented error handling or recovery guidance. Most tools are READ_ONLY (13 of 15), which is security-positive but limits composition complexity. Descriptions average ~150 chars (within baseline 194), but lack specificity about what data is returned and when to call each tool vs. similar alternatives. Parameter descriptions are present but often generic (e.g., 'Additional filter for DQL statement' without format/constraint guidance). Three AI-facing tools (generate_dql_from_natural_language, explain_dql_in_natural_language, chat_with_davis_copilot) lack clear output structure documentation.
Have a conversation with Davis CoPilot AI for assistance with Dynatrace queries and analysis.
Create a workflow in Dynatrace to send notifications to a team when problems of a specific type occur.
Execute a Dynatrace Query Language (DQL) statement. Returns records and metadata including scanned bytes and execution time.
Explain a Dynatrace Query Language (DQL) statement in plain English using Davis CoPilot AI.
Find a monitored entity by name. Searches all entity types and returns matching entities with their IDs and types.
Convert plain English descriptions into Dynatrace Query Language (DQL) statements using Davis CoPilot AI.
Output schemas completely undocumented. No tool documents what fields are returned, what types they are, or what the agent should expect. This forces LLMs to guess field names and types when chaining tools or extracting data.
Three AI-facing tools (generate_dql_from_natural_language, explain_dql_in_natural_language, chat_with_davis_copilot) lack clarity on output format. Returns raw AI text without structured field definitions, making downstream parsing ambiguous.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Get information about the connected Dynatrace Environment (Tenant) and verify the connection and authentication.
Get events for a specific Kubernetes cluster or all clusters if no cluster ID is provided.
Get details about a monitored entity by its entity ID. Returns entity name, type, tags and all properties.
Get ownership information for one or more monitored entities.
List all Davis problems from Dynatrace for the last 12 hours. An additional filter can be provided using DQL filter.
List all non-muted vulnerabilities from Dynatrace for the last 30 days. An additional filter can be provided using DQL filter.
Send a message to a Slack channel using a configured Dynatrace Slack integration.
Update an existing workflow in Dynatrace.
Verify a Dynatrace Query Language (DQL) statement for syntax correctness without executing it.
Parameter descriptions lack constraint clarity. E.g., 'Additional filter for DQL statement' does not specify syntax (DQL syntax? Free text?), allowed length, or example patterns. 'channel' for send_slack_message lacks guidance on format (channel ID? #name? @user?).
No error handling or recovery guidance documented. Tools do not explain what errors can occur, when to retry, or what the agent should do if a call fails. E.g., execute_dql can timeout, return no results, or fail with invalid syntax, none of this is documented.
Pagination parameters missing from list tools. list_vulnerabilities and list_problems accept maxVulnerabilitiesToDisplay / maxResultRecords but no offset, cursor, or next_token. Large result sets may exceed context window.
Destructive tools lack confirmation step. create_workflow_for_problem_notification, update_workflow, and send_slack_message modify external state but do not support dry-run or confirmation before execution. Agents can accidentally send messages or create unwanted workflows.
Overlapping tool purposes without clear differentiation. Both generate_dql_from_natural_language and chat_with_davis_copilot can convert text to DQL, and both explain_dql_in_natural_language and chat_with_davis_copilot can explain queries. LLMs may waste reasoning cycles deciding between them.
Resource references (entity IDs, workflow IDs, channel IDs) are opaque. Tools accept entity_id like 'PROCESS_GROUP-F84E4759809ADA84' but no guidance on how to obtain them without calling find_monitored_entity_by_name. Forces multi-step workflows when natural lookup might suffice.