browseEnumerate doc paths in a category/namespace. Use to discover what exists before calling get_document or a targeted grep_docs. NOT a content search — use semantic_search for behavior/concept lookups or grep_docs for token lookups. Returns {path, title, chunks}[].
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| namespace | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description goes further by specifying the return shape '{path, title, chunks}[]' and explicitly clarifying that it does NOT do content search, adding meaningful behavioral context beyond the annotations. No contradiction exists.
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?
The description is three sentences long, front-loaded with the purpose, then usage, then contrast, then return format. Every sentence carries essential information, and there is no fluff or repetition, achieving high conciseness and logical structure.
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 that this is a simple enumeration tool with two optional parameters, read-only annotations, and no output schema, the description covers all needed aspects: purpose, usage, when-not-to-use, and return format. It is complete for the tool's complexity and context.
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 0%, so the description must compensate. It does mention 'category/namespace' as scoping parameters, but it does not explain their distinct roles or how they interact. The ambiguity of the slash between category and namespace leaves their relationship unclear, though the enum for category provides some guidance.
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 explicitly states the tool enumerates doc paths within a category/namespace, using the specific verb 'enumerate' plus the resource 'doc paths'. It also distinguishes itself from sibling tools by explicitly contrasting with content searches and referencing alternatives, making its unique purpose clear.
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 gives direct when-to-use guidance: 'discover what exists before calling get_document or grep_docs'. It also provides explicit when-not-to-use instructions and names alternatives (semantic_search for behavior/concept lookups, grep_docs for token lookups), fulfilling the usage guidelines dimension perfectly.
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 has a clearly distinct purpose: asset_lookup handles game-asset hashes/names, lookup_native handles script natives, grep_docs does exact token search, semantic_search handles concept/behavior queries, browse/list_namespaces orient, get_document/read_lines retrieve content, get_invoke_guide is a specialized reference, and share_finding contributes. The descriptions explicitly cross-reference when NOT to use each tool, eliminating ambiguity.
Most tools follow verb_noun pattern (get_document, grep_docs, list_namespaces, lookup_native, read_lines, share_finding), but asset_lookup uses noun_verb order, and browse is a bare verb. The deviation is minor and the pattern remains predictable.
10 tools is well within the ideal 3-15 range. Each tool earns its place: search, retrieval, discovery, lookup, and contribution are all covered without bloat. The count matches the server's purpose as a comprehensive documentation interface.
The domain is RedM/RDR3 documentation access, and the set covers the full lifecycle: orientation (list_namespaces, browse), search (semantic_search, grep_docs, lookup_native, asset_lookup), retrieval (get_document, read_lines, get_invoke_guide), and contribution (share_finding). There are no obvious dead ends or missing operations for the stated purpose.