oda-mcp

지원 국가 목록

country_list

Read-onlyIdempotent

Retrieve a list of 44 partner countries for overseas procurement, including ISO2, ISO3, English names, and procurement model slugs.

Instructions

overseas-procurement-100의 44개 협력국을 ISO2·ISO3·영문명·조달 모델 slug와 함께 반환합니다.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "country_list"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`count`	Yes
`countries`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Jul 29, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-established. The description adds value by specifying the exact data fields returned and the fixed set of 44 countries, going beyond what annotations provide.

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

Conciseness5/5

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

The description is a single sentence that is front-loaded with the tool's core function and specific output details. Every piece of information is relevant, and there is no redundant or missing content. It is optimally concise.

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 that the tool has no parameters and an output schema exists (context signals indicate 'Has output schema: true'), the description adequately covers the tool's behavior. The provided fields (ISO2, ISO3, English name, procurement model slug) likely align with the output schema, making the description complete for an agent to understand what the tool does.

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 zero parameters and 100% schema coverage, the schema already fully defines the input structure. The description does not need to add parameter details. Baseline 4 is appropriate for a parameterless tool.

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 is specific and complete: it states the tool returns a list of 44 cooperating countries from 'overseas-procurement-100' with specified fields (ISO2, ISO3, English name, procurement model slug). This clearly distinguishes it from sibling tools like country_data_status or country_hazard_snapshot.

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?

The description does not explicitly provide usage context or contrast with alternatives. Although the purpose is clear from the tool name and description, there is no guidance on when to prefer this tool over siblings, such as when to get a full list versus querying specific country data.

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

Deploy Server