補助・助成.jp

記入内容を検査して出力する

validate_and_export_application

同じ記入内容を検査し、pass なら出力。fail は出力しない。 warning・unknown は指摘を利用者と確認した後だけ allow_warnings=true で出力する。 expected は validate_application と同じ。表の金額には元の値・行列見出しを渡す。必須欄・補助額の正しさ・書式は検証しきれないので、提出前に実ファイルを確認する。 Excelを含む場合は export.note の開き直し・再計算後の表紙・集計値の確認手順を利用者に案内する。 passでも入力値からの検算とExcelで開いた表示確認は別であり、未確認の反映を確認済みと伝えない。出力は個別URL。少数Wordはdocx直接添付を優先し、添付不可なら個別URLを案内する。 ZIPは利用者が希望した場合だけ include_zip=true。Word→確認用PDF変換は非対応。 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": "validate_and_export_application"
  }
}

Input Schema

Name	Required	Description	Default
`case_id`	Yes
`expected`	No
`include_zip`	No
`allow_warnings`	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

A4.3/5.0

Behavior5/5

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

Beyond the annotations, the description discloses pass/fail export behavior, warning/unknown gating, validation limitations, Excel verification guidance, output URL versus attachment behavior, ZIP constraints, and PDF handling. The readOnlyHint=false annotation is consistent with exporting and file creation.

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?

The core behavior is front-loaded in the first sentence, and most subsequent sentences add operational constraints that an agent needs. It is long but largely earns its length given the tool's complexity and edge cases.

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

Completeness5/5

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

For a complex validate-and-export tool, the description covers validation limits, warning handling, export modes, attachment versus URL behavior, ZIP policy, and PDF limitations. Although an output schema exists, the extra return-format context is useful and not merely redundant.

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?

With 0% top-level schema description coverage, the description compensates well by explaining expected semantics, allow_warnings=true usage, and include_zip=true usage. Only case_id is left without explanation, which is a minor gap.

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 combined action: validate the same entered content and export only if the result is pass. It clearly distinguishes behavior from validate_application by noting expected is the same, but it does not explicitly differentiate itself from export_application.

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 gives concrete usage constraints: fail means no export, warning/unknown require allow_warnings=true only after user confirmation, include_zip only when requested, and no Word-to-PDF conversion. It lacks an explicit statement of when to choose this over the sibling export_application tool.

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?