Slack Max API MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.13
Disambiguation4/5
Most tools have distinct purposes within the Slack operations domain, but some overlap exists. For example, ops_access_policy_info and ops_policy_info both relate to policy information, which could cause confusion. However, descriptions clarify that the former focuses on access-control profiles while the latter covers operational guardrails, helping to differentiate them.
Naming Consistency5/5
Tool names follow a highly consistent pattern throughout, using the 'ops_' prefix followed by a descriptive verb_noun structure (e.g., ops_access_approve, ops_incident_create). This uniformity makes the set predictable and easy to navigate, with no deviations in naming conventions.
Tool Count3/5
With 21 tools, the count is borderline high for a focused operations server, potentially feeling heavy. While the tools cover various aspects like access control, incidents, broadcasts, and SLA management, some consolidation might improve usability without losing functionality.
Completeness5/5
The tool set provides comprehensive coverage for Slack operations, including CRUD-like lifecycle management for incidents (create, update, close), access control (request, approve, revoke), and monitoring (audit logs, failures, SLA breaches). No obvious gaps are present, ensuring agents can handle full workflows without dead ends.
Average 3/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It hints at scope ('recent', 'local') but fails to specify time ranges, return format, pagination behavior, or whether this requires specific admin privileges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded with no wasted words. However, given the complete lack of schema documentation and annotations, the description is undersized rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 undocumented parameters, no annotations, and no output schema, the description is insufficient. It omits critical details about filter parameters, return structure, and behavioral constraints necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), and the description completely fails to compensate. It does not explain what 'event' or 'method' filter for, valid formats, or how 'limit' interacts with the 'recent' scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resource ('local audit log entries'), distinguishing it from sibling tools like ops_incident_create or ops_access_approve. However, it lacks explicit contrast with similar diagnostic tools like ops_recent_failures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it mentions 'governance and troubleshooting' as use cases, it provides no explicit guidance on when to prefer this over ops_recent_failures or ops_state_overview, nor does it mention prerequisites like required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists returned data components but fails to indicate whether this is a safe read-only operation, if it generates audit logs, rate limits, or whether 'recent samples' implies sampling randomness or recency bias. Major safety and operational characteristics are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant phrases. Every word conveys meaningful content about the tool's output. However, given the complexity (6 undocumented parameters), extreme brevity becomes a liability rather than a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters (0% schema coverage), no output schema, and no annotations, the description is insufficient. It lists output categories but provides no parameter guidance, return format, pagination info, or error conditions. The gap between description content and required context is substantial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the 6 parameters. Critical relationships between parameters are unexplained: how 'limit' interacts with 'sample_size', what 'token_override' is for, or how 'participant_limit' differs from the participant count in the snapshot. The description completely fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an 'operational snapshot' and enumerates specific data components (activity volume, participants, threads, reactions, samples). However, it doesn't explicitly differentiate from sibling tools like 'ops_state_overview' or clarify that this is an analytics/inspection tool versus the action-oriented siblings (approve, revoke, broadcast).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus alternatives like 'ops_state_overview' or 'ops_recent_failures'. No mention of prerequisites (e.g., channel permissions) or when not to use it. The description only states what data is returned, not the decision criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'config-backed incident templates' and 'tracked' status, offering some context about template dependencies and persistence. However, it fails to disclose critical mutation behaviors such as side effects, idempotency, return value structure, or the security implications of the token_override parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately front-loaded with the verb 'Create' and avoids redundant phrasing. However, given the tool's complexity (10 parameters, no schema documentation), the extreme brevity becomes a liability rather than a virtue, leaving insufficient room for necessary parameter and behavioral guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters with no schema descriptions, no annotations, and no output schema, the description is insufficiently complete. It omits critical information about the severity enum values, the dry_run testing mode, authentication via token_override, and the structure of the created record, forcing the agent to guess at parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving all 10 parameters undocumented. The description fails to compensate for this gap, mentioning only the 'announce' capability implicitly and providing no details about severity levels, dry_run behavior, channel formatting, or the purpose of token_override. This leaves the agent without guidance on required parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Create... a tracked incident record') and mentions the optional announce capability. It distinguishes the tool from non-incident siblings (ops_access*, ops_broadcast*, etc.) by specifying the 'incident' resource. However, it does not explicitly differentiate from closely related siblings ops_incident_update and ops_incident_close regarding the incident lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like ops_incident_update for existing incidents. While the word 'optionally' hints at the announce parameter's flexibility, there is no guidance on when announcement is appropriate or what the dry_run parameter is for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. While it mentions 'local diagnostics state,' it fails to specify retention periods, whether the operation is read-only, output format, or if querying affects the state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality without redundancy. However, it is underspecified given the lack of supporting schema documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a diagnostic tool with three undocumented parameters and no output schema or annotations, the description lacks essential context such as parameter semantics, failure retention policies, and return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for all three parameters (limit, kind, method). The description adds no semantic information to compensate, leaving critical parameters like `kind` and `method` completely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('List') and clear resource ('tool, Slack API, or access-control failures'), including scope ('from local diagnostics state'). However, it does not differentiate from sibling tools like `ops_audit_log_read` or `ops_explain_error`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as `ops_audit_log_read` or `ops_explain_error`, nor does it mention prerequisites like required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions switching runtime state but fails to disclose persistence (session vs permanent), validation behavior (what happens if profile doesn't exist), or side effects on existing operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action and target. No redundant or filler text. However, extreme brevity is inappropriate given the complete lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing operation with 0% schema coverage, no annotations, and no output schema, the description is insufficient. Missing: valid profile values, purpose of 'reason' field, error conditions, and confirmation of success/failure behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. While 'profile' is implicitly contextualized as the access-control profile to activate, valid values/format are not specified. The 'reason' parameter is completely undocumented despite being available for audit/compliance purposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Switch' and identifies the resource as 'active Slack access-control profile', clearly distinguishing it from sibling tools like ops_access_request (requesting) or ops_access_policy_info (querying). It clarifies scope by mentioning 'MCP runtime state'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like ops_access_request or ops_access_approve. No mention of prerequisites (e.g., whether to verify available profiles first using ops_access_policy_info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it hints at persistence ('persist the new operational status') and optional threading ('post a thread update'), it fails to disclose critical mutation safety details: dry_run behavior, side effects of severity changes, notification triggers, or whether updates are reversible. For a 10-parameter write operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. However, given the high parameter count and zero schema documentation, it may be overly terse rather than appropriately concise—leaving too much weight on the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 10 parameters, 0% schema coverage, and no output schema or annotations, the description is incomplete. It fails to explain enum semantics (severity levels, status workflow), the purpose of dry_run, or what successful execution returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate significantly. It only implicitly references 3 of 10 parameters (incident_id via 'tracked incident', post_update via 'post a thread update', status via 'operational status'). It completely omits semantics for critical fields like dry_run, token_override, next_update_minutes, and the distinction between summary vs details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Update a tracked incident') with specific verbs and resource. However, it does not explicitly differentiate from sibling tools like ops_incident_create or ops_incident_close, leaving the agent to infer the lifecycle distinction from the word 'Update' alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus ops_incident_close or ops_incident_create. There is no mention of prerequisites (e.g., that the incident must exist) or workflow conditions (e.g., whether closed incidents can be updated).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but omits critical safety information (read-only vs. destructive), the algorithmic definition of 'unanswered' (zero replies vs. no accepted answer), and the structure of returned data. While it mentions 'stale' implying temporal filtering, it fails to disclose rate limits or authentication requirements beyond the cryptic token_override parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that prioritizes the core action and subject matter, minimizing word count. However, 'for follow-up operations' adds vague operational context that doesn't clarify functionality, slightly diminishing the value of the conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering six undocumented parameters, zero annotations, and no output schema, the description is insufficient for agent confidence. It fails to explain filtering logic, pagination behavior (max_threads), return data structures, or the impact of boolean flags, leaving critical gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage across six parameters, the description inadequately compensates by only implicitly referencing 'channel' and temporal concepts (stale) without explaining the distinction between lookback_hours and min_age_minutes, the purpose of include_bot_replies in determining 'unanswered' status, or the function of token_override.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb (Find) and resource (unanswered or stale question-like threads) that clearly differentiates this tool from its operational siblings (access control, incidents, broadcasting). However, the phrase 'for follow-up operations' introduces slight ambiguity regarding the intended use case without explicitly contrasting with alternatives like ops_channel_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but offers no guidance on when to use it versus alternatives such as ops_channel_snapshot or ops_recent_failures. It lacks prerequisites (e.g., channel permissions), exclusion criteria, or workflow context necessary for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only discloses the filtering logic (SLA threshold + no external replies). It fails to clarify if this is read-only, whether it modifies thread state, rate limits, or what the return format contains (especially critical given no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient single sentence of 12 words with zero redundancy. Information is front-loaded with the action verb, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a 6-parameter operational tool with complex logic (SLA calculation, threading, external vs internal reply detection). Lacks explanation of pagination behavior (max_threads), authentication override purpose, or output structure. Should specify what constitutes an 'external' reply and how SLA breaches are calculated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to compensate. It conceptually maps to 'channels' and 'sla_minutes' via 'multiple channels' and 'SLA threshold', but completely ignores 'lookback_hours', 'max_threads_per_channel', 'include_bot_replies', and 'token_override', leaving 4 of 6 parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (scan), target resource (channels/threads), and specific filtering criteria (exceed SLA threshold, without external replies). However, it loses a point for ambiguous terminology ('external replies' lacks context) and fails to explicitly differentiate from the sibling tool 'ops_sla_followup'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus siblings like 'ops_unanswered_threads' or 'ops_sla_followup', nor any mention of prerequisites (e.g., required channel name format) or when-not-to-use conditions. The agent must infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden, yet it fails to explain side effects, idempotency, failure modes, or the meaning of 'dry_run'. It doesn't clarify what happens when both text and broadcast_id are provided, or how the 13 parameters interact. 'Operational message' is jargon without context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence structure is front-loaded with the action verb and contains no redundant or filler text. However, given the high complexity (13 parameters, no annotations), the extreme brevity becomes underspecification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 optional parameters, no output schema, and no annotations, the description is inadequate. It fails to explain parameter precedence rules (e.g., broadcast_id vs. text), return values, error handling, or the relationship between the composition fields (title/summary/details/blocks).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 13 parameters, the description provides insufficient compensation. While it implicitly references 'channels' and draft-related parameters (broadcast_id/template_id), it offers no guidance on complex parameters like 'blocks', 'mrkdwn', 'unfurl_links', 'token_override', or the relationships between text/title/summary/details/blocks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action (broadcast operational message) and scope (multiple channels). It also distinguishes two operational modes (direct broadcast vs. sending prepared drafts), implicitly differentiating from sibling 'ops_broadcast_prepare'. However, it doesn't explicitly name the sibling relationship or clarify when to use each mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies two usage patterns (broadcasting directly to channels vs. sending a prepared draft), but provides no explicit guidance on when to choose one over the other, prerequisites for using drafts, or workflow integration with 'ops_broadcast_prepare'. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It mentions 'config-backed defaults' (explains parameter optionality) and 'state persistence' (hints at side effects). However, it fails to clarify the tool's safety profile (destructive vs safe), authentication requirements, or what 'running' actually entails (sending messages? creating tickets?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense sentence with no filler. Front-loaded with the core action. Information-to-word ratio is high. However, extreme brevity may hinder comprehension given the tool's complexity (15 parameters), though this is primarily a completeness issue rather than conciseness failure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a complex 15-parameter operational tool with no output schema and zero annotations. Missing: parameter-to-playbook mappings, return value description, error handling behavior, and safety warnings expected for incident management workflows. The 'config-backed defaults' hint is insufficient operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate significantly. It fails to do so, providing no explanation for 15 parameters including critical distinctions like 'channel' vs 'channels', the purpose of 'dry_run', or which parameters apply to which playbooks. The parenthetical playbook names merely repeat the schema enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Run) and resource (operations playbook) with specific parenthetical examples (incident open, support digest, release broadcast). It distinguishes from ops_playbook_list by emphasizing execution over listing. However, it doesn't explicitly differentiate from direct action siblings like ops_incident_create or ops_broadcast_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like ops_incident_create or ops_broadcast_message. The examples imply use cases but don't clarify selection criteria or prerequisites (e.g., which playbook to choose, required vs optional parameters with config defaults).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Inspect' implies read-only access but does not confirm idempotency, safety guarantees, rate limits, or whether this queries a cache versus live systems. No information on return format or pagination behavior is provided despite the presence of a 'limit' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is front-loaded with the primary verb and efficiently lists the covered entity types. No wasted words, though given the lack of schema descriptions and annotations, additional sentences explaining parameters or behavior would have been valuable rather than verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters (including one with six enum values), zero schema descriptions, no annotations, and no output schema, the description is insufficient. It fails to document the 'summary' collection, explain valid 'status' values, or describe the return structure, leaving the agent to guess at critical usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by listing the entity types corresponding to the 'collection' enum values (though it misses 'summary'). However, it provides no semantics for the 'status' parameter (valid values, format) or 'limit' parameter (default behavior, pagination semantics), leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'Inspect' and enumerates the resource types (incidents, digests, broadcasts, followups, playbook runs), which distinguishes it from action-oriented siblings like ops_incident_create or ops_broadcast_message. However, it omits the 'summary' collection type and 'local operations state' is slightly vague without specifying if this is cached or real-time data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool versus alternatives. While the verb 'Inspect' implies this is for reading state versus the creating/updating siblings, there is no mention of prerequisites, when to prefer this over specific getters, or filtering capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions optional side effects ('post a closure update') and persistence ('persist the final resolution'), but fails to address idempotency, error handling when closing already-closed incidents, or the purpose of the dry_run and token_override parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, efficiently structured sentence that front-loads the primary action ('Close a tracked incident') before listing optional modifiers. There is no redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters with 0% schema coverage, no annotations, no output schema, and performs a destructive/terminal mutation, the description is insufficiently complete. It lacks critical context about return values, error states, and the specific behavior of safety parameters like dry_run.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate significantly. While it implicitly references 'resolution' and 'post_update' through phrases like 'final resolution' and 'post a closure update', it leaves five parameters (details, owner, dry_run, token_override, incident_id) completely undocumented, including critical behavioral flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Close') with a clear resource ('tracked incident'), distinguishing it from sibling tools like ops_incident_create and ops_incident_update. However, it stops short of explicit lifecycle context (e.g., 'terminal state change') that would fully clarify its role in the incident workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus ops_incident_update, nor does it mention prerequisites (e.g., whether the incident must be in a specific state before closing). There are no 'when-not' exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully indicates the dry-run capability, which is crucial for a write operation. However, it omits details about return values, error handling, rate limits, or whether the operation is idempotent, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of 12 words that front-loads the action verb and packs in the core functionality and a key feature (dry-run). There is no wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is insufficiently minimal. It fails to compensate for the lack of schema documentation by explaining key filtering logic or expected outputs, leaving the agent under-equipped to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its 9 parameters. While the description implicitly references 'channels' and explicitly mentions 'dry-run,' it fails to document critical parameters like sla_minutes, lookback_hours, or max_threads_per_channel, leaving the majority of the interface unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Post reminder replies'), target ('SLA-breached threads'), and scope ('across channels'). It effectively distinguishes itself from sibling tools like ops_sla_breach_scan (identification vs. action) and ops_broadcast_message (broadcast vs. thread reply). However, it could clarify what constitutes an SLA breach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'supports dry-run,' weakly implying a testing workflow, but provides no explicit guidance on when to use this tool versus alternatives like ops_sla_breach_scan or ops_unanswered_threads. There are no stated prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses that the broadcast is 'tracked' and in 'draft' status, implying persistence and auditability. However, it fails to explain what 'tracked' entails, draft lifecycle (expiration, visibility), or side effects, leaving significant behavioral gaps for a state-creating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficiently structured with the action front-loaded ('Create a tracked broadcast draft'). Every word earns its place, though the extreme brevity is insufficient to compensate for the complete lack of schema descriptions across 8 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It fails to explain the return value (likely a draft ID needed for the subsequent send operation) or clarify the complex parameter relationships, which is critical for a multi-step workflow tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only implicitly references the 'channels' parameter ('one or more channels'). It provides no clarification for the 4 distinct content fields (text, title, summary, details), nor mrkdwn, template_id, or token_override, leaving 7 of 8 parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('tracked broadcast draft') and implies the preparatory nature ('before sending'), which distinguishes it from the sibling tool ops_broadcast_message. However, it could more explicitly contrast with the immediate-send alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before sending it to one or more channels' implies this is a staging step in a workflow, suggesting it should be used when review or preparation is needed prior to transmission. However, it lacks explicit guidance on when to use this versus ops_broadcast_message, and doesn't state prerequisites or next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Show' implies read-only access, the description does not explicitly confirm lack of side effects, required authorization levels, rate limits, or the structure of the returned policy data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with the verb first. The parenthetical clarification '(method policy and local audit settings)' efficiently defines 'operational guardrails' without adding unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter information retrieval tool, the description adequately identifies what information is returned. However, given the absence of an output schema or annotations, it could improve by briefly indicating the return format (e.g., 'returns JSON configuration').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero input parameters and 100% schema coverage trivially. The baseline score of 4 applies as there are no parameters requiring semantic clarification beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Show' and specifies the resource as 'operational guardrails' for 'this MCP', clarifying it retrieves the server's own method policy and audit configuration. It distinguishes from sibling ops_access_policy_info by emphasizing 'this MCP' (internal server policies) rather than external access controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus similar siblings like ops_access_policy_info or ops_audit_log_read. No prerequisites, triggers, or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While 'Show' implies a read-only operation, the description does not explicitly confirm it is non-destructive, disclose required permissions, or explain the output format/structure given the absence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of nine words. Every word earns its place by identifying either the operation type or specific data categories returned. No redundancy or filler content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter information retrieval tool, the description adequately identifies the data domains covered. However, given the lack of output schema and the complex operational context (many sibling access management tools), it omits expected details about output structure, pagination, or filtering limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. Per the evaluation rules, 0 parameters establishes a baseline score of 4. There are no parameters requiring semantic elaboration beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Show' and enumerates four distinct resources (access-control profiles, effective rules, pending elevation requests, active grants). It implicitly distinguishes from action-oriented siblings (approve, set, revoke) through the read-only verb choice, though it lacks explicit contrast with ops_policy_info or ops_access_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not indicate that ops_access_policy_set should be used for modifications, or that ops_access_request is for creating new requests rather than viewing pending ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context about the data source ('latest diagnostics snapshot'), implying read-only access to cached diagnostic data. However, it lacks essential safety information (idempotency, performance cost, error handling for invalid failure_ids) that annotations would typically cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of 11 words that front-loads the action ('Explain') and wastes no space. Every word earns its place by conveying the transformation (failure record → human-readable explanation) and data source (diagnostics snapshot).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read operation) and lack of output schema, the description adequately covers the core function. However, given zero schema coverage and no annotations, it should explicitly mention the relationship to 'ops_recent_failures' for obtaining failure IDs to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (failure_id lacks description), so the description must compensate. It implicitly maps the parameter through the phrase 'recorded failure,' giving semantic meaning to what failure_id represents. However, it does not describe the parameter's format, valid values, or that it should be obtained from sibling list operations, leaving documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Explain') and resource ('recorded failure'), clearly indicating it provides human-readable diagnostics for a specific error record. However, it does not explicitly differentiate from sibling tool 'ops_recent_failures' (which likely lists failures), leaving minor ambiguity about the workflow relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'ops_recent_failures' or 'ops_incident_create'. It omits crucial context that this tool requires a specific failure_id likely obtained from listing failures first, and does not indicate if it should be used during active incidents or post-mortem analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure; it implies a read-only operation through 'List' and clarifies the scope to 'built-in' playbooks, but fails to describe the return format, pagination behavior, or what metadata is included for each playbook. The mention of 'multi-step Slack workflows' adds domain context but does not address operational characteristics like caching or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, efficient sentence that front-loads the action ('List') and immediately specifies the resource, with no redundant or extraneous information. Every word serves to clarify the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While appropriate for a simple listing tool, the description lacks information about the return structure since no output schema is provided, leaving the agent uncertain about what playbook metadata is returned. Given the tool's low complexity and zero parameters, the description meets minimum viable standards but omits helpful context about the relationship to ops_playbook_run.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, establishing a baseline score of 4; the description does not need to compensate for missing schema documentation. The phrase 'built-in operations playbooks' implicitly confirms no filtering parameters are required, aligning with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'built-in operations playbooks' and qualifies them as those 'that can run multi-step Slack workflows,' which distinguishes this discovery tool from the execution sibling ops_playbook_run and other ops tools. While clear, it could explicitly reference the sibling tool to strengthen differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit guidance on when to invoke it versus alternatives like ops_playbook_run, nor does it specify prerequisites or typical workflows. The phrase 'can run multi-step Slack workflows' implies these are templates for execution but does not explicitly instruct the agent to use this for discovery before running.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Successfully discloses the pending-approval state ('must be approved before it becomes active'), but omits temporal aspects (temporary access implied by duration_minutes parameter), expiration behavior, and approval routing logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 12 words with zero redundancy. Critical information (create, scoped, Slack access, approval requirement) is front-loaded and dense. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic workflow understanding given the complexity (6 parameters, approval flow), but gaps remain: no output schema explanation, no clarification that access is temporary (despite duration_minutes parameter), and no detail on scoping dimensions despite 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage across 6 parameters. Description mentions 'scoped' which vaguely alludes to channels/methods/tools parameters, but provides no semantics for actions (despite enum complexity), duration_minutes limits, or reason requirements. Insufficient compensation for schema deficiencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity with 'Create a scoped Slack access elevation request' — clearly identifies the verb, resource, and scope. The phrase 'must be approved before it becomes active' effectively distinguishes this from sibling ops_access_approve (which performs approvals) and ops_access_revoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies this is the first step in an approval workflow, but lacks explicit guidance on when to use this versus requesting permanent access or emergency break-glass procedures. No mention of who can approve or prerequisites for creating requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds valuable context about persisting 'in local state' but lacks critical safety disclosures for a mutation tool: whether revocation is reversible, immediate side effects, permission requirements, or what the operation returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 13 words with zero redundancy. The information is front-loaded with the action verb and efficiently conveys the dual-mode operation (single vs bulk) and persistence behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation operation with no output schema or annotations, the description is minimally adequate. It covers the core revocation logic but misses the 'reason' parameter entirely and lacks safety warnings or return value documentation appropriate for destructive operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to compensate. It implicitly clarifies the semantics of grant_id vs revoke_all_active through the 'one... or all' phrasing, but completely omits the 'reason' parameter, leaving one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Revoke') with clear resource ('access grant'/'grants') and scope ('one' vs 'all'), clearly distinguishing it from sibling tools like ops_access_approve and ops_access_request through the revocation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the mutual exclusivity pattern between grant_id (one) and revoke_all_active (all), but provides no explicit guidance on when to use this tool versus alternatives like ops_access_approve, or prerequisites for revocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden and successfully discloses state transition (pending→active) and temporal constraint (time-boxed). However, missing safety-critical details: no mention of reversibility, required permissions, audit logging, or failure modes specific to access control.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 12-word sentence with zero redundancy. Front-loaded action ('Approve') followed by precise object and outcome. Every term ('pending', 'elevation', 'time-boxed') conveys specific operational semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic invocation but insufficient for security-critical access management: no output schema, undocumented parameter (reason), and missing operational constraints (maximum durations, approval authority requirements, notification behaviors).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description implicitly maps 'pending access elevation request' to request_id and 'time-boxed' to duration_minutes, but provides no explicit parameter documentation and completely omits the reason parameter, leaving one-third of inputs undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Approve' with resource 'access elevation request', and distinguishes from siblings by specifying it converts 'pending' requests into 'active time-boxed grants'—clearly differentiating from ops_access_request (creation) and ops_access_revoke (removal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context through 'pending' (prerequisite state) and 'time-boxed' (temporary nature), but lacks explicit when-to-use guidance, exclusion criteria, or mention of alternative actions like denying requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Slack-mcp MCP server](https://glama.ai/mcp/servers/JeongWoobin335/Slack-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JeongWoobin335/Slack-mcp)

Score Badge

Copy to your README.md:

[![Slack-mcp MCP server](https://glama.ai/mcp/servers/JeongWoobin335/Slack-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JeongWoobin335/Slack-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JeongWoobin335/Slack-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server