Set document metadata (title, author, subject, keywords) in DOCX files programmatically via MCP.
Set metadata
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "docx.metadata_set"
}
}| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Set metadata' reveals nothing about effects, persistence, whether the document must be open, return behavior, or whether existing metadata is replaced or merged. This is effectively no behavioral information.
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 extremely short, but this is under-specification rather than effective conciseness. It contains no useful content beyond the tool name, so the brevity does not serve the agent's decision-making.
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?
In a document-editing toolset with many siblings, this description is too sparse to be complete. It omits the relationship to metadata_get, any dependency on open/saved documents, and the nature of the metadata being modified, making it inadequate for reliable tool selection.
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 input schema has zero parameters and 100% coverage, so there are no parameter semantics the description must clarify; the baseline for 0 params is therefore 4. The description might have added context about how metadata is supplied, but the schema already removes ambiguity about expected inputs.
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 'Set metadata' essentially restates the tool name and gives no information about what kind of metadata is being set, what scope it applies to, or how it relates to the sibling metadata_get tool. It is a bare verb+object phrase rather than a meaningful purpose statement.
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?
There is no guidance on when to use this tool, what prerequisites exist, or how it compares to alternatives like metadata_get or other mutating tools such as styles_set. The description leaves the agent to infer usage entirely from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.