Save corrected content as a new version of one of your TomeVault files. The previous version is kept and the file is re-checked. Returns the new version number and the verdict, never the file content.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The complete corrected file. Partial content would truncate the file. | |
| item_id | Yes | The vault file id, from list_vault_items. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations: it discloses that the previous version is kept, that the file is re-checked as a side effect, and that the response contains only the version number and verdict, never file content. This contextualizes the destructiveHint=true and gives the agent a concrete safety and return-behavior model.
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, each earning its place: the action, the side effect/versioning behavior, and the return payload. It is front-loaded with the primary purpose and contains no 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 two-parameter tool with no output schema, the description covers the essential context: what to pass (via schema + 'corrected content'), what side effects occur (version kept, re-check), and what is returned (version number and verdict, not content). No critical operational information 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?
Schema description coverage is 100%, with item_id and content already well documented (e.g., 'complete corrected file' and 'partial content would truncate'). The tool description reinforces 'corrected content' but does not add material parameter-level meaning beyond the schema, so the baseline 3 applies.
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 a specific action ('save corrected content as a new version') on a specific resource ('one of your TomeVault files'), and clarifies that this is a versioning write, not an overwrite or read. It is clearly differentiated from the sibling read/scan/convert tools, even though no sibling is named.
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 phrase 'corrected content' establishes when the tool is appropriate, and the description implies it is the write step after content has been corrected. It does not explicitly name alternatives or exclusions, but the use case is clear enough for an agent to select it.
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.
Several tools overlap in purpose: get_tome and get_vault_item both fetch a single item's content without clarifying the relationship between tomes and vault items, and connect_source overlaps with get_workspace_status for reporting connected sources. The detailed descriptions help, but the boundaries between these pairs remain unclear.
Most tool names follow a clear snake_case verb_noun pattern (get_tome, list_vault_items, scan_content, verify_attestation). There are minor deviations such as deliver_to_source with its preposition and connect_source whose name undersells its reporting behavior, but the overall convention is predictable.
Fifteen tools is within a reasonable range for a workspace, content-management, and attestation service, and most tools map to a distinct concern. The count feels slightly heavy because a few tools (get_tome vs get_vault_item, connect_source vs get_workspace_status) could potentially be consolidated.
Read, search, scan, versioning, and delivery workflows are well covered, along with members, billing, and workspace status. However, there are notable lifecycle gaps: no disconnect/remove for sources, no remove or role-update for members, and no delete or explicit approve action for vault items/versions.
