Skip to main content
Glama
deenesjakoruzh
OldTemple91

koreafilings-mcp

by OldTemple91
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Korea Filings

PyPI PyPI MCP License x402

한국 기업 공시(DART · 전자공시)에 대한 기계 판독 가능한 영어 요약본을 제공하며, Base 네트워크의 x402 프로토콜을 통해 호출당 USDC로 결제합니다. 한국어 PDF를 읽지 않고도 한국 시장 이벤트에 프로그래밍 방식으로 접근해야 하는 AI 에이전트, 퀀트 펀드 및 연구 플랫폼을 위해 구축되었습니다.

라이브: https://koreafilings.com · API: https://api.koreafilings.com · 대화형 문서: /swagger-ui.

기능

원시 DART 데이터는 무료이지만 한국어로 되어 있고 LLM이 아닌 인간 공시 담당자를 위해 구조화되어 있습니다. Korea Filings는 모든 공시를 에이전트가 한 번의 호출로 소비할 수 있는 구조화되고 캐시된 영어 요약 JSON 페이로드로 변환합니다:

{
  "rcptNo": "20260424900874",
  "summaryEn": "Global SM's stock trading was temporarily suspended on April 24, 2026, due to a change in electronic registration related to a stock consolidation or split.",
  "importanceScore": 10,
  "eventType": "SINGLE_STOCK_TRADING_SUSPENSION",
  "sectorTags": ["Capital Goods"],
  "tickerTags": ["095440"],
  "actionableFor": ["traders", "long_term_investors"],
  "generatedAt": "2026-04-24T08:47:51Z"
}

캐시가 핵심 경쟁력입니다. 공시를 처음 요청하는 에이전트가 LLM 실행 비용을 지불하면, 동일한 rcpt_no에 대해 이후 요청하는 모든 에이전트는 거의 비용이 들지 않는 DB 조회만 수행하며 동일한 고정 수수료를 지불합니다. 채택이 늘어날수록 마진이 복리로 증가합니다.

Related MCP server: DART 공시 브리핑 MCP 서버

사용 방법

스택에 맞는 인터페이스를 선택하세요. 세 가지 모두 내부적으로 동일한 x402 흐름을 사용합니다. X-PAYMENT 헤더에 서명하는 지갑이 곧 신원입니다. API 키도, 가입 절차도 없습니다.

Python SDK

pip install koreafilings
from koreafilings import Client

with Client(private_key="0x...", network="base-sepolia") as client:
    summary = client.get_summary("20260424900874")

    print(f"[{summary.importance_score}/10] {summary.event_type}")
    print(summary.summary_en)
    print("paid:", client.last_settlement.tx_hash)

MCP 서버 (Claude Desktop, Cursor, Continue 등)

uv tool install koreafilings-mcp

MCP 클라이언트 설정:

{
  "mcpServers": {
    "koreafilings": {
      "command": "uv",
      "args": ["tool", "run", "koreafilings-mcp"],
      "env": {
        "KOREAFILINGS_PRIVATE_KEY": "0x...",
        "KOREAFILINGS_NETWORK": "base-sepolia"
      }
    }
  }
}

두 가지 도구를 사용할 수 있습니다:

  • get_pricing — 무료; 라이브 지갑, 네트워크, USDC 컨트랙트 및 엔드포인트별 가격을 반환합니다.

  • get_disclosure_summary(rcpt_no) — 유료; 구조화된 요약과 온체인 결제 트랜잭션 해시를 반환합니다.

curl / 직접 HTTP

# 1) Probe the endpoint without payment to discover the requirements.
curl -i https://api.koreafilings.com/v1/disclosures/20260424900874/summary
#   HTTP/2 402
#   payment-required: <base64 PaymentRequired payload>
#   { "x402Version": 2, "accepts": [{ "scheme": "exact", ... }], ... }

# 2) Sign an EIP-3009 TransferWithAuthorization for one of the entries
#    in `accepts`, base64-encode the signed PaymentPayload, and resend
#    with the X-PAYMENT header. See testclient/payer.py for a 90-line
#    reference implementation.
curl -H "X-PAYMENT: $SIGNED" \
     https://api.koreafilings.com/v1/disclosures/20260424900874/summary
#   HTTP/2 200
#   x-payment-response: <base64 SettlementResponse with tx hash>
#   { "rcptNo": "...", "summaryEn": "...", ... }

가격

엔드포인트

메서드

가격 (USDC)

/v1/disclosures/{rcptNo}/summary

GET

0.005

기계 판독 가능한 전체 가격 설명자(현재 지갑, 네트워크, USDC 컨트랙트, 모든 유료 엔드포인트)는 /v1/pricing에서 확인할 수 있습니다.

현재 Base Sepolia 테스트넷에서 운영 중입니다. 테스트넷 USDC는 Circle 수도꼭지에서 무료로 받을 수 있으므로 누구나 실제 돈을 쓰지 않고도 서비스를 처음부터 끝까지 테스트해 볼 수 있습니다. 메인넷 코드 경로(Ed25519 JWT 인증을 사용하는 Coinbase CDP 촉진자)는 연결 및 단위 테스트가 완료되었으며, 첫 번째 유료 고객이 관심을 보이면 환경 변수 하나만 변경하여 전환할 수 있습니다.

아키텍처

세 개의 논리적 하위 시스템이 하나의 Spring Boot 애플리케이션을 공유합니다:

  1. 수집(Ingestion) — DART Open API에 대해 30초 단위 폴링을 예약하고, rcpt_no로 중복을 제거하며, 원시 메타데이터를 Postgres에 저장하고 요약 작업을 큐에 넣습니다.

  2. 요약(Summarisation) — 요약 작업을 소비하고 복잡도를 분류한 뒤 Gemini 2.5 Flash-Lite(Resilience4j 속도 제한 + 서킷 브레이커 + 재시도 포함)로 라우팅하며, 영어 요약 + 티커/섹터 태그 + 감사 행을 llm_audit에 저장합니다.

  3. 유료 API(Paid API) — X402PaywallInterceptor 뒤에 있는 Spring MVC 컨트롤러입니다. 모든 요청에 대해 X-PAYMENT를 확인하고, 촉진자를 통해 서명을 검증하며, Redis에서 재전송을 확인하고, 200 응답 시 결제하며, ResponseBodyAdvice를 통해 온체인 트랜잭션 해시가 포함된 X-PAYMENT-RESPONSE를 첨부합니다. 인터셉터는 @X402Paywall이 없는 핸들러 메서드에 대해서는 우회하므로 /v1/pricing, /.well-known/x402 및 OpenAPI 문서는 인증 없이 유지됩니다.

402 챌린지는 x402 v2 전송 사양을 따릅니다. PAYMENT-REQUIRED 헤더는 base64로 인코딩된 PaymentRequired 페이로드를 전달하며(AI 에이전트 검색 가능성을 위한 bazaar 확장 포함), 본문은 이전 클라이언트가 계속 작동하도록 v1 호환 JSON 복사본을 유지합니다.

스택: Java 21, Spring Boot 3.4, PostgreSQL 16, Redis 7, Docker Compose, Cloudflare Tunnel, Cloudflare Workers, Hetzner CAX11. 자세한 내용은 docs/ARCHITECTURE.md를 참조하세요.

저장소 레이아웃

.
├── src/                  # Spring Boot application source
├── sdk/python/           # `koreafilings` Python SDK (PyPI)
├── mcp/                  # `koreafilings-mcp` MCP server (PyPI)
├── landing/              # Marketing landing page (Cloudflare Workers)
├── testclient/           # Reference Python x402 client (testnet payer)
├── docs/
│   ├── ARCHITECTURE.md   # System design
│   ├── PRD.md            # Product requirements
│   ├── ROADMAP.md        # Six-week launch plan
│   └── STATUS.md         # Operator handoff notes
├── Dockerfile            # Multi-stage prod build (eclipse-temurin:21)
├── docker-compose.yml    # postgres + redis + app + cloudflared
└── build.gradle.kts      # Gradle (Kotlin DSL)

로컬 개발

git clone https://github.com/OldTemple91/korea-filings-api.git
cd korea-filings-api

cp .env.example .env
# Fill in:
#   POSTGRES_PASSWORD     (any strong password)
#   DART_API_KEY          (free, register at https://opendart.fss.or.kr/)
#   GEMINI_API_KEY        (free tier, https://aistudio.google.com/apikey)
#   X402_RECIPIENT_ADDRESS (your receiving wallet — only the address)

docker compose up -d postgres redis
./gradlew bootRun

로컬 인스턴스에 대해 실제 x402 결제를 수행하려면 testclient/.env.testclient.example을 testclient/.env.testclient로 복사하고, Base Sepolia 지갑의 개인 키( Circle 수도꼭지에서 자금을 지원받은 새 지갑이 안전함)를 입력한 후 python testclient/payer.py를 실행하세요.

상태

Base Sepolia에서 라이브 운영 중, MVP 기능 세트:

  • DART 실시간 수집 (30초 폴링)

  • 중요도 점수 + 섹터/티커 태그 지정이 포함된 Gemini 2.5 Flash-Lite 요약

  • 에이전트 검색 가능 호출을 위한 bazaar 확장이 포함된 x402 v2 페이월

  • /.well-known/x402를 통한 검색

  • /v3/api-docs의 OpenAPI 3 사양 + 대화형 Swagger UI

  • PyPI에 게시된 Python SDK 및 MCP 서버

  • x402scan에 인덱싱됨

  • Cloudflare Tunnel을 통한 Hetzner 프로덕션 배포

다음 예정:

  • Base 메인넷 전환 (CDP 촉진자 코드는 이미 연결 및 단위 테스트 완료)

  • 추가 유료 엔드포인트: /disclosures/latest, /by-ticker/{ticker}, POST /filter, SSE /stream, /impact

  • TypeScript SDK

  • 한국어 랜딩 페이지

전체 계획은 docs/ROADMAP.md를 참조하세요.

기여

이슈와 PR을 환영합니다. 특히 다음 분야를 환영합니다:

  • Python SDK의 다른 언어 포팅 (TypeScript, Go, Rust)

  • 추가 분석 엔드포인트 (가격 반응, 비교 공시 등)

  • 비 x402 에이전트 프레임워크와의 통합

  • 랜딩 페이지의 다국어 번역

중요한 변경 사항의 경우, 구축하기 전에 적합성을 검토할 수 있도록 먼저 방향을 설명하는 이슈를 열어주세요.

라이선스

MIT.

Available Tools

5 tools
find_companyA

Search the KRX directory of Korean listed companies. Free.

Use this as the first step when you have a company name (English
or Korean) but not the six-digit KRX ticker. Pass the resulting
ticker to ``get_recent_filings`` (paid) or ``get_disclosure_summary``
(paid, when you also have a specific receipt number).

Args:
    query: Company name (English or Korean) or six-digit ticker.
        Examples: "Samsung Electronics", "삼성전자", "005930".
    limit: Max matches to return (1-50, default 20).

Returns:
    A list of company dicts with ``ticker``, ``corp_code``,
    ``name_kr``, ``name_en``, and ``market`` (KOSPI / KOSDAQ).
    Empty list when nothing matches; never raises on no-results.
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses it is free, returns a list of dicts, and states behavior on no results ('Empty list... never raises'). Does not mention side effects but no issues expected.

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?

Description is concise with organized sections (intro, usage link, Args, Returns). Every sentence adds value without redundancy.

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 simple tool (2 params, no enums, has output schema), description covers purpose, usage, params, return format, and edge case (empty list). No gaps for the agent.

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

Parameters5/5

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

Schema coverage is 0%, but description adds examples for query (English, Korean, ticker) and specifies limit range (1-50, default 20), providing crucial context beyond schema.

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 clearly states the tool searches the KRX directory for Korean listed companies, specifies the use case (getting a ticker from a company name), and distinguishes from siblings by mentioning passing to get_recent_filings or get_disclosure_summary.

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?

Explicitly says 'Use this as the first step when you have a company name... but not the six-digit KRX ticker.' and provides follow-up usage, though does not explicitly state when not to use it.

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

get_disclosure_summaryA

Fetch the AI-generated English summary of a Korean DART disclosure.

**This tool spends real USDC from the configured wallet** — 0.005
USDC per call as of v0.1, settled on-chain via x402. The wallet
pays only on a successful 200 response; 4xx/5xx failures do not
settle.

Args:
    rcpt_no: 14-digit DART receipt number, e.g. ``"20260424900874"``.
        You can discover receipt numbers from the DART portal at
        https://dart.fss.or.kr/ or from koreafilings.com's listing
        endpoints as they come online.

Returns:
    A dict with the summary content (``summary_en``), operational
    metadata (``importance_score`` 1–10, ``event_type``,
    ``ticker_tags``, ``sector_tags``, ``actionable_for``,
    ``generated_at``), and payment proof (``paid_tx``, ``network``,
    ``payer``). If the server served from its free-tier path the
    payment block is absent.

Raises:
    RuntimeError: when the SDK rejects the request. The message
        distinguishes payment failures (facilitator rejection,
        network mismatch, insufficient balance) from other API
        errors (404 unknown rcpt_no, 429 rate limit, 5xx upstream).
ParametersJSON Schema
NameRequiredDescriptionDefault
rcpt_noYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully discloses the real USDC cost, settlement conditions, error handling, and return value structure including payment proof. This exceeds expectations for transparency.

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 well-structured with sections and front-loaded with purpose and cost warning. It is somewhat lengthy but every sentence serves a clear purpose, earning a 4.

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 one parameter and an output schema, the description covers input, output structure, errors, cost, and use case. It is complete and leaves no gaps for the agent.

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

Parameters5/5

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

The single parameter rcpt_no is documented with a 14-digit format, an example, and sources for discovery. Schema description coverage is 0%, but the description compensates fully, adding significant meaning.

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 clearly states the tool fetches an AI-generated English summary of a Korean DART disclosure. It specifies the resource (disclosure summary) and action (fetch), and is distinct from sibling tools like find_company or get_pricing.

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?

The description explains when to use (need a summary), provides cost and failure details, and tells how to discover receipt numbers. It lacks explicit when-not or alternative tools, but the context is sufficiently clear.

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

get_pricingA

Fetch the current per-endpoint pricing for koreafilings.com.

This is a free call; it returns the x402 wallet address, network, USDC contract, and the price in USDC for each paid endpoint. Useful to confirm the payer will be settling on the expected chain before spending anything.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the call is free and returns specific fields (x402 wallet address, network, USDC contract, price in USDC). This gives good behavioral context, though it doesn't mention authentication or rate limits, which are likely unnecessary for a free, parameterless call.

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?

Three sentences with no wasted words. First sentence states purpose, second details output, third gives usage guidance. It is appropriately sized and front-loaded.

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 zero parameters and the existence of an output schema (though not shown), the description mentions what the call returns and explains when to use it. It covers the necessary context for a simple 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?

There are no parameters, and schema coverage is 100%, so baseline is 4. The description adds no extra parameter info because none exist, but that's appropriate.

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?

Description clearly states the tool fetches current per-endpoint pricing for koreafilings.com. The verb 'Fetch' and resource 'current per-endpoint pricing' are specific. Sibling tools are about filings and disclosures, so this tool is distinct.

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?

Description explicitly notes it's a free call and useful for confirming the payer will settle on the expected chain before spending. This implies when to use it, though it doesn't provide explicit exclusions or alternatives. Nevertheless, the context is clear.

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

get_recent_filingsA

Fetch up to limit AI summaries for one Korean ticker.

**This tool spends real USDC from the configured wallet** — 0.005
USDC × ``limit`` per call (default 0.025 USDC). The wallet pays
only on a successful 200 response; 4xx/5xx failures do not settle.

If you only have a company name, call ``find_company`` first to
resolve the ticker.

Args:
    ticker: Six-digit KRX ticker, e.g. "005930" for Samsung Electronics.
    limit: Max filings to fetch (1-50, default 5). Each costs 0.005 USDC.

Returns:
    A dict with ``ticker``, ``count``, ``summaries`` (each summary
    carries the same shape as ``get_disclosure_summary``), and a
    ``payment`` block with the on-chain settlement tx hash.

Raises:
    RuntimeError: on payment rejection or API failure.
ParametersJSON Schema
NameRequiredDescriptionDefault
tickerYes
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description fully carries the burden, disclosing real USDC cost (0.005 per filing), payment on success only, return structure including payment tx hash, and RuntimeError on failure.

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?

Every sentence is purposeful: purpose, cost warning, usage hint, parameter descriptions, return shape, error handling. No redundancy or fluff.

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 tool's complexity (paid API with cost, two parameters, custom return), the description covers behavior, cost, error handling, and return shape comprehensively, despite no annotations or rich output schema in prompt.

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

Parameters5/5

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

Despite 0% schema description coverage, the description adds crucial details: ticker format with example, limit range (1-50) and default, and cost per unit, far exceeding schema's plain type info.

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 clearly states the verb 'Fetch' and resource 'AI summaries for one Korean ticker', distinguishing it from siblings like find_company (resolves name to ticker) and list_recent_filings (likely just lists without costs).

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?

Explicitly advises to call find_company if only a company name is available, providing an alternative. No explicit when-not, but the cost implication implicitly guides against overuse.

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

list_recent_filingsA

Browse recent DART filings across every listed Korean company. Free.

Returns metadata only — no AI summaries — so an agent can decide
which filings warrant a paid call. Each entry includes ``rcpt_no``
(for ``get_disclosure_summary``) and ``ticker`` (for
``get_recent_filings``).

Args:
    limit: Max filings to return (1-100, default 20).
    since_hours: Look back this many hours (1-168, default 24).

Returns:
    A list of filing-metadata dicts.
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
since_hoursNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It states 'Returns metadata only' implying read-only behavior and mentions 'Free', but it does not explicitly confirm safety, idempotency, or authentication requirements. The description is mostly adequate but lacks explicit transparency on side effects.

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 concise (6 sentences), well-structured with clear sections (purpose, return type, args, returns), and front-loads the primary purpose. Every sentence earns its place, with no fluff.

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 tool's simplicity (2 optional parameters) and the presence of an output schema, the description is adequately complete. It covers metadata-only return and cross-references other tools, providing sufficient context for an agent to use this tool correctly.

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

Parameters5/5

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

The description fully documents both parameters (limit and since_hours) with ranges and defaults, compensating for 0% schema description coverage. This adds meaning beyond the bare input schema, enabling precise agent decisions.

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 clearly states that the tool browses recent DART filings for Korean companies and returns metadata only. However, it does not differentiate itself from the sibling tool 'get_recent_filings', which has a similar name and purpose, creating potential ambiguity.

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?

The description hints at a usage flow by referencing get_disclosure_summary for paid calls, but it does not explicitly state when to use this tool versus alternatives like get_recent_filings. It provides some context without clear when-to-use or when-not-to-use guidance.

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.

  1. 3 tool updatesv0.1.1
    • Addedfind_company
    • Addedget_recent_filings
    • Addedlist_recent_filings
  2. 2 tool updatesv0.1.0
    • First observedget_disclosure_summary
    • First observedget_pricing
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

A4.5/5.0

Scored across 5 tools

Disambiguation4/5

Each tool has a broadly distinct role: pricing lookup, company search, free filing metadata browsing, paid ticker-based summaries, and paid receipt-based summary retrieval. The main confusion risk is between list_recent_filings and get_recent_filings, whose names are very similar though their descriptions clearly separate free metadata browsing from paid AI summary generation.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: get_pricing, find_company, list_recent_filings, get_recent_filings, get_disclosure_summary. The verbs are standard retrieval actions and the naming is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for this server: pricing discovery, company resolution, free filing browsing, and two paid summary-fetching operations. Each tool earns its place and the server avoids unnecessary bloat.

Completeness4/5

The core workflow is covered: resolve a company with find_company, browse recent filings for free with list_recent_filings, then fetch paid AI summaries by ticker or receipt number. Minor gaps exist such as no historical filing lookup beyond recent limits and no raw disclosure document access, but these do not break the primary use case.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • kr-crypto-intelligence

    bakyang2
    A
    license
    A
    quality
    C
    maintenance
    Korean crypto market data API for AI agents. Real-time Kimchi Premium (Upbit vs Binance), Korean exchange prices, USD/KRW FX rate. First verified Korean market data MCP server. Pay-per-use via x402 on Base.
    17
    2
    MIT

  • Disclosure Compass

    MLOpsEngineer
    A
    license
    Not graded
    quality
    C
    maintenance
    A Model Context Protocol server that exposes seven read-only tools for querying Korean public company disclosures from the OpenDART system, returning normalized JSON.
    MIT

  • OpenDart MCP Server

    sayouzone
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that retrieves Korean stock fundamentals and financial data from OpenDART, enabling LLMs to access corporate disclosures, financial statements, and dividend information.
    Apache 2.0