boosthis_list_rulesEvery Boosthis performance rule available to this runtime, as a list of ids and titles. It is the index for boosthis_get_rule, which answers with the detail for one of them.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating the returned content is limited to ids and titles and that this tool serves as an index rather than a source of full rule detail. This goes beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the core behavior is front-loaded. The first sentence states what the tool returns; the second situates it relative to a sibling. Every word earns its place.
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 parameterless, read-only, index-style tool with no output schema, the description is complete. It explains the result content (list of ids and titles), the scope (all rules available to this runtime), and points to the sibling for detailed rule lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden. The description adds no param-specific detail, but none is needed. Baseline 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every Boosthis performance rule available to the runtime, specifically as ids and titles. It also distinguishes itself from boosthis_get_rule by positioning itself as the index for that detail-fetching sibling tool.
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 clearly implies when to use this tool: to enumerate all rules or obtain ids/titles as an index. It also references boosthis_get_rule for retrieving detail on one rule, providing a clear relationship. However, it does not explicitly mention exclusions such as when to prefer boosthis_match_rules_for_code or other rule-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target a distinct concern—alerts, budgets, jobs, promises, rules, crash risk, install/removal—and the descriptions are detailed enough to separate them. A few pairs, like verify_kit/verify_kit_install and recent_samples/session_summary, could be misselected without close reading, but they are not functionally identical.
All tools share the boosthis_ prefix and use snake_case, which creates a recognizable namespace. However, the second part mixes noun-only names (alerts, budgets, jobs, snapshot, trend), verb-based names (get_rule, remember_promise, verify_kit), and one sentence-style name (what_should_i_look_at_next), so there is no consistent verb_noun convention.
At 24 tools, this sits squarely in the borderline-heavy range for an MCP server. Each tool does have a distinct role, but the surface feels large, especially with several overlapping read-only diagnostics that could potentially be consolidated.
The set covers the main observability lifecycle well: install, verify, monitor, diagnose, check trends, and record promises. Minor gaps exist—like no way to mutate alert states or delete promises through the MCP—but these appear intentional and are documented as dashboard-side actions.