get_inventionReturns an invention disclosure rendered as markdown, including the problem, solution, technical details, and prior art.
| Name | Required | Description | Default |
|---|---|---|---|
| invention_id | Yes | The invention identifier |
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| url | Yes | ||
| title | Yes | ||
| refNum | No | ||
| markdown | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, covering safety. The description adds the behavioral detail of returning markdown and specific content, but does not elaborate on potential side effects or response format beyond that. Since annotations are present, this additional info is sufficient but not extensive.
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, concise sentence that front-loads the action and clearly states the output format and contents. There is no unnecessary verbosity or ambiguity.
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?
The description sufficiently conveys the purpose and expected return content. Although an output schema is not provided, the markdown format and listed sections give adequate context for an agent to understand the result. It is complete for a simple read operation.
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 already defines invention_id as a required string with a minimal description. The tool description does not add any additional meaning or elaboration about the identifier (e.g., where to find it, expected format). With full schema coverage, no extra value is provided, so a baseline score of 3 is appropriate.
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 clearly states the tool returns an invention disclosure in markdown format, listing the included sections. It is specific and distinct from sibling tools like list_inventions or get_invention_template by focusing on a single disclosure with its content.
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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., list_inventions to obtain IDs, or get_invention_template for a template). It lacks conditions or exclusions, leaving the agent to infer usage from the parameter name.
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.