update_inventionUpdates one or more sections of an existing invention disclosure with new content and returns the updated invention. Overwrites the specified sections.
| Name | Required | Description | Default |
|---|---|---|---|
| sections | Yes | Named invention sections and their full replacement text | |
| invention_id | Yes | The invention identifier |
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as destructive, and the description adds meaningful behavior by explicitly saying it overwrites the specified sections and returns the updated invention. This clarifies that content is replaced rather than merged, which is valuable context beyond the structured annotations.
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 fully convey the operation, the overwrite behavior, and the return value. There is no filler or redundant restatement; each 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?
For a nested-object update tool with an output schema and destructive annotations, the description is adequately complete. It explains the core behavior, and the schema covers detailed section properties, so nothing critical is missing for an agent to use 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 the schema already documents each section parameter and the empty-string clearing behavior. The description adds a general statement about replacing section content, which aligns with the schema but does not meaningfully expand parameter semantics.
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 uses a specific verb and resource: it updates one or more sections of an existing invention disclosure. It also clarifies that this is an overwrite operation and returns the updated invention, cleanly distinguishing it from creation and retrieval siblings like create_invention and get_invention.
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 clearly conveys that this tool is for modifying existing invention disclosures by replacing section content. It does not explicitly name alternatives or state when not to use it, but the 'existing' qualifier gives enough contextual guidance for an agent to avoid using it for creation.
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.