Loading ToolBench
Model Context Protocol server for FireHydrant incident management platform, providing tools to list and create incidents, manage retrospectives, and list alerts
FireHydrant MCP has 5 tools with properly registered schemas and consistent naming patterns. All tools use verb_noun naming (alertsList*, incidentsCreate*, incidentsListIncidents, retrospectivesListIncidentRetrospectives, retrospectivesUpdateIncidentRetrospectiveField). Tool descriptions are present and state WHAT the tool does, though most are brief (15-50 chars). Parameter schemas are comprehensive with type definitions and descriptions present for all visible parameters. However, descriptions lack depth regarding WHEN to use each tool, dependencies between calls, and guidance for multi-step workflows. Output schema documentation is absent, no visible documentation of what fields are returned or their structure. Error handling is not visible in the tool code excerpts. Annotations are present (readOnlyHint, destructiveHint, etc.) which is positive. The tools follow composition principles (each has one responsibility), but lack documentation for chaining scenarios (e.g., after listIncidents, which tool retrieves retrospectives?). Baseline compliance: 100% of tools have names starting with action verbs, 100% have input schemas with type information, but output documentation is missing.
List alerts Retrieve all alerts, including Signals alerts and third-party
Create an incident Create a new incident
List incidents List all of the incidents in the organization
All attached retrospectives for an incident Retrieve retrospectives attached to an incident
Update the value on a retrospective field Update retrospective field value
Output schema documentation missing. No visible documentation of response fields, structure, or data types returned by any tool. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure.
Tool descriptions are minimal (15-50 characters). Most descriptions state WHAT but lack WHEN context, dependencies, or integration guidance. For example, 'List alerts' does not explain when to use this vs. filtering in incidentsListIncidents, or what alert types are supported.
No visible error handling or recovery guidance. Tool code excerpts show no error classification (retryable, user-fixable, fatal) or actionable error messages. If incidentsCreateIncident fails due to invalid severity, the LLM receives no guidance on valid values or next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Parameter descriptions lack constraint information. For example, 'page_number' and 'per_page' lack min/max bounds. 'severity' and 'priority' in incidentsCreateIncident have no enum or valid value list in descriptions. LLMs will hallucinate invalid values.
No chaining guidance or reference ID documentation. Tools like incidentsListIncidents and retrospectivesListIncidentRetrospectives operate on the same resources (incidents), but there is no documentation explaining which fields link them or how to chain calls. LLMs must guess whether 'incident_id' from one tool matches the parameter name in another.
No pagination guidance in responses. alertsListAlerts and incidentsListIncidents accept 'page' and 'per_page' parameters but no documentation clarifies whether results exceed the limit, how many items are returned, or if there is a total count in the response. Baseline pattern requires pagination metadata (total_count or next_cursor).
No confirmation or dry-run pattern for destructive operations. incidentsCreateIncident and retrospectivesUpdateIncidentRetrospectiveField are WRITE operations but lack any safety mechanism (e.g., dry_run flag or confirmation requirement). Agents can make irreversible mistakes without recourse.
Tool description for retrospectivesListIncidentRetrospectives uses vague phrasing ('All attached retrospectives for an incident' / 'Retrieve retrospectives'). Does this tool filter by status? Does it return rich content or IDs only? Descriptions must answer these questions explicitly.