補助・助成.jp

記入済みの様式を出力する

export_application

記入済みの様式を元の書式のまま出力し、個別のダウンロードURLを返す。

    Excelを含む場合は note の開き直し・再計算後の表紙・集計値の確認手順を利用者に案内する。
    入力値からの検算とExcelで開いた表示確認は別であり、未確認の反映を確認済みと伝えない。

    Args:
        case_id: 出力する案件ID。
        form_ids: 出力する様式ID。省略時は記入済みの全様式。
        include_zip: 一括取得などを利用者が希望した場合だけtrue。既定ではZIPを作らない。

    Returns:
        files（少数Wordはdocx直接添付、添付不可なら個別URLを案内）、zip、delivery_note。
        Word→確認用PDF変換は非対応。要求時はBot側の変換手段かWordのPDF保存を案内し、Wordも残す。
        提出前に内容（書式の崩れ・記入漏れ・添付書類）を確認するよう伝える。提出は利用者が行う。

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": {
      "case_id": "<case_id>"
    },
    "name": "export_application"
  }
}

Input Schema

Name	Required	Description	Default
`case_id`	Yes
`form_ids`	No
`include_zip`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026
- addedInput schema / properties / include_zip
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```
First observedOct 21, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false with destructiveHint=false, and the description is consistent with that: it produces files and URLs rather than modifying the application. Beyond the annotations it discloses delivery mechanics (small Word files attached directly as docx, otherwise per-file URLs, plus zip and delivery_note), the default of no ZIP creation, and the unsupported conversion path. It does not say what happens to previously generated files or whether URLs expire, which keeps it at 4.

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 summary line is front-loaded and the Args/Returns structure is easy to scan. However, several sentences drift into user-facing operational coaching (how to verify recalculated Excel figures, whether a reflection counts as confirmed, that the user must submit), which is context rather than tool definition and inflates length.

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?

Three parameters, one required, an output schema present, and no destructive behavior add up to a low-complexity tool, and the description still covers inputs, default behavior, delivery shape, and unsupported operations. The remaining gap is sibling routing against validate_and_export_application, which an agent may confuse with this tool.

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

Parameters4/5

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

Schema description coverage is 0%, so the description carries the full burden, and it documents all three parameters: case_id as the case to export, form_ids as the subset with an omit-means-all default, and include_zip as opt-in bulk. That compensates well for the empty schema, though it adds no format detail (e.g., ID syntax) for case_id or form_ids.

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 first sentence gives a specific verb and resource: it outputs filled-in forms in the original format and returns individual download URLs. An agent can tell this is an export/delivery tool rather than an editing one. It does not explicitly distinguish itself from the sibling validate_and_export_application, which keeps it below a 5.

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?

Concrete conditions are given for each optional parameter: form_ids omitted means all filled forms, and include_zip should be true only when the user asks for bulk retrieval. It also states an exclusion (Word→PDF conversion is not supported) and points to alternatives (the Bot-side converter or Word's Save-as-PDF). It lacks any routing guidance relative to validate_and_export_application, so it is not a 5.

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

All 補助・助成.jp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?