Check infrastructure health, manage incidents, and run runbooks in Faultline.
Scored across 10 tools
Each tool maps to a distinct resource+action pair: list vs get vs acknowledge vs diagnose vs resolve for incidents, list vs get for services, and separate tools for anomalies and on-call. The descriptions explicitly delimit boundaries (e.g. diagnose_incident is analysis-only, run_runbook mutates infrastructure), so misselection is unlikely.
Nine of ten tools follow a clean verb_noun snake_case pattern (list_incidents, get_service, resolve_incident, run_runbook). The single outlier, who_is_on_call, is a question-form name rather than a verb_noun, but it is still readable and unambiguous.
Ten tools is squarely in the well-scoped range for an incident-response server, and each tool covers a distinct step in the detect-diagnose-act-resolve workflow. No redundant or filler tools are present.
The core incident lifecycle (list, get, acknowledge, diagnose, resolve, run runbook) plus service health, anomaly, and on-call lookups are covered. Minor gaps remain: no way to add a timeline note/comment outside of resolve, no manual incident creation, no escalation tool, and no pause/resume for services despite the PAUSED status being listed.
Acknowledge an open incident, stopping further escalation. Call this when the user says they are looking into an incident or asks you to take ownership of it.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a non-read-only, non-destructive mutation. The description adds useful behavioral context by saying acknowledgment stops further escalation, but it omits operational details such as idempotency, permission requirements, and whether acknowledging an already-acknowledged incident is an error.
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?
Two sentences are used efficiently: the action and effect come first, followed by the usage trigger. There is no redundant restatement of the tool name or annotations.
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?
For a simple one-parameter mutation with annotations covering safety, the definition provides enough to select and invoke the tool. It could be stronger if it clarified the expected incidentId and the result of acknowledgment, especially since no output schema exists.
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?
There is one required parameter, incidentId, and the schema description coverage is 0%. The description does not explain the parameter at all, so it fails to compensate for the schema's missing documentation of what identifier is expected or its format.
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 names a specific verb and resource ('Acknowledge an open incident') and adds the immediate effect ('stopping further escalation'). It does not explicitly distinguish this action from the sibling tool resolve_incident, so an agent must infer the boundary rather than being told.
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?
It gives concrete caller-facing triggers: when the user says they are looking into an incident or asks the agent to take ownership. It does not state when not to use it or point to alternatives such as resolve_incident or diagnose_incident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze an open incident and recommend the next action: run a specific runbook, escalate to a human, resolve, or wait. Returns the recommendation (with rationale and confidence) and the candidate runbooks. This is analysis ONLY — it does not change anything. Call this to decide what to do about an incident; then confirm with the user before calling run_runbook.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's 'does not change anything' is reinforcing rather than new — but it earns credit for disclosing the return payload shape (recommendation with rationale and confidence, plus candidate runbooks) and the human-in-the-loop gate before run_runbook. It stops short of noting whether only open incidents are eligible or what happens on a closed/already-resolved incident.
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?
Three tight, front-loaded sentences: purpose, return value, then the safety constraint and follow-up. Minor redundancy between 'analysis ONLY' and 'it does not change anything', which restates the same point twice.
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?
No output schema exists, yet the description covers the return contract (recommendation, rationale, confidence, candidate runbooks) and the required next-step workflow. For a single-parameter read-only analysis tool, nothing essential is missing.
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?
One parameter with 0% schema description coverage, so the description would need to carry semantics for incidentId. It only indirectly implies the constraint via 'open incident' — there is no statement of the ID format, where to obtain it (e.g. list_incidents), or what happens for a non-open incident.
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?
States a specific verb and resource ('Analyze an open incident') and enumerates the outcome space (runbook / escalate / resolve / wait), which cleanly separates it from mutating siblings like resolve_incident and run_runbook. The read-only framing ('analysis ONLY') further disambiguates it from the action tools.
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?
Explicitly says when to call it ('to decide what to do about an incident') and prescribes the follow-up sequence: confirm with the user, then call run_runbook. It also names the alternatives it competes with (escalate, resolve, wait) rather than leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an incident's full record: timeline of every update, escalations, runbook results, AI summary, and post-mortem if drafted. Call this before acting on an incident.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value by disclosing the shape of the payload the agent will receive. It omits error behaviour for a missing or invalid incident (fails vs. empty), which keeps it from a 5.
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?
Two sentences, zero filler. The payload contents come first and the usage rule is a punchy closing imperative.
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?
For a single-parameter read tool with no output schema, the description carries enough — it compensates for the missing return schema by enumerating what comes back. The remaining gap is the undocumented ID parameter and the absence of missing-incident behaviour.
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 description coverage is 0%, so the only parameter, incidentId, is documented nowhere except by its self-evident name. The description adds no format, sourcing, or lookup guidance (e.g., where to get an ID), which is exactly the gap a 0%-coverage schema leaves.
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?
Uses a specific verb ('Get') plus the resource ('an incident's full record') and then enumerates the components of that record: timeline, escalations, runbook results, AI summary, post-mortem. This clearly separates it from the mutation and diagnosis siblings, which the agent can rule out without opening their schemas.
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?
"Call this before acting on an incident" gives a concrete ordering rule that tells the agent when to reach for this tool rather than acknowledge/resolve/diagnose. It stops short of naming alternatives or stating exclusions (for example, use list_incidents to find an ID), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one service's details including its 10 most recent health checks (status codes, latency, errors). Call this when diagnosing WHY a service is degraded or down.
| Name | Required | Description | Default |
|---|---|---|---|
| serviceId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint and openWorldHint, so safety is handled. The description still adds real value by disclosing the embedded payload — a bounded window of the 10 most recent health checks with their fields — which tells the agent what evidence it will get without a second call.
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?
Two tight sentences with no waste: the return payload first, the usage trigger second. Every clause carries information an agent needs.
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?
With no output schema, the description does the work of describing return content, and it does so adequately. The only real hole is how to construct the serviceId, which nothing else in the definition covers.
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 description coverage is 0% and the description never explains what a serviceId is — whether it is a numeric ID, a slug, or a service name, or where to obtain it. With a required identifier as the sole parameter, the description leaves the agent guessing at the one thing it must supply.
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?
States a specific verb and resource ('Get one service's details') and enumerates what comes back (10 most recent health checks with status codes, latency, errors). The 'one service' phrasing implicitly separates it from list_services, though no sibling is named.
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?
Gives a clear triggering context: 'Call this when diagnosing WHY a service is degraded or down.' It does not state when NOT to use it or mention the adjacent diagnose_incident tool, so the routing is only partially pinned down.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent learned-baseline latency anomalies: observed vs baseline response time, the deviation z-score, how many consecutive hours it has been sustained, and the incident it auto-opened (if any). Call this when asked why a service is slow, about latency spikes, or for early degradation signals that have not yet tripped a hard up/down threshold.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, non-open-world operation. Beyond that, the description discloses the useful behavioral detail that these are learned-baseline anomalies and that some have auto-opened incidents, which helps an agent interpret the results.
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?
Two dense sentences front-load the purpose and then the usage conditions. Every phrase adds information about what is returned or when to call it, with no filler.
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?
With no input parameters and no output schema, the description carries the burden of explaining the result shape, and it does so by listing the key anomaly fields and the auto-opened incident relationship. It also explains when the tool is useful, making it complete for correct invocation.
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?
The tool takes no parameters, so there are no parameter semantics to explain. The baseline for zero-parameter tools applies, and the description does not introduce any confusing parameter-like expectations.
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 uses a specific verb and resource ('List recent learned-baseline latency anomalies') and names the exact information returned (observed vs baseline, z-score, sustained hours, auto-opened incident). This clearly distinguishes it from the incident- and service-focused sibling tools.
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?
It gives clear triggering contexts: when asked why a service is slow, about latency spikes, or for early degradation signals. It does not explicitly name alternatives or when not to use it, but the usage context is strong enough for an agent to select it confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List incidents — open ones by default, or recently resolved with status='resolved'. Call this when asked about outages, what's broken, or incident history.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: the default filter is open incidents, and 'resolved' is implicitly a recency-bounded view. It does not state result limits, ordering, or whether the resolved window is time-boxed.
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?
Two sentences, zero waste. The default behavior is stated before the alternative and the routing hint is appended last, which is the right order for an agent scanning for a match.
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?
For a one-optional-param read tool with annotations and no output schema, the description covers the essentials. The remaining gap is the vague 'recently resolved' boundary and no mention of ordering or result volume.
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 description coverage is 0%, so the description must carry the load, and it does: it explains the default (open) and what status='resolved' selects. The ambiguity is that 'recently resolved' implies a time window whose size is never specified.
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?
States a specific verb and resource ('List incidents') plus the scope of the default result set (open ones). It does not name a sibling such as get_incident or list_anomalies to draw the boundary, so it falls short of a 5.
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?
'Call this when asked about outages, what's broken, or incident history' gives concrete triggering contexts an agent can match against. It stops short of explicit exclusions (e.g. use get_incident for a single incident's detail).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all monitored services with their current status (OK, DEGRADED, DOWN, PAUSED, PENDING). Call this first to get an overview of infrastructure health, or to find a service's ID.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that results include current status, which is useful. However, the parenthetical status list reads as return values and never states that results can be narrowed by status, and there is no mention of pagination or result ordering.
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?
Two sentences, no waste, with the core action and result in the first sentence and the usage cue front-loaded in the second.
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?
There is no output schema, so the description must carry return-shape and filtering semantics; it covers what is returned but leaves filter behavior, pagination, and ordering unaddressed. For a one-parameter read-only tool this is adequate but has a real gap.
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 0% — the status property has only an enum and no description. The description lists the same enum values but frames them as statuses a service can have, not as a filter the caller can pass. An agent could conclude the list is always unfiltered, which is the key semantic gap for the only parameter.
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?
States a specific verb and resource ('List all monitored services') with explicit scope ('all') and what is returned ('current status'). The phrase 'find a service's ID' implicitly separates it from the single-service sibling get_service.
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?
Gives clear positive guidance: 'Call this first to get an overview of infrastructure health, or to find a service's ID.' That covers the two main entry scenarios. It does not name alternatives or state when not to use it (e.g., when you already have an ID, use get_service).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an incident as resolved, with an optional note describing the fix. Only call this when the user confirms the underlying issue is fixed — resolving is a status-page-visible action.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| incidentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), it discloses the key consequence that resolving is a status-page-visible action and demands user confirmation — real behavioral context an agent could not infer from the schema. It does not say whether resolving is reversible or how to un-resolve.
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?
Two short sentences, front-loaded with the action, then the guard condition and the reason for it. No filler.
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?
For a simple 2-parameter mutation with annotations covering the safety profile, this is close to sufficient. The remaining gap is what the call returns and whether the note is publicly visible, but with no output schema that is a minor omission.
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 0%, so the description bears the burden; it does explain the purpose of `note` (optional, describes the fix) but says nothing about `incidentId` format or the 1000-char limit on note. Partial compensation only.
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?
States a specific verb and resource ("Mark an incident as resolved") plus the optional accompanying field. It is distinguishable from siblings like acknowledge_incident and diagnose_incident by the terminal-status semantics, though it never names them explicitly.
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?
Gives an explicit precondition: only call when the user confirms the underlying issue is fixed. That is a strong when-to-call signal, but no alternatives (e.g., acknowledge_incident, diagnose_incident) are mentioned for cases where the fix isn't confirmed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one specific runbook against an incident. This MUTATES INFRASTRUCTURE (it can restart or scale services). Only call after diagnose_incident recommended it AND the user has confirmed. Pass the runbookId from the diagnosis's recommendation or candidate list.
| Name | Required | Description | Default |
|---|---|---|---|
| runbookId | Yes | ||
| incidentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety bar is lower, but the description still adds real value by concretizing the blast radius ("can restart or scale services") and imposing a confirmation gate. It stops short of stating reversibility, idempotency, or failure behavior for a destructive operation, so not a 5.
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?
Three short sentences, front-loaded with the action, then the danger, then the precondition and parameter sourcing. No sentence is filler.
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?
Covers action, risk, gating, and parameter provenance for a two-param destructive tool with no output schema. The remaining gap is what an execution returns (status, logs, failure modes), which the agent would otherwise have to discover empirically.
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 0% for both params, so the description must carry the load. It usefully explains the provenance of runbookId (from the diagnosis recommendation or candidate list) but says nothing about incidentId or the accepted ID format; incidentId is inferable from context only.
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?
Specific verb+resource: "Execute one specific runbook against an incident." The 'one specific' qualifier distinguishes it from bulk/listing siblings and frames the unit of action unambiguously.
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?
Explicit gating: only after diagnose_incident recommended it AND user confirmation, naming the sibling tool that produces the prerequisite. It also tells the agent where the runbookId comes from (the diagnosis's recommendation or candidate list), removing the main source of mis-invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the person currently on call for each on-call schedule, and when their shift ends. Call this when deciding who to contact about an incident.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds that results are per-schedule rather than a single flat answer, which tells the agent to expect multiple entries. It does not cover the empty case (nobody on call) or whether schedules with no rotation are omitted, which is the one remaining behavioral gap.
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?
Two short sentences: the first states what is returned, the second states when to call. No filler and nothing buried.
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?
With no parameters and no output schema, the description carries the return-shape burden and does it: person plus shift-end timestamp per schedule. Missing only the edge-case behavior (no one on call, multiple rotations), which keeps it from a 5.
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?
The tool takes zero parameters, so there is nothing to disambiguate and the baseline applies. The description correctly frames the call as taking no input scope.
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?
States a specific verb and resource ('Get the person currently on call for each on-call schedule') plus the returned datum ('when their shift ends'). This is clearly distinguishable from the incident-oriented siblings, none of which expose on-call ownership.
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?
Explicitly names the triggering situation: 'Call this when deciding who to contact about an incident.' That ties it to the incident workflow siblings nicely, but it doesn't state when not to use it or offer a contrasting alternative (e.g. escalation policies), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
acknowledge_incidentdiagnose_incidentget_incidentget_servicelist_anomalieslist_incidentslist_servicesresolve_incidentrun_runbookwho_is_on_callManage incidents and on-call: list/create/update incidents, who is on call, on-call overrides.
Monitor websites, APIs, and servers: create monitors, triage incidents, and query uptime stats.
Manage uptime monitors and incidents and search logs, metrics and traces from an AI assistant.
Manage the uptime monitoring, incidents and status pages of your Phare organization.
Add one secure layer between your agents and this server.
