Skip to main content
Glama

dismiss_suggested_board

Idempotent

Dismiss a suggested company board so it no longer appears in suggestions while its jobs remain tracked. Use add_board if you want to watch it instead.

Instructions

Stop suggesting a company in list_suggested_boards, when the person doesn't want to watch it. Its jobs stay tracked. To watch one instead, use add_board with its add_board arguments.

Input Schema

NameRequiredDescriptionDefault
companyYesThe company as list_suggested_boards names it (any case; Inc, LLC and the like aside), or its board.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as a non-read-only, non-destructive, idempotent write, so the safety profile is covered. The description adds a genuinely useful side-effect note ('Its jobs stay tracked'), clarifying that jobs are not removed when the suggestion is dismissed. It stops short of disclosing the response shape, though 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loading the core action and side effect before the routing hint. The trailing phrase 'with its add_board arguments' is slightly redundant and awkwardly worded, costing a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 plus the schema carry the param and safety detail. The description completes the picture with routing and side-effect context; only the exact effect on the suggestion list versus the board itself is left implicit.

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 100% with a single required parameter, and the schema already spells out case-insensitivity, name-vs-board acceptance, and suffix handling. The description's reference to 'a company in list_suggested_boards' echoes rather than extends that. Baseline 3 is appropriate.

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?

States a specific verb ('Stop suggesting') and resource ('a company in list_suggested_boards'), tying the action directly to the sibling list whose results it affects. An agent can distinguish it from add_board, remove_board, and the other board tools without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the triggering condition ('when the person doesn't want to watch it') and names the opposite-path alternative ('To watch one instead, use add_board'). The when-to-use and the when-to-use-something-else are both explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.