get_reviewReturns a review: its metadata, the document under review rendered as markdown, and each comment thread with a stable comment ID. Attorney redlines are included as suggested changes, each with the original text, the proposed replacement, and an optional rationale.
| Name | Required | Description | Default |
|---|---|---|---|
| review_id | Yes | The review identifier |
| Name | Required | Description | Default |
|---|---|---|---|
| review | Yes | ||
| threads | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, and the description adds useful behavioral details beyond that: the document is rendered as markdown, comment IDs are stable, and attorney redlines come as structured suggested changes. It does not mention error cases or prerequisites, but none are critical for a simple read operation.
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 a single focused sentence that front-loads the main verb and resource, then uses a colon to list the included elements. Every clause adds value, and there is no repetition or filler.
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-parameter, read-only retrieval tool with an output schema and sibling list_reviews, the description is complete: it states exactly what is returned, including markdown rendering, stable comment IDs, and redline semantics. No critical operational detail is missing.
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?
There is only one parameter, review_id, and the schema description covers it 100%, so the baseline is 3. The description does not add further parameter-level meaning such as how to obtain the review_id or expected format, but the schema's field name is self-explanatory.
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 opens with a specific verb and resource, 'Returns a review', then enumerates the concrete payload pieces: metadata, markdown rendering of the document, comment threads with stable IDs, and attorney redlines as suggested changes. This makes it easy to distinguish from sibling tools like list_reviews or get_invention_feedback.
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 this tool is for retrieving one full review with comments and redlines, but it never explicitly states when to prefer it over alternatives such as list_reviews or respond_to_review. There is no exclusionary guidance, so the agent must infer usage from the singular 'a review' and the detailed return contents.
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 invention lifecycle tools are clearly distinct, but there are overlapping pairs: add_comment and reply_to_comment both handle replies to threads, and fetch overlaps with get_invention for invention content. These overlaps require careful reading of descriptions to select the right tool.
Tool names generally follow a snake_case verb_noun pattern like list_inventions, create_invention, and update_invention. A few deviations such as fetch, search, and whoami break the pattern slightly, but the naming remains predictable overall.
At 18 tools, the set is slightly above the ideal scoped range and contains some functional overlap, making it feel heavier than necessary. Each tool has a plausible purpose, but the surface could be tightened by merging the overlapping comment and document-retrieval tools.
The tool set covers the core invention lifecycle well: create, get, list, update, validate, submit, and analyze, plus review and comment workflows. Minor gaps exist around comment management and lack of explicit review creation/deletion, but there are no major dead ends for common workflows.