Read the full search results returned for a single instant-search request. Returns chunk_id, vertex_id, title, full text, and relevance score. Use this to inspect the exact results a user saw for their search query. Ordered by score descending.
| Name | Required | Description | Default |
|---|---|---|---|
| search_request_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds useful behavioral context beyond that by specifying the returned fields, descending score ordering, and the fact that it returns exact results for a single request. The phrase 'full text' also signals potentially large payloads, which is valuable behavioral information.
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?
Three short sentences convey the purpose, return content, use case, and ordering with no wasted words. The most important information is front-loaded and 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?
Given the single parameter, read-only annotation, and presence of an output schema, the description is nearly complete. It could mention expected error cases or clarify that the output schema contains the listed fields, but nothing critical is missing for selecting and calling the tool.
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 has zero description coverage for the only parameter, and the description does not directly define search_request_id beyond implying it identifies an instant-search request. The name and UUID format are reasonably self-explanatory, and the description clarifies the tool's scope, but it does not explain where the ID comes from or how it relates to other tools.
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 the exact verb ('read'), resource ('full search results returned for a single instant-search request'), and the specific fields returned. It clearly distinguishes this tool from siblings like read_chat_request_documents and read_sessions by focusing on search results rather than chat requests or sessions.
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 explicitly says when to use it: 'Use this to inspect the exact results a user saw for their search query.' This gives clear context for the tool's purpose, though it does not explicitly mention when not to use it or name alternative tools.
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.
Each tool targets a distinct resource or metric, and even the closely related analytics tools (e.g. get_top_languages vs get_top_locales, get_top_interaction_sources vs get_top_clicked_urls) are explicitly differentiated in their descriptions. There is no real overlap that would cause an agent to misselect.
The verb prefixes create_, get_, list_, read_, and update_ are used predictably, and there is no mixing of camelCase or other conventions. The main inconsistency is that read_sessions is actually a list operation while list_nodes is the equivalent pattern for nodes, and read_session_detail is the singular read.
At 33 tools, this set is well beyond the 16-25 'heavy' range and far above the typical well-scoped 3-15 range. Many of the get_top_* analytics endpoints are individually distinct but could likely be consolidated into fewer parameterized tools to reduce agent selection overhead.
The read and analytics side is comprehensive, but the management lifecycle has notable gaps: knowledge nodes support create/read/update but no delete, and data sources/tools lack create/delete operations. Agents can work around some gaps, but content deletion is a clear dead end for a knowledge-base management surface.