Status keeps a team’s approved incident states and the exact customer-facing wording, then lets an assistant read that set before it posts an update. A 14-day trial, then Pro. The price is only at checkout.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 13 tools
The two evaluate_* tools are the closest pair, but the descriptions clearly separate audience-level permission (evaluate_audience) from exact-wording approval (evaluate_customer_update). The list_approved_causes / list_approved_statements / list_statement_limits trio and the corresponding save_* tools each target a distinct artifact type. get_status_context vs search_incident_states overlap somewhat (both surface incident states), but one is context retrieval and the other is paged search.
All 13 tools use a clean snake_case verb_noun pattern: create_status_board, list_status_boards, get_status_context, save_approved_cause, evaluate_customer_update, search_incident_states, etc. The verb prefixes (create/list/get/save/evaluate/search) map predictably onto action types. No camelCase or mixed-convention deviations.
13 tools sit comfortably in the well-scoped band and match the domain's distinct entity types (boards, causes, statements, limits, incident states) plus evaluation and read paths. There is mild redundancy—get_status_context already returns approved causes/timelines/workarounds that the three list_* tools expose separately—but nothing feels padded.
The core governance lifecycle is covered: create/list boards, save and read approved causes, statements, limits, and incident states, plus audience and wording evaluation. Gaps are revocation-oriented—there is no delete/update for boards and no way to retract or expire a previously approved cause/statement/limit, which matters for a governance surface. Agents can work around this by writing a superseding approval, so it is a minor rather than blocking gap.
Create a status board when the user asks for a new incident-wording home. Does not approve wording, a cause, a timeline, or a workaround.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description only needs to add context. It adds domain-scope semantics (no approval of wording/cause/timeline/workaround), which is useful, but says nothing about what creation returns, permissions, or side effects.
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 and followed by the scope boundary; no filler. Slightly under-specified rather than bloated, and 'incident-wording home' is an awkward phrase.
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?
An output schema exists, so return values need no explanation, and the tool is low-complexity with only two simple parameters. Still, the vague usage trigger and zero parameter guidance leave an agent with gaps for a create tool.
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 mentions 'name' or 'description' at all. The parameter names are largely self-explanatory, but the description contributes nothing to compensate for the total absence of schema-level documentation.
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 verb+resource ('Create a status board') is unambiguous and clearly distinct from the list_status_boards / get_status_context siblings. The qualifier 'when the user asks for a new incident-wording home' is cryptic jargon that muddies rather than sharpens the purpose.
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 supplies a trigger condition and a negative scope ('Does not approve wording, a cause, a timeline, or a workaround'), which implicitly steers away from the save_approved_* siblings. However, it never names those alternatives or states prerequisites, so the routing guidance remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide whether this channel may state a cause, a timeline, or a workaround, or may publish to an audience. REFUSED means do not publish and do not invent an audience. Permission to state wording still requires evaluate_customer_update for the exact text.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| boardId | Yes | ||
| channel | Yes | ||
| targetAudience | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered structurally. The description adds real behavioral context beyond that: what a REFUSED result obligates (no publish, no invented audience) and that a positive permission is still gated by a second call for exact wording. It stops short of describing the non-REFUSED outcomes.
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 sentences, all front-loaded with the decision first, then the refusal consequence, then the follow-up requirement. Every sentence carries information, though the phrasing is dense enough to require a second read.
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?
An output schema exists, so return-value details are not required, and the description covers the key decision semantics and the mandatory next step. The main gap is that three of four parameters receive no explanation, which matters at 0% schema coverage.
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 parameter meaning. It implicitly maps the four action enum values to intents (state cause, state timeline, state workaround, publish), which is genuine added value, but boardId, channel, and targetAudience are never explained.
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 states a specific verb (decide) and resource (whether a channel may state a cause/timeline/workaround or publish), so the agent knows this is a policy/gate evaluation rather than a content operation. It also names the sibling evaluate_customer_update, which differentiates it from the other evaluation tool. The only softness is that the evaluated 'resource' is an abstract permission rather than a concrete entity.
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 explicitly says when this applies (before stating a cause, timeline, workaround, or publishing) and routes the agent to the correct alternative for exact wording ('still requires evaluate_customer_update for the exact text'). It also gives an explicit when-not: 'REFUSED means do not publish and do not invent an audience.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide whether proposed customer-facing wording, a cause, a timeline, or a workaround is in the approved set. REFUSED means do not say it and do not invent a substitute ETA, cause, or workaround. APPROVED means sayOnly is the only permitted wording. Pass channel to also enforce the statement limit.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| boardId | Yes | ||
| channel | No | ||
| proposal | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds decision semantics absent from structured fields: REFUSED forbids substitutes and APPROVED makes sayOnly the sole permitted wording, which directly shapes what the agent should do with the result.
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 sentences with no filler, front-loaded with the core decision. The outcome semantics and channel note follow in logical order.
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?
An output schema exists, so return shape needn't be explained. The description supplies the meaning of REFUSED/APPROVED and the channel limit behavior, though it leaves boardId unexplained.
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 has to carry parameter meaning. It explains channel's statement-limit enforcement and implies that proposal can be wording, cause, timeline, or workaround, matching the kind enum, but boardId is never described.
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 'decide' plus the four proposal kinds and the 'approved set' object. An agent can distinguish this validator from list_* and save_* siblings that enumerate or persist approved items.
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?
No explicit when-to-use statement or named alternative. The channel sentence hints at conditional behavior but doesn't tell the agent when to choose this tool over listing approved statements or checking limits separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve selected incident states for a customer question, plus the board's approved causes, timelines, workarounds, and statement limits. This is evidence, not permission. A missing state is not an invitation to invent one. Call evaluate_customer_update before stating wording, a cause, a timeline, or a workaround.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| boardId | Yes | ||
| question | Yes |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavioral context the annotations cannot: the result is evidence and not permission, and a missing state must not be fabricated — a real guardrail for an LLM consumer.
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?
Four short sentences, front-loaded with what is returned, then the evidence-not-permission caveat, then the required next call. Every sentence earns its place 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?
An output schema exists so return-value explanation is unnecessary, and the description fully covers scope and the downstream sequencing constraint. The only gap is parameter meaning for boardId and limit, which neither schema nor description addresses.
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% across three parameters, so the description must carry the load. It only implies the 'question' parameter ('for a customer question') and says nothing about boardId or what 'limit' controls (default 8, max 20) — the selection cap on returned states is left unexplained.
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 ('Retrieve') and enumerates exactly what comes back: incident states for a customer question plus approved causes, timelines, workarounds, and statement limits. An agent can distinguish this composite evidence-fetch from siblings like search_incident_states or list_approved_causes.
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 downstream condition — call evaluate_customer_update before stating wording, a cause, a timeline, or a workaround — which names the alternative sibling and the trigger for using it. It stops short of explaining when to prefer this over list_approved_causes or search_incident_states directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read approved causes on a board. Only APPROVED causes can authorize wording, and only through evaluate_customer_update. Do not treat this list as permission to invent a cause.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | ||
| includeRetired | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds real context beyond them: the downstream governance rule that approved causes only authorize wording through evaluate_customer_update, plus an explicit anti-invention guardrail. It adds no details on result shape, but an output schema exists.
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 core read operation before the governance constraints. The closing anti-invention warning is a defensive guardrail rather than invocation-relevant content, but it is brief and does not bloat the definition.
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 an output schema present, return values need no explanation, and annotations cover the safety profile. The remaining gap is the undocumented includeRetired parameter; otherwise the definition is adequate for calling the tool correctly.
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 carries the full burden for two parameters. "On a board" loosely maps to the required boardId, but includeRetired is never mentioned, leaving an agent to guess whether retired causes are included by default.
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?
"Read approved causes on a board" gives a specific verb plus resource and scope, so the operation is unambiguous. It does not, however, differentiate itself from the near-identical sibling list_approved_statements, which an agent may confuse it with.
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 constrains how the results may be used (only APPROVED causes authorize wording, and only via evaluate_customer_update) and warns against inventing causes. It never says when to pick this tool over list_approved_statements or list_statement_limits, so tool-selection guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read approved timelines and workarounds. Listing them does not approve a different promise. Call evaluate_customer_update with the exact wording before saying one.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| boardId | Yes | ||
| includeRetired | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, non-destructive read, so the safety profile is covered. The description adds real workflow context beyond them: that reading this list has no approval effect and that a separate evaluation call gates any use of the wording. It does not discuss the retired-filter behavior, though that is largely schema-visible.
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 what it reads, then the critical misuse warning, then the required follow-up call. 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?
An output schema exists, so return values need not be described, and annotations cover safety. The workflow guardrail is present. The only gap is the unexplained parameters, particularly the required boardId and the includeRetired default.
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 parameter meaning. Naming 'timelines and workarounds' loosely maps to the kind enum (TIMELINE/WORKAROUND), but boardId and includeRetired get no explanation at all, leaving the semantic burden essentially unmet.
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: reads/lists approved timelines and workarounds. It is clear what the tool returns, but it does not name or contrast itself with the nearest siblings such as list_approved_causes or list_statement_limits, so an agent must still infer which list applies.
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 precondition and next action: call evaluate_customer_update with the exact wording before saying a promise. It also clarifies a common misuse (listing does not approve a different promise). It stops short of stating when not to use it versus the other list_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read statement limits. A channel with no APPROVED limit cannot state a cause, an ETA, or a workaround and cannot be given an invented audience.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | ||
| includeRetired | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds a meaningful business rule (a channel without an APPROVED limit cannot state cause/ETA/workaround or an invented audience), but it does not disclose pagination, scope, or return behavior beyond that.
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 with no filler; the core operation is front-loaded before the domain rule. Appropriately sized for a simple read tool, though the second sentence leans toward domain color rather than operational detail.
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?
An output schema exists, so return values need not be described. However, the description omits any parameter explanation and any when-to-use routing, leaving an agent with the operation but not the invocation details.
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 says nothing about boardId or includeRetired. With two parameters, one required UUID and one defaulted boolean, the description leaves both entirely uninterpreted, failing to compensate for the coverage gap.
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 states a specific verb and resource ('Read statement limits'), which is unambiguous. It does not, however, distinguish this tool from sibling list/read tools like list_approved_statements or list_approved_causes, so an agent must infer the boundary.
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 explains the domain consequences of a missing APPROVED limit but gives no guidance on when to call this tool versus alternatives such as list_approved_statements, nor any prerequisites or exclusions. Usage is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this team's status boards. Use the returned id. Do not guess a board.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only the mild guardrail that board ids must come from this call rather than being invented, and says nothing about result size, ordering, or whether the list is paginated.
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 with the core action front-loaded and no filler. The last two sentences overlap slightly ('use the returned id' vs 'do not guess a board'), a small redundancy in otherwise tight text.
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?
An output schema exists, so return-value detail is not required, and this is a simple single-parameter list tool. Still, the description never states whether the list is complete or paginated, which matters given the undocumented offset parameter.
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 single offset parameter has no documentation in either the schema or the description. Since coverage is low, the description was expected to compensate, but it never mentions pagination, page size, or how offset should be used.
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 gives a specific verb and resource ('List this team's status boards') and scopes it to the team, which separates it cleanly from create_status_board in the sibling list. It stops short of naming any sibling or explaining how it differs from other list_* tools such as list_approved_causes.
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?
'Use the returned id. Do not guess a board.' implies the tool must be called before any operation that needs a board id, which is useful implied guidance. However, no explicit when-to-use or when-not-to-use statement and no named alternative are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a cause the user has explicitly approved. matchTerms must name a specific incident. The word outage or cause alone is not a rule. wording is the only cause text that may later be approved. decision STATE grants that wording. decision WITHHOLD refuses a cause and records the only script that may be said.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| status | No | APPROVED | |
| boardId | Yes | ||
| wording | Yes | ||
| decision | Yes | ||
| matchTerms | Yes | ||
| expectedRevision | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety bar is lower. The description usefully explains the STATE/WITHHOLD decision semantics, but it never explains what the destructive write actually does (overwrite vs. append), that expectedRevision governs concurrency, or what WITHHOLD's recorded 'script' means operationally.
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?
Five short sentences, purpose front-loaded, no filler. Some phrasing is cryptic ('the only script that may be said') and could be tightened, but nothing is padded.
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 7-parameter, 5-required mutation tool with a destructive hint, a zero-description schema and no parameter docs, the description leaves major gaps: revision-based concurrency, the status enum, and the board scoping are all unaddressed. The output schema exists so return values need not be covered, but the input side is under-served.
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 all seven parameters, and it only meaningfully covers three (matchTerms, wording, decision). The added meaning for matchTerms and wording is genuinely beyond the schema, but boardId, name, status, and especially expectedRevision are left completely unexplained.
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+resource ('Store a cause the user has explicitly approved') and immediately qualifies what a valid cause is. It is distinguishable from list_approved_causes and save_approved_statement, though it never explicitly names a sibling to contrast against.
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 validation-flavored guidance ('matchTerms must name a specific incident', 'the word outage or cause alone is not a rule') that implies when a cause is admissible, but never states when to call this versus save_approved_statement or the list_* tools, nor any prerequisites like board setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a timeline or workaround the user has explicitly approved. The statement is the only wording that can later pass evaluate_customer_update. Do not save an ETA or a workaround the user did not approve.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| name | Yes | ||
| status | No | APPROVED | |
| boardId | Yes | ||
| statement | Yes | ||
| expectedRevision | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false; the description adds the approval precondition and the downstream consequence via evaluate_customer_update. However, it never explains the destructive/idempotent nature the annotations assert, nor what the optimistic-concurrency behavior implies, so it adds only partial value over the structured fields.
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 sentences, front-loaded with the action and scope, then the reason, then the exclusion. No filler or repetition.
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?
An output schema exists, so return values need no explanation, and the mutation precondition is covered. But for a destructive, non-idempotent-flagged write with 0% parameter documentation, the description omits parameter meaning and doesn't clarify the destructive/concurrency semantics an agent needs before calling.
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% across 6 parameters, so the description must compensate — and it only loosely maps 'timeline or workaround' to the kind enum. It says nothing about status (APPROVED/RETIRED), expectedRevision, name length limits, or boardId, leaving half the required parameters undocumented.
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 concrete verb (Store) and resource (timeline or workaround statement) and ties the purpose to the sibling evaluate_customer_update, which the statement must satisfy. It is distinguishable from siblings like save_approved_cause, though it never explicitly names those alternatives.
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 precondition (the user must have explicitly approved it) and explicit exclusions (do not save an ETA, do not save an unapproved workaround). It lacks a direct comparison to sibling save tools, but the when-not guidance is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store or revise an incident state the user has explicitly approved. wording is the only customer-facing text that may later be approved. Identical retries keep the same revision. A changed state requires expectedRevision from a previous read.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| status | No | APPROVED | |
| boardId | Yes | ||
| summary | Yes | ||
| wording | Yes | ||
| expectedRevision | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, and the description reinforces this by specifying the retry semantics ('Identical retries keep the same revision') and adding an optimistic-concurrency requirement (expectedRevision from a previous read). It also scopes which field is customer-facing, context the annotations do not provide, though conflict/failure behavior is not described.
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?
Four short sentences with no filler, and the approval precondition is front-loaded ahead of the mechanical constraints. Density is high, though the telegraphic phrasing of the middle sentences costs a little readability.
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?
An output schema exists, so return values need no explanation, and the approval gate plus revision semantics are covered. However, for a six-parameter write tool the description omits the meaning of status (APPROVED vs RETIRED), the significance of boardId, and any conflict or failure behavior, leaving meaningful gaps.
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% across 6 parameters, so the description carries the explanatory burden. It clarifies 'wording' (the only customer-facing text) and the role of 'expectedRevision', but leaves name, summary, status, and boardId entirely unexplained, covering only a third of the parameters.
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 pair and resource ('Store or revise an incident state') plus a key scope qualifier ('the user has explicitly approved'), which separates it from sibling save_approved_statement and save_approved_cause by object type. It stops short of naming those siblings, so differentiation relies on the resource noun alone.
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 a clear precondition for use ('a state the user has explicitly approved') and a condition for the mutation path ('A changed state requires expectedRevision from a previous read'), which tells the agent when a read must precede the call. No explicit alternative tools or when-not-to-use cases are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store the statement limit the user has explicitly approved for one channel. maxAudience must be on audienceLadder. Cause, timeline, and workaround flags default closed unless the user sets them true. A limit does not itself approve wording.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| notes | No | ||
| status | No | APPROVED | |
| boardId | Yes | ||
| channel | Yes | ||
| allowCause | No | ||
| maxAudience | Yes | ||
| allowTimeline | No | ||
| audienceLadder | Yes | ||
| allowWorkaround | No | ||
| expectedRevision | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation profile is covered. The description adds real context beyond that: the audienceLadder validation constraint, the default-closed flag behavior, and the caveat "a limit does not itself approve wording" — but it never addresses the destructive/overwrite or revision-check implications the annotations imply.
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 sentences with the core purpose front-loaded and no filler. Each sentence carries distinct information (scope, validation, defaults, caveat).
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 destructive, 11-parameter mutation with zero schema descriptions, the description supplies useful defaults and a validation rule, and an output schema exists so return values need not be explained. It still leaves most parameters and the overwrite/revision behavior unaddressed, so it is only partially adequate.
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% across 11 parameters, so the description carries the full explanatory burden. It clarifies only a handful — maxAudience's relationship to audienceLadder and the default values of the three allow* flags — leaving name, notes, status, boardId, channel, and expectedRevision entirely undocumented.
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 ("Store the statement limit ... for one channel") and distinguishes the object from siblings like save_approved_statement by calling it a limit rather than wording. It does not name any sibling explicitly, so differentiation relies on inference.
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 phrase "the user has explicitly approved" hints at a precondition, but there is no guidance on when to use this over save_approved_statement, save_approved_cause, or list_statement_limits. No when-to-use or when-not-to-use statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up approved incident states by name, summary, or customer-facing wording. An empty result means there is no approved wording. Do not invent an update, a cause, a timeline, or a workaround. Page with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| offset | No | ||
| boardId | Yes | ||
| includeRetired | No |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the description adds genuine extra context: empty-result semantics, a prohibition on fabricating content, and offset-based paging. It stops short of describing page size 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?
Four short sentences, front-loaded with the purpose, then result semantics, then a guardrail, then paging. Each sentence carries distinct information; only the 'do not invent' sentence is arguably policy rather than tool guidance.
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?
An output schema exists, so return-value detail is unnecessary, and the description still covers the key edge case (empty results) plus paging. The remaining gap is the undocumented required boardId and the includeRetired flag.
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% across four parameters, so the description must compensate. It clarifies that 'query' matches name, summary, or customer-facing wording and that 'offset' drives paging, but leaves 'includeRetired' and the required 'boardId' entirely unexplained.
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 ('Look up') plus a precisely scoped resource ('approved incident states') and the searchable fields (name, summary, customer-facing wording). This clearly separates it from siblings like list_approved_statements and list_approved_causes, though it never names an alternative directly.
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?
Usage is implied rather than stated: the 'empty result means there is no approved wording' note and the 'do not invent' guardrail signal that this is a pre-write lookup for approved text, but there is no explicit when-to-use/when-not or named alternative among the many approved-content siblings.
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.
create_status_boardevaluate_audienceevaluate_customer_updateget_status_contextlist_approved_causeslist_approved_statementslist_statement_limitslist_status_boardssave_approved_causesave_approved_statementsave_incident_statesave_statement_limitsearch_incident_states
Add one secure layer between your agents and this server.