The narajangteo-pro server integrates 6 Korean public procurement (나라장터) APIs, enabling natural language-driven search, market analysis, competitor research, and bid evaluation through 8 MCP tools.
search_procurement — Unified search across 5 domains (bid announcements, award results, contracts, procurement requests, shopping mall items) with keyword, institution, period, and business type filtering. Supports natural language date/amount expressions.
get_procurement_detail — Retrieve full details for a specific bid notice, award result, contract, procurement request, or shopping item using its ID.
trace_procurement_lifecycle — Track an entire procurement process from pre-specification → announcement → award → contract in a single call using one identifier.
analyze_market — Keyword-based market analysis covering monthly trends, average award rates, top institutions/companies, and estimated market size.
analyze_competitor — Analyze a specific company's procurement activity: award counts/amounts, key business areas, average award rates, and client patterns.
score_bid_fit — Score bid suitability (0–100) by matching a company's licenses, certifications, revenue, and prior contracts against bid requirements. Accepts saved or inline profiles.
manage_watchlist — Monitor procurement opportunities by adding/removing keywords, listing watched terms, and checking for new bid notices since the last check.
manage_company_profile — Save, load, list, or delete company profiles (licenses, certifications, revenue, contracts) for reuse in bid fit evaluations, with natural language revenue input (e.g., '50억').
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@narajangteo-pro Search for recent IT procurement notices"
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.
This is an MCP server that integrates 6 types of KONEPS (Korea ON-line E-Procurement System) public procurement APIs. You can connect it to MCP clients like Claude Desktop to perform tasks such as searching for bid notices, analyzing the market, and evaluating bid suitability using natural language.
We have integrated major KONEPS public APIs to allow for the retrieval of various data.
Bid Notices: Search for notices by keyword, organization, and period.
Bid Results: Retrieve information on winning bidders and amounts.
Contract Information: Verify actual contract execution details.
Integrated Contract Process Disclosure: Track the entire process from pre-specifications to contracts.
Procurement Requests: Retrieve data from the pre-ordering stage.
Comprehensive Shopping Mall Items: Search for items registered under unit price contracts.
The common API client (api/client.py) handles the following functions:
Normalization of response formats
Automatic retries on request timeouts (up to 2 times)
Memory caching (default 5 minutes)
Configured as functional tools for efficient use in LLM environments.
Tool Name | Description |
| Integrated search for bids / results / contracts / requests / shopping mall |
| Retrieve detailed information |
| Track procurement progress stages |
| Keyword-based market trend analysis |
| Analyze procurement activities of a specific company |
| Analyze bid suitability based on company information |
| Register keywords of interest and check for new notices |
| Save / load company profiles |
Implemented to automatically convert user input in everyday language into API parameters.
Period Expressions — last 7 days / past 3 months / this year
Amount Expressions — 500 million / 150 million / 30 million won
Work Category Synonyms — service → service / construction → construction work
Stores user configuration data based on SQLite. Saved items include Watchlist and company profiles; the default storage location is as follows.
~/.narajangteo-pro/state.dbRelated MCP server: mcp-kr-g2b
After applying for the services below at the Public Data Portal, copy the Decoding value of the ServiceKey from My Page → Development Account.
Public Procurement Service_KONEPS Bid Notice Information Service
Public Procurement Service_KONEPS Bid Result Information Service
Public Procurement Service_KONEPS Contract Information Service
Public Procurement Service_KONEPS Integrated Contract Process Disclosure Service
# uvx (권장 — Python 설치 없이 실행)
uvx narajangteo-pro
# npx
npx narajangteo-pro
# pip
pip install narajangteo-pro
narajangteo-proModify the configuration file at the following path:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"narajangteo-pro": {
"command": "uvx",
"args": ["narajangteo-pro@latest"],
"env": {
"NARA_API_KEY": "발급받은_디코딩_서비스키"
}
}
}
}You can use it immediately after restarting Claude Desktop.
"Analyze the market for AI chatbots over the last month"
"Show me the entire progress from pre-specification to contract for notice number 20260415123"
"Evaluate whether we should bid on this notice based on our company profile"
┌─────────────────────────────────────┐
│ Claude Desktop / Cursor / VS Code │
└──────────────────┬──────────────────┘
│ MCP (stdio | HTTP)
┌──────────────────▼──────────────────┐
│ narajangteo-pro │
│ ┌────────┐ ┌──────────┐ ┌──────┐ │
│ │ Tools │→ │Analytics │→ │ DB │ │
│ └───┬────┘ └────┬─────┘ └──────┘ │
│ └────────────┘ │
│ ┌──────────┐ │
│ │API Client│ │
│ └────┬─────┘ │
└──────────────┼──────────────────────┘
│
┌─────────▼──────────┐
│ 공공데이터포털 │
│ 나라장터 API 6종 │
└────────────────────┘MIT
특정 기업의 조달시장 활동 분석.
낙찰 건수/금액, 주력 분야, 평균 낙찰가율, 거래 발주기관 패턴을 분석.
Args: company_name: 기업명 (정확하지 않아도 부분 일치) period_months: 분석 기간 business_type: 업무구분 또는 'all'
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | Yes | ||
| period_months | No | ||
| business_type | No | all |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It indicates a read-only analysis (no mutation implied), but does not explicitly state side effects, permissions, or rate limits. Partially transparent but could be clearer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with the main purpose. The Args section is a bit repetitive but functional. No unnecessary words, though structure could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description lists the analytical aspects (bid counts, etc.) which gives agent expectation of output content. Parameter documentation covers all three parameters. Lacks output format details but sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds useful parameter semantics: company_name accepts partial matches, period_months is analysis period, business_type has default 'all'. This adds meaningful context beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a specific company's procurement market activity, listing specific metrics (bid counts/amounts, core sectors, average win rate, buyer patterns). This distinguishes it from siblings like analyze_market (market-level) and score_bid_fit (bid fit scoring).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Missing context on prerequisites, limitations, or typical use cases. The Args section lists parameters but does not explain the context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
특정 분야 시장 동향 분석.
낙찰 데이터를 집계하여 월별 추이, 평균 낙찰가율, 상위 발주기관/낙찰업체, 추정 시장 규모를 반환.
Args: keyword: 분석 대상 키워드 (예: 'AI 챗봇', '클라우드') period_months: 분석 기간 — 기본 12개월 business_type: 업무구분 또는 'all' (4개 합산)
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | ||
| period_months | No | ||
| business_type | No | 용역 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It describes the expected outputs (e.g., monthly trends, top organizations) but does not mention any critical behavioral aspects such as data source freshness, authentication requirements, rate limits, or absence handling. The presence of an output schema partially compensates, but the description lacks deeper 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence followed by a bulleted list of outputs and an Args section. It is front-loaded and every sentence adds value. Minor redundancy could be trimmed, but overall it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 parameters, 1 required) and presence of an output schema, the description covers the parameter semantics and output briefly. However, it lacks usage guidelines and behavioral details, which leaves some completeness gaps. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds essential meaning. Each parameter is explained: 'keyword' is the analysis keyword with examples ('AI 챗봇', '클라우드'); 'period_months' is described as the analysis period with a default of 12 months; 'business_type' is explained as a business type or 'all' summing 4 types. This goes far beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('분석') and resource (시장 동향, market trends). It lists concrete outputs (monthly trends, average bid ratio, etc.), making it easy to understand. It also distinguishes from siblings like 'analyze_competitor', which focuses on competitors rather than market trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus its siblings, nor does it mention any prerequisites or limitations. It only describes what the tool does, leaving the agent to infer usage from context. No 'when-not' or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
입찰공고/낙찰/계약/조달요청/쇼핑몰품목 상세 정보 조회.
Args: domain: 'bid'(입찰공고), 'award'(낙찰), 'contract'(계약), 'request'(조달요청), 'shopping'(종합쇼핑몰 품목) notice_no: 식별 번호 - bid/award: 입찰공고번호 - contract: 확정계약번호 - request: 조달요청번호 - shopping: 품목식별번호 business_type: 업무구분 (shopping은 무시) notice_ord: 공고차수 (보통 '00')
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| notice_no | Yes | ||
| business_type | No | 용역 | |
| notice_ord | No | 00 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only describes input mapping and does not mention idempotency, side effects, authentication needs, or rate limits. The phrase 'detailed information retrieval' implies read-only but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose and a structured Args block. Every sentence adds value, and the Korean/English bilingual presentation is efficient for the target audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (no need to describe return values), the description covers parameter domain mapping and usage. It lacks explanation of error handling or edge cases, but for a detailed retrieval tool with moderate complexity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds significant value by explaining each parameter's meaning (domain enumeration with Korean labels, notice_no mapping across domains, business_type context, notice_ord default). However, business_type possible values are not fully enumerated, and notice_ord format is vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed information for various procurement domains (bid, award, contract, request, shopping). It distinguishes from siblings like search_procurement and trace_procurement_lifecycle by focusing on single item details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameter usage but does not explicitly state when to use this tool versus alternatives. Usage is implied from context (e.g., search vs detail retrieval), but no when-not or alternative references provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
회사 프로필 관리 — 적합도 평가에 재사용.
actions: - 'save': 저장 (profile_id, name 필수). 같은 ID면 업데이트. - 'load': 조회 (profile_id 필수) - 'list': 모든 프로필 목록 - 'delete': 삭제 (profile_id 필수)
revenue는 자연어 표현 가능: '50억', '100억원' 등.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| profile_id | No | ||
| name | No | ||
| licenses | No | ||
| certifications | No | ||
| revenue | No | ||
| prior_contracts | No | ||
| notes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description explains update behavior for save (same ID updates) and revenue format (natural language). Lacks details on authentication, error handling, or idempotency for delete/list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with action list and revenue note. Concise with minimal fluff. Could be slightly more condensed but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values not needed. Covers basic usage but lacks details on list output format, error cases, or edge conditions for a CRUD tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description explains action enum, profile_id/name requirement for save, and revenue format. But other params (licenses, certifications, prior_contracts, notes) are undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it manages company profiles for suitability evaluation, listing actions (save, load, list, delete). Distinct from sibling tools like analyze_competitor or score_bid_fit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Context is clear: used for company profile CRUD in evaluation. Action list with required parameters guides usage, but no explicit when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
관심 키워드 모니터링.
actions: - 'add': 새 키워드 등록 (keyword 필수) - 'remove': 등록 해제 (watch_id 필수) - 'list': 등록된 키워드 목록 - 'check_new': 등록한 키워드의 신규 공고 (마지막 확인 이후)
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| keyword | No | ||
| business_type | No | ||
| institution | No | ||
| watch_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does not disclose side effects (e.g., whether adding or removing is destructive), access requirements, rate limits, or what 'check_new' returns. Only bare action descriptions are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (3 lines plus bullet list). It front-loads the main purpose and lists actions cleanly. However, it could be more structured (e.g., parameter descriptions in a table) and the Korean language may limit universal clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 5 parameters and an output schema. The description covers the overall purpose and action-specific parameter requirements but misses some parameters. With no annotations, more detail on behavior and return values would improve completeness. The output schema may compensate for return values, so score is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only two parameters (keyword, watch_id) are mentioned in context of specific actions, but business_type and institution are omitted despite being in the schema. With 0% schema description coverage, the description should explain all parameters; it fails to do so, leaving ambiguity about the role of business_type and institution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Title is missing but description states 'keyword monitoring' and lists four specific actions (add, remove, list, check_new). The name 'manage_watchlist' together with the actions makes the tool's purpose unambiguous. It is clearly distinct from sibling tools like analyze_competitor or search_procurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description lists actions but does not provide context such as 'use this to manage keywords, use search_procurement to find announcements' or when to prefer one action over another. Implicit usage is derived only from action names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
입찰 적합도 평가 — 0-100 점수 + 권고.
회사 프로필(보유 면허, 매출, 실적)과 공고 요구사항을 매칭해 적합도를 산출.
Args: bid_notice_no: 입찰공고번호 business_type: 업무구분 profile_id: 저장된 회사 프로필 ID (manage_company_profile로 미리 저장) inline_profile: 즉석 프로필 dict (저장 없이 일회성 평가) {"licenses": [...], "certifications": [...], "revenue": int, "prior_contracts": [...]} notice_ord: 공고차수
| Name | Required | Description | Default |
|---|---|---|---|
| bid_notice_no | Yes | ||
| business_type | No | 용역 | |
| profile_id | No | ||
| inline_profile | No | ||
| notice_ord | No | 00 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the return type (score + recommendation) but does not state whether the tool is read-only, has side effects, or requires specific permissions. The absence of contradictions is noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line purpose statement followed by a clean parameter list. Every sentence adds value, no redundancy. The structure is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema (implied by mentioning score), the description covers purpose, all parameters, and return value. It also references a sibling tool (manage_company_profile) for context. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for all 5 parameters, including the structure of inline_profile (dict with licenses, certifications, revenue, prior_contracts) and the relationship between profile_id and manage_company_profile. This adds significant meaning beyond the schema's titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates bid fit by matching company profile (licenses, revenue, performance) with notice requirements and outputs a 0-100 score plus recommendation. This specific verb-resource combination distinguishes it from siblings like analyze_competitor or manage_company_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a company profile and bid notice are available, and explicitly mentions that profile_id is stored via manage_company_profile, indicating a prerequisite. However, it does not explicitly state when not to use or compare to alternatives like analyze_competitor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
나라장터 통합 검색 도구.
하나의 도구로 5개 영역을 모두 검색한다.
Args: domain: 검색 영역 - 'bid': 입찰공고 - 'award': 낙찰결과 - 'contract': 체결된 계약 - 'request': 조달요청 (발주의 가장 이른 단계 — 영업 선행지표) - 'shopping': 종합쇼핑몰 품목 (단가계약 등록 품목) business_type: 업무구분 — '물품', '용역', '공사', '외자' (자연어 표현 자동 매핑) 'shopping' 도메인은 이 파라미터를 무시. keyword: 공고명/품목명 키워드 institution: 발주기관/계약기관명 (shopping에선 공급업체명으로 사용) period: 자연어 기간 — '최근 7일', '지난 3개월', '올해' 등 (date_from/to보다 우선) date_from: 시작일 YYYYMMDD date_to: 종료일 YYYYMMDD limit: 최대 결과 수 (1-100)
Returns: {"items": [...], "total_count": int, "page_no": int}
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | bid | |
| business_type | No | 용역 | |
| keyword | No | ||
| institution | No | ||
| period | No | ||
| date_from | No | ||
| date_to | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses parameter interactions (period overrides date_from/to, shopping ignores business_type) and return format (items, total_count, page_no). Minor omission: no mention of read-only vs destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with sections and bullet-pointed parameters, making it scannable. However, the parameter explanations are somewhat verbose; some could be shortened without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and an output schema, the description covers all necessary aspects: domain behavior, parameter interactions, return values, and limits. Complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It does so thoroughly, explaining each parameter, including enum values for domain, natural language processing for business_type, and default behavior for period. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it's a unified search tool for 5 areas (bid, award, contract, request, shopping) of the Korean procurement system, with clear definitions. This distinguishes it from sibling tools like get_procurement_detail or trace_procurement_lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear domain-specific usage notes (e.g., 'shopping' ignores business_type; 'request' is the earliest stage). However, it does not explicitly state when to use this tool versus alternatives, though sibling tool names give context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⭐ 조달 전 과정 추적 — 사전규격 → 공고 → 낙찰 → 계약을 한 번에.
이 도구가 narajangteo-pro의 시그니처 기능. 식별자 하나만 알면 조달 라이프사이클 전체를 추적해 타임라인으로 반환한다.
Args: id_value: 식별 번호 business_type: 업무구분 id_type: 식별자 종류 - 'bid_notice': 입찰공고번호 (가장 흔함) - 'spec': 사전규격등록번호 - 'plan': 발주계획번호 - 'request': 조달요청번호
| Name | Required | Description | Default |
|---|---|---|---|
| id_value | Yes | ||
| business_type | No | 용역 | |
| id_type | No | bid_notice |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it returns a timeline and is read-only based on context, but does not disclose side effects, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in Korean followed by Args list. Front-loaded with purpose and value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Description explains all parameters and basic behavior. Lacks error handling or edge case details, but sufficient for standard use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions coverage is 0%, but description adds meaning by explaining id_type enum values and naming the parameters. Could further elaborate on id_value format and business_type options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it traces the entire procurement lifecycle from pre-spec to contract, returning a timeline. It distinguishes itself from siblings like search_procurement, get_procurement_detail, etc., which are for specific aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use comparisons with siblings. The description implies it's for full lifecycle tracing, but lacks direct guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_competitoranalyze_marketget_procurement_detailmanage_company_profilemanage_watchlistscore_bid_fitsearch_procurementtrace_procurement_lifecycleScored across 8 tools
Each tool has a clearly distinct purpose: analysis per company or market, detail retrieval, profile/watchlist management, fit scoring, search, and lifecycle tracing. No two tools overlap significantly.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., analyze_competitor, manage_watchlist. No mixing of camelCase or other conventions.
8 tools is ideal for this domain, covering search, detail, analysis, management, scoring, and tracing without being too few or too many.
Covers core procurement activities well, but lacks a direct tool for comparing bids or exporting reports. The analysis tools provide aggregated data, mitigating minor gaps.
Access Korea’s G2B procurement and Nara Market data for bid notices, awards, contracts, statistics…
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
EU tenders and grant calls, matched to your company and qualified, inside the AI you already use
