spike_get_escalationGet one escalation policy by id — {escalation, integrations:[...], isPinned, alertRules}. Spike: GET /escalations/{escalationId} (team-scoped).
| Name | Required | Description | Default |
|---|---|---|---|
| teamId | No | The 24-char hex team _id to scope this request to (x-team-id). Omit to use the configured default (SPIKE_TEAM_ID). List ids with spike_list_teams. | |
| escalationId | Yes | The escalation policy's _id (from spike_list_escalations). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only operation. The description adds value by specifying returned fields and team-scoped behavior, which is beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, informative sentence covering core purpose and endpoint. Could be slightly more structured but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple get tool with no output schema; lists return fields and parameter context is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds minimal extra value beyond the schema, justifying a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get one escalation policy by id' and lists specific fields returned, distinguishing it from list tools like spike_list_escalations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions team-scoped context and the endpoint, implying use for detailed retrieval, but lacks explicit when-to-use versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action (e.g., incidents, escalations, on-calls, services, teams) with no overlap. Incident tools are further subdivided by status and action, making misselection unlikely.
All tools follow a 'spike_verb_noun' pattern with snake_case. Verbs are consistently action-oriented (list, get, acknowledge, resolve, set), with only one longer name (spike_who_is_on_call_next) that still fits the pattern.
16 tools is well-scoped for an incident management server. It covers listing, fetching, and mutating incidents, plus supporting resources (escalations, on-calls, services, teams) without being overwhelming.
The tool surface covers the core incident lifecycle (trigger, acknowledge, resolve, priority) and provides read access to related resources. Minor gaps exist (no create/update/delete for non-incident resources), but the set is complete for typical incident response workflows.