sota-agw-mcp

Điền template → file mới

template_fill

Fill values into highlighted DOCX/XLSX template fields and save a new output file while keeping the original unchanged, then return the file path and any missing fields for review before use.

Instructions

Điền giá trị vào các trường tô vàng, lưu file MỚI ở /output (file gốc giữ nguyên). Trả đường dẫn + các trường còn thiếu — cho người dùng xem lại trước khi dùng / gửi.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>",
      "values": "<values>"
    },
    "name": "template_fill"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes
`values`	Yes
`output_name`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.11.0Nov 9, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false with destructiveHint=false, and the description reinforces this with a concrete guarantee that the source file is preserved and output goes to <workdir>/output. It also discloses that the response surfaces missing fields, which is behavioral context beyond the annotations. It does not cover failure modes such as a template with no highlighted fields or a bad output_name.

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

Conciseness4/5

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

Two short sentences, front-loaded with the action and the file-safety guarantee, with no filler. It is tight to the point of being thin on the parameters, but nothing is redundant.

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

Completeness3/5

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

An output schema exists, so the return path and missing-fields payload do not need describing here. The real gap is the undocumented `values` object schema and `output_name` semantics for a tool that writes a file, which leaves an agent guessing at call shape despite a clear overall purpose.

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 0% across three parameters including a free-form nested object, so the description must carry the load and largely does not. Saying values go into 'các trường tô vàng' hints that keys correspond to highlighted field names, but nothing explains what `path` points to or how `output_name` relates to the default output location.

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?

States a specific verb and resource: fill values into yellow-highlighted fields and save a NEW file under <workdir>/output, leaving the original untouched. The scope (only highlighted fields) and the artifact produced are concrete enough to separate it from template_inspect, though no sibling is named explicitly.

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

Usage Guidelines3/5

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

Usage is implied by the closing note that the result is for the user to review before using or sending, which sketches a workflow but not a decision rule. There is no statement of when to choose this over inspecting a template first, nor any prerequisite about the template already having highlighted fields.

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

Deploy Server