Skip to main content
Glama

補助金の対象になるか判定する

check_eligibility
Read-only

1つの補助金について自社が対象になりそうかを項目別に判定する(likely_eligible / needs_review / ineligible)。

    subsidy_id は recommend_subsidies の id。plan を省略するとプロフィールの plan を使う。
    各項目の根拠(公募要領のページ引用)、不足情報、補助額試算を返す。
    guideline に、公募要領を読めているか(available)と、公式サイトで見つけた要領のリンク(pdf_candidates)、
    公募要領で確かめる観点(viewpoints)がある。available が false のときは、リンクを開いて観点を確かめる。
    観点は合否ではない。確かめられなければ「未確認」と伝える。
    

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": {
      "subsidy_id": "<subsidy_id>"
    },
    "name": "check_eligibility"
  }
}

Input Schema

NameRequiredDescriptionDefault
planNo
subsidy_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / $defs / InvestmentPlan / properties / planned_end / description
      Added value: +"事業の完了予定日。利用者が言った日付をそのまま入れ、推奨日程に置き換えない"
    • addedInput schema / $defs / InvestmentPlan / properties / planned_start / description
      Added value: +"事業の開始予定日(発注日ではない)。利用者が言った日付をそのまま入れる"
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnly/openWorld annotations, it discloses the returned assessment structure, page citations as evidence, missing-information reporting, subsidy amount estimation, and the guideline subfields available/pdf_candidates/viewpoints. It also warns that viewpoints are not pass/fail and that unverifiable items should be reported as unconfirmed, which is valuable behavioral context.

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 description is front-loaded with the core action and result statuses, then adds the important subsidy_id/plan and guideline-workflow details. It is somewhat dense, but each section addresses a real decision an agent must make before calling or interpreting the tool.

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?

Given the read-only but open-world nature of the tool, the existing output schema, and the nested plan schema, the description supplies the remaining operational context an agent needs. It covers input source, fallback behavior, returned evidence, and how to handle unavailable guidelines.

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?

Top-level schema description coverage is reported as 0%, so the description usefully compensates by defining subsidy_id as an id from recommend_subsidies and explaining the plan omission fallback. The nested InvestmentPlan fields are already well described in the schema, so the description does not need to repeat them.

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

Purpose5/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: judging one subsidy's eligibility for the company, item by item, with explicit result categories (likely_eligible / needs_review / ineligible). It also anchors subsidy_id to recommend_subsidies, helping distinguish this tool from sibling search/recommend tools.

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 clearly explains that subsidy_id comes from recommend_subsidies and that omitting plan falls back to the profile plan. It also gives concrete guidance for when guideline.available is false: open the links and check the viewpoints. It stops short of explicitly naming when to use this versus get_subsidy or search_subsidies, so it is strong but not exhaustive.

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.

Resources