Which integrations are available for this server?

Integrates with the National Election Commission (NEC) of South Korea's open API to provide election data, candidate profiles, district-level results, party vote-share history, and composite candidate packets for South Korean elections.

How do I use kr-elections-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kr-elections-mcp Search for candidates in the 2022 presidential election" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

kr-elections-mcp

by taehyun-lim

Overview Schema Source Related Servers Discussions Admin

Python

Remote

South Korean Election MCP (kr-elections-mcp)

Korean README

DOI Python 3.11+ License: MIT Auth: BYOK

South Korean Election MCP (kr-elections-mcp) is a local Python FastMCP server for South Korean election research. It combines NEC open data, normalized result adapters, and krpoltext text lookups into task-oriented MCP tools.

This repository is composite-first. It does not mirror every raw NEC endpoint as a public MCP tool. Instead, it focuses on higher-value workflows such as candidate packets, district summaries, election overviews, diagnostics, and safe text lookups.

What It Provides

Candidate search and profile retrieval
Candidate policy retrieval when NEC coverage is available
District-level election results and summaries
Party vote-share history and election overviews
krpoltext text lookup for campaign booklet corpus rows
Composite packet assembly across NEC, results, and krpoltext text
NEC API diagnostics for local BYOK usage

Related MCP server: open-assembly-mcp

Quick Start

1. Install the CLI

Requires Python 3.11+.

Recommended for most users:

pipx install .

pipx keeps the CLI isolated and makes it easier to point MCP clients at a stable kr-elections-mcp command.

If you prefer plain pip:

python -m pip install .

For development from a repository checkout:

python -m venv .venv
# activate the virtual environment for your shell
python -m pip install -r requirements.txt
python -m pip install -e .

This project is currently distributed as a Python package, not an npm package. If your MCP client is JavaScript- or Node-based, install the Python CLI first and then reference kr-elections-mcp from the client config below.

2. Apply for NEC API access

This project uses a BYOK model. Each user must apply for the relevant NEC OpenAPI products through the Public Data Portal (data.go.kr).

The Public Data Portal notes that encoded and decoded service keys can behave differently depending on API environment or invocation conditions. This server accepts both forms.

See:

3. Store the key securely

Recommended:

kr-elections-mcp setup-key

setup-key accepts both encoded and decoded NEC service keys. You can store one or both.

Important behavior:

If only NEC_API_KEY_DECODED is present, the server derives the encoded variant automatically.
Request order is always decoded first, then encoded.
Legacy NEC_API_KEY still works as a fallback.

Useful commands:

kr-elections-mcp show-key-source
kr-elections-mcp clear-key

4. Run the MCP server

kr-elections-mcp run

MCP Client Example

After installation, your MCP client should launch the Python-installed CLI, not an npm wrapper.

{
  "mcpServers": {
    "south-korean-election": {
      "command": "kr-elections-mcp",
      "args": ["run"]
    }
  }
}

If you do not want OS keyring storage, you can provide the key in the MCP client environment instead:

{
  "mcpServers": {
    "south-korean-election": {
      "command": "kr-elections-mcp",
      "args": ["run"],
      "env": {
        "NEC_API_KEY_DECODED": "YOUR_DECODED_KEY"
      }
    }
  }
}

NEC_API_KEY_ENCODED is not required if the decoded key is already available.

API Key Storage Rules

Key lookup priority is:

Process environment or MCP client env
OS keyring
.env development fallback

Within each source, the server prefers NEC_API_KEY_DECODED and NEC_API_KEY_ENCODED, then falls back to legacy NEC_API_KEY.

Recommended for public users:

Use kr-elections-mcp setup-key when possible.
Keep keys out of chat, screenshots, and Git commits.
Treat .env as a development-only fallback.
If you intentionally use .env, pass it explicitly with --env-file .env.
In many environments, NEC_API_KEY_DECODED alone is enough.

Source Checkout Fallback

If you are running directly from a repository checkout instead of an installed package, the legacy commands still work:

python server.py setup-key
python server.py show-key-source
python server.py run

If you intentionally want to load a local dotenv file, pass it explicitly:

kr-elections-mcp run --env-file .env
python server.py run --env-file .env

Tools

Core tools:

list_elections
list_districts
list_parties
search_candidates
get_candidate_profile
get_candidate_policies
get_district_results
get_district_summary
get_party_vote_share_history
get_election_overview
assemble_candidate_packet
diagnose_core_api_access

Additional tools:

diagnose_full_api_access
get_krpoltext_text
get_krpoltext_meta
match_krpoltext_candidate

`krpoltext` Text Support

This repository does not OCR live NEC booklet PDFs on demand.

Current behavior:

get_krpoltext_text can match on candidate name plus optional year, office, district, and party hints.
It can also match directly on booklet code.
get_krpoltext_meta returns structured campaign booklet metadata without the long booklet text body.
The metadata tool preserves merged candidate bio fields such as giho, birthday, age, job*, edu*, and career* when the upstream dataset provides them.
match_krpoltext_candidate resolves an NEC candidate first, then ranks krpoltext rows using election scope plus stronger personal identifiers.
Same-election same-district same-name collisions remain ambiguous unless a stronger personal identifier uniquely matches.
The adapter now uses the current krpoltext data manifest under /data/index.json, falls back to /data/metadata.json when needed, and resolves the campaign_booklet resource.
It understands both legacy download_url entries and newer download_urls maps from krpoltext 0.2.0, including OSF-managed artifact links.
Enriched NEC linkage fields such as huboid are preserved when the upstream corpus provides them, and match_krpoltext_candidate can use them as strong identifiers.
Runtime installs now include pyarrow, so enriched Parquet artifacts can be preferred by default while CSV metadata and fallback URLs remain supported.
Legacy text fetches stay on configured krpoltext hosts, and dataset artifact fetches accept the trusted OSF-managed download hosts used by the current manifest.
When text is available in the campaign booklet corpus, the tool returns the dataset-backed text record and corpus metadata such as code, party_name, and page_count when present.
This public repository does not expose live NEC booklet discovery, URL derivation, or PDF download.

Example metadata lookup for Moon Jae-in in the 2017 presidential election:

get_krpoltext_meta(
  candidate_name="문재인",
  election_year=2017,
  office_name="president",
  district_name="전국 대한민국",
  party_name="더불어민주당",
  limit=3
)

Example response shape:

{
  "items": [
    {
      "record_id": "ECM0120170001_0001S",
      "code": "ECM0120170001_0001S",
      "candidate_name": "문재인",
      "office_name": "president",
      "election_year": 2017,
      "district_name": "전국 대한민국",
      "giho": "1",
      "party_name": "더불어민주당",
      "birthday": "1953-01-24",
      "age": 64,
      "edu": "경희대학교 법률학과 졸업",
      "career1": "(전)더불어민주당 당대표",
      "career2": "(전)제19대 국회의원",
      "page_count": 15,
      "has_text": true
    }
  ],
  "warnings": []
}

Example conservative NEC-to-krpoltext match:

match_krpoltext_candidate(
  candidate_name="문재인",
  sg_id="20170509",
  sg_typecode="1",
  district_name="전국 대한민국",
  limit=5
)

Example response shape:

{
  "status": "resolved",
  "message": "Resolved krpoltext metadata row from NEC election, office, district, and name context.",
  "item": {
    "code": "ECM0120170001_0001S",
    "candidate_name": "문재인",
    "district_name": "전국 대한민국",
    "giho": "1",
    "birthday": "1953-01-24",
    "age": 64,
    "match_method": "name+year+office+district+party+giho+birthday+age+sex+education+job+career",
    "match_confidence": 1.0
  },
  "warnings": [],
  "errors": []
}

The examples above use a real 2017 presidential-election row from the managed campaign booklet corpus.

Resources

resource://nec/elections
resource://nec/districts/{sg_id}/{sg_typecode}
resource://nec/parties/{sg_id}/{sg_typecode}

Documentation

How to Cite

If you use this software in research, cite the software record or export citation metadata from CITATION.cff.

DOI: 10.5281/zenodo.19490046
Citation metadata: CITATION.cff

Example citation:

Lim T (2026). kr-elections-mcp. doi:10.5281/zenodo.19490046, Python package version 0.1.0, https://github.com/taehyun-lim/kr-elections-mcp.

Example BibTeX:

@Manual{Lim2026krElectionsMcp,
  title = {kr-elections-mcp},
  author = {Tae Hyun Lim},
  year = {2026},
  doi = {10.5281/zenodo.19490046},
  url = {https://github.com/taehyun-lim/kr-elections-mcp},
  note = {Python package version 0.1.0},
}

Testing

Tests are designed to run with mocks and stubs even without a live NEC API key.

pytest

The source-adapter tests cover krpoltext manifest resolution, trusted-host handling, and campaign booklet corpus lookups.

Limitations

NEC policy coverage is incomplete and depends on service support by election and office.
Live NEC API access still depends on each user's approved data.go.kr access.
Result coverage can differ by source and historical election availability.
krpoltext support depends on the current external dataset manifest and does not perform live OCR over NEC booklet files.

License

This project is released under the MIT License.

Available Tools

16 tools

assemble_candidate_packetD

ParametersJSON Schema

Name	Required	Description	Default
`giho`	No
`sg_id`	No
`sd_name`	No
`party_name`	No
`sg_typecode`	No
`candidate_ref`	No
`district_name`	No
`candidate_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

diagnose_core_api_accessD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

diagnose_full_api_accessD

ParametersJSON Schema

Name	Required	Description	Default
`include_optional`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_candidate_policiesD

ParametersJSON Schema

Name	Required	Description	Default
`giho`	No
`sg_id`	No
`sd_name`	No
`party_name`	No
`sg_typecode`	No
`candidate_ref`	No
`district_name`	No
`candidate_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_candidate_profileD

ParametersJSON Schema

Name	Required	Description	Default
`giho`	No
`sg_id`	No
`sd_name`	No
`party_name`	No
`sg_typecode`	No
`candidate_ref`	No
`district_name`	No
`candidate_name`	No
`include_raw_fields`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_district_resultsD

ParametersJSON Schema

Name	Required	Description	Default
`sg_id`	Yes
`sd_name`	Yes
`sgg_name`	No
`wiw_name`	No
`sg_typecode`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_district_summaryD

ParametersJSON Schema

Name	Required	Description	Default
`sg_id`	Yes
`sd_name`	Yes
`sgg_name`	No
`wiw_name`	No
`sg_typecode`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_election_overviewD

ParametersJSON Schema

Name	Required	Description	Default
`sg_id`	Yes
`sg_typecode`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_krpoltext_metaD

ParametersJSON Schema

Name	Required	Description	Default
`code`	No
`limit`	No
`sg_id`	No
`huboid`	No
`party_name`	No
`office_name`	No
`sg_typecode`	No
`district_name`	No
`election_year`	No
`candidate_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_krpoltext_textD

ParametersJSON Schema

Name	Required	Description	Default
`code`	No
`limit`	No
`sg_id`	No
`huboid`	No
`party_name`	No
`office_name`	No
`sg_typecode`	No
`district_name`	No
`election_year`	No
`candidate_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_party_vote_share_historyD

ParametersJSON Schema

Name	Required	Description	Default
`sd_name`	No
`year_to`	No
`year_from`	No
`party_name`	Yes
`sg_typecode`	No
`district_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_districtsD

ParametersJSON Schema

Name	Required	Default
`sg_id`	Yes
`sd_name`	No
`match_mode`	No	strict
`sg_typecode`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_electionsD

ParametersJSON Schema

Name	Required	Description	Default
`year_to`	No
`year_from`	No
`sg_typecode`	No
`include_history`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_partiesD

ParametersJSON Schema

Name	Required	Description	Default
`sg_id`	Yes
`sg_typecode`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

match_krpoltext_candidateD

ParametersJSON Schema

Name	Required	Description	Default
`giho`	No
`limit`	No
`sg_id`	No
`sd_name`	No
`party_name`	No
`sg_typecode`	No
`candidate_ref`	No
`district_name`	No
`candidate_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_candidatesD

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`sg_id`	No
`sd_name`	No
`sg_typecode`	No
`district_name`	No
`candidate_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

16 tool updatesv0.1.0Jul 30, 2026
- First observedassemble_candidate_packet
- First observeddiagnose_core_api_access
- First observeddiagnose_full_api_access
- First observedget_candidate_policies
- First observedget_candidate_profile
- First observedget_district_results
- First observedget_district_summary
- First observedget_election_overview
- First observedget_krpoltext_meta
- First observedget_krpoltext_text
- First observedget_party_vote_share_history
- First observedlist_districts
- First observedlist_elections
- First observedlist_parties
- First observedmatch_krpoltext_candidate
- First observedsearch_candidates

Deploy Server

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

TDQS

D1.6/5.0

Scored 2026-07-30 09:00 across 16 tools

Disambiguation2/5

Several tools have overlapping names (e.g., get_district_results and get_district_summary; get_candidate_profile and get_candidate_policies). Diagnostic tools (diagnose_core_api_access, diagnose_full_api_access) are unrelated to elections, increasing confusion. Without descriptions, distinguishing purposes is challenging.

Naming Consistency4/5

All tool names follow a verb_noun pattern in snake_case, using verbs like list, get, search, assemble, diagnose, match. The pattern is mostly consistent, though the variety of verbs (e.g., assemble, diagnose) slightly deviates from the more common list/get/search conventions.

Tool Count4/5

16 tools is a reasonable count for an elections-related server. It covers multiple entities (elections, districts, parties, candidates) and includes some specialized tools. The count is slightly high but not excessive.

Completeness2/5

The tool set appears to support read and search operations only (no create, update, delete). The inclusion of diagnostic and 'krpoltext' tools suggests extraneous functionality unrelated to an elections data API. Gaps like updating candidate information or managing election results are likely to cause agent failures.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Dados Abertos Senado BR MCP A
io.github.SidneyBissoli
MCP server for Brazilian Federal Senate open data (legislative, administrative, e-Cidadania).
Government Data Open Data
6926
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
mcpOAuth
com.bullpenstrategygroup.rotunda
An MCP server that provides congressional transcripts
Government Data Search Open Data
2
FirstData
io.github.Vist233
Hosted MCP server for finding authoritative primary data sources and official portals.
Search Open Data Government Data
2144

Related MCP Servers

houan-mcp
Government Data Open Data
SHAYOUWORLD
A
license
A
quality
C
maintenance
MCP server for searching Japanese Diet bills and committee Q\&A records via the NDL Kokkai API.
Updated 5 months ago (2026-04-25 06:59 UTC)
4
5 npm
1
MIT
open-assembly-mcp
Government Data Open Data
kyusik-yang
A
license
A
quality
D
maintenance
MCP server for the Korean National Assembly Open API, enabling querying of bills, members, votes, committees, and more via natural language.
Updated 4 months ago (2026-05-19 03:03 UTC)
20
Apache 2.0
narajangteo-prespec
Government Data Open Data
opendata-kr
A
license
A
quality
A
maintenance
MCP server that wraps the Korean government's '나라장터 사전규격정보서비스' API, enabling natural language search and retrieval of public procurement pre-specifications through simplified tools.
Updated 9 days ago (2026-09-06 21:43 UTC)
5
29 npm
MIT
fec-mcp
bsilha
F
license
Not graded
quality
B
maintenance
An MCP server that searches official FEC PDF rulebooks for compliance and contribution limits, and provides real-time lookups against the OpenFEC API for candidates, committees, filings, and financial data.
Updated 20 days ago (2026-08-27 19:45 UTC)
-

South Korean Election MCP (kr-elections-mcp)

What It Provides

Quick Start

1. Install the CLI

2. Apply for NEC API access

3. Store the key securely

4. Run the MCP server

MCP Client Example

API Key Storage Rules

Source Checkout Fallback

Tools

krpoltext Text Support

Resources

Documentation

How to Cite

Testing

Limitations

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`krpoltext` Text Support