Skip to main content
Glama

Helvabase — Governed response dossiers

helvabase_prepare_client_file

DestructiveIdempotent

Prepare a version-bound assignment for filling an original with the customer's own file tools, or attaching it unchanged. Requires enabled managed files, exact-plan agreement and all existing source/draft/adaptive approval gates. Use expectedAssignment=null for the first assignment. Returned values and targets are authoritative; this does not create or approve a file. Read all assignment/original pages, fill a copy and submit actual bytes. Unsupported arbitrary Office rewrites or PDF overlays remain blocked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemIdYes
selectionYes
pdfTargetsNo
sectionIdsNo
docxTargetsNo
xlsxTargetsNo
planRevisionYes
draftRevisionYes
confirmationIdYes
idempotencyKeyYesUnique key for this logical mutation. Reuse exactly the same key and arguments after a timeout; never generate a new key to force a replay.
expectedVersionYes
adaptiveRevisionNo
consistencyFactsNo
adaptiveDocumentIdNo
expectedAssignmentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds value beyond these by clarifying that despite the destructive hint, 'this does not create or approve a file,' which is a key behavioral distinction. It also states 'Returned values and targets are authoritative,' giving insight into the return behavior. It does not contradict annotations and adds useful context about prerequisites and limitations, though it does not fully describe side effects.

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

Conciseness3/5

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

The description is moderately sized but includes an instruction-like sentence ('Read all assignment/original pages, fill a copy and submit actual bytes') that is ambiguous as to whether it describes the tool's behavior or gives agent workflow guidance. This adds confusion rather than value. The core purpose is front-loaded, but the extra sentence could be removed or clarified. Overall it is not overly verbose but has some unnecessary content.

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

Completeness2/5

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

With 15 parameters, nested objects, no output schema, and only 7% schema coverage, the description is far from complete. It does not explain the structure of the returned values ('Returned values and targets are authoritative' gives no details), does not describe how to construct the complex nested objects, and does not clarify the distinction between planRevision, draftRevision, adaptiveRevision, expectedVersion, and expectedAssignment. An agent would need substantial additional knowledge to correctly invoke this tool.

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

Parameters2/5

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

Schema description coverage is only 7%, so the description must compensate for the many undocumented parameters. The description only provides meaning for expectedAssignment ('Use expectedAssignment=null for the first assignment') and vaguely references plan/draft/adaptive revisions through the prerequisite phrase. The other 15 parameters, including complex nested objects like selection, pdfTargets, docxTargets, xlsxTargets, consistencyFacts, and the revision objects, remain unexplained in the description. This is insufficient given the low schema coverage.

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

Purpose4/5

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

The description states a specific verb and resource: 'Prepare a version-bound assignment for filling an original with the customer's own file tools, or attaching it unchanged.' It distinguishes itself from the actual submission (submit_client_file) by explicitly stating 'this does not create or approve a file,' clarifying it is a preparation step. The purpose is clear, though the later instruction 'Read all assignment/original pages, fill a copy and submit actual bytes' introduces ambiguity about whether the tool itself does this or the agent does it afterward.

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?

It provides prerequisites ('Requires enabled managed files, exact-plan agreement and all existing source/draft/adaptive approval gates') and a specific parameter hint ('Use expectedAssignment=null for the first assignment'). It implies the actual file creation/submission is done elsewhere ('this does not create or approve a file'), and lists a limitation ('Unsupported arbitrary Office rewrites or PDF overlays remain blocked'). However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.