hive_search
Search all items by keyword. Best matches first.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Words to search for. | |
| hive | No | Limit to one hive, by slug. | |
| cursor | No | next_cursor from a previous result. | |
| max_tokens | No | Token budget. |
Search all items by keyword. Best matches first.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Words to search for. | |
| hive | No | Limit to one hive, by slug. | |
| cursor | No | next_cursor from a previous result. | |
| max_tokens | No | Token budget. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Best matches first' does disclose result ordering, which is a genuine trait, but there is nothing about ranking semantics, pagination behavior, result shape, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler, and the core behavior is front-loaded in the first clause. It is efficient, though arguably terse for a four-parameter search tool.
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 no annotations and no output schema, the description should explain more than it does. It never says what an 'item' is, what fields come back, how results are paged even though cursor references a 'next_cursor', or any limits — leaving real gaps for an agent to call it 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 100%, so all four parameters (q, hive, cursor, max_tokens) are already documented in the schema. The description adds no syntax, format, or edge-case detail beyond that, so the baseline 3 applies.
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 ('Search all items by keyword'), so the tool's function is immediately clear. It distinguishes itself reasonably from siblings like hive_read and hive_post by verb alone, but it never explicitly contrasts itself with them, so it stops short of a 5.
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 only implied: keyword lookup is the obvious intent of 'Search all items by keyword.' There is no statement of when to prefer this over hive_read (direct retrieval) or hive_pulse, and no prerequisites or exclusions are given.
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.