Skip to main content
Glama

hermes_update_draft

Update specific fields of an existing document draft—title, summary, product, contributors, approvers, approver groups, or custom fields—leaving all other details unchanged.

Instructions

Update a document draft in Hermes (WIP status only). Supports updating title, summary, product, contributors, approvers, approver groups, and custom fields. All fields are optional — only provided fields are changed. The document_id must be the SharePoint objectID from hermes_list_drafts or hermes_create_draft.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoNew title for the document
ownersNoUpdated list of owner email addresses (replaces existing)
productNoNew product or area name
summaryNoNew summary or abstract
approversNoUpdated list of approver email addresses (replaces existing)
document_idYesSharePoint objectID of the draft to update (from hermes_list_drafts or hermes_create_draft)
contributorsNoUpdated list of contributor email addresses (replaces existing)
custom_fieldsNoCustom fields specific to the document type. IMPORTANT: 'name' must be the camelCase key (e.g. 'currentVersion'), 'type' must be uppercase (e.g. 'STRING', 'PEOPLE'), and 'display_name' must match the displayName from the API exactly. Call hermes_get_document on an existing doc or hermes_list_document_types to discover valid keys and types.
approver_groupsNoUpdated list of approver group names (replaces existing)
Install Server

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It does explain partial-update semantics ('only provided fields are changed') and the WIP-only restriction, which is valuable. However, it does not mention what the operation returns, whether there are permission requirements, or how errors are surfaced, leaving meaningful gaps for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no filler: purpose/WIP restriction, partial-update semantics, and the source of document_id. The information is front-loaded and every sentence contributes to correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The combination of description and a fully covered schema gives an agent the necessary info to call the tool correctly: WIP-only eligibility, patch semantics, required document_id, and detailed custom field rules. Missing behavioral details like response shape or non-WIP failure behavior are notable but not blockers given the rich schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents every parameter, including the detailed custom_fields object. The description adds the useful patch behavior ('only provided fields are changed') but mostly lists fields that the schema already names, so it does not substantially extend the schema's semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Update') and resource ('a document draft in Hermes') and adds the critical WIP-status constraint, which distinguishes this tool from the sibling hermes_update_document. It also enumerates the updateable fields, making the tool's scope immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly scopes usage to WIP drafts and explains that all fields are optional with only provided fields changed, plus the required document_id provenance. However, it does not explicitly name an alternative tool for non-WIP documents, so the when-not-to-use guidance is mostly implicit rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HarutuneDavisIBM/hermes-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server