boosthis_match_rules_for_codeRanks Boosthis rules against a code snippet using each rule's id tokens and when_to_apply text, up to 8 candidates. They are ranked guesses from a text match, not findings: each rule's when_to_apply settles whether it really applies.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context: results are heuristic ('ranked guesses from a text match, not findings'), there is an 8-candidate cap, and each rule's when_to_apply must settle real applicability. This goes beyond the annotations.
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 wasted words. The first sentence front-loads the action and method, the second clarifies interpretation. Every sentence 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 single-input read-only tool, the description covers what it does, what it returns (up to 8 ranked candidates), and how to interpret results. It does not describe the exact fields of each candidate, but with no output schema and a simple scope, this is a reasonable level of completeness.
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 schema only defines 'code' as a required string with no description (0% coverage). The description compensates by identifying it as the code snippet to match against, which is the sole parameter and is sufficiently disambiguated, even though no format or size details are given.
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 ('ranks') and resource ('Boosthis rules against a code snippet'), and clarifies the output is ranked guesses rather than definitive findings. This distinguishes it from sibling tools like list_rules or get_rule, which would not do text-based ranking against code.
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 implies usage when you need to match rules to a code snippet and then confirm applicability via when_to_apply, but it does not explicitly name alternatives or state when not to use this tool. The guidance about results being guesses is useful but not a full when-to-use vs. when-not-to-use.
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 resource or workflow: alerts, budgets, crashes, traces, jobs, promises, kits, and rules. A few summary-style tools such as snapshot, session_summary, and what_should_i_look_at_next overlap in spirit, but their descriptions clarify the different aggregation levels and purposes.
All tools share the consistent boosthis_ snake_case prefix, making the family immediately recognizable and predictable. However, naming mixes noun-resource styles with verb-command styles, and a few names are question-like phrases such as boosthis_what_should_i_look_at_next and boosthis_which_kits.
At 26 tools, this is on the heavy side and slightly past the 16-25 range where a large toolset starts to feel burdensome. The count is defensible because each tool maps to a distinct observability or kit-management concern, but agents will need to do significant selection work.
The surface covers a broad lifecycle: kit installation and verification, rules and code matching, performance snapshots and trends, crash risk, release checks, promises, alerts, and connection status. It is mostly read-only by design, so the lack of write operations beyond remember_promise is not a major gap, though alert and job management actions are intentionally absent.