Skip to main content
Glama
opendata-kr

@opendata-kr/narajangteo-bid-mcp

Official
by opendata-kr

공고 변경이력 조회

get_bid_change_history
Read-only

Retrieve bid notice change history by bid notice number. Shows corrected items with before and after values for goods, construction, and services categories.

Instructions

입찰공고번호로 공고의 변경이력(정정·변경 항목, 변경 전/후 값)을 조회한다. 공고 내용이 사후에 어떻게 바뀌었는지 확인할 때 쓴다. 기초금액은 get_bid_basis_amount, 참가자격은 get_bid_eligibility를 쓴다. 변경이력은 물품·공사·용역 3구분만 존재하며(외자·기타 없음), bidKind 지정 시 해당 구분만, 미지정 시 3구분을 병렬 조회한다. 변경 이력이 없는 공고는 빈 결과를 반환한다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bidKindNo업무구분(thng=물품, cnstwk=공사, servc=용역). 변경이력은 이 3구분만. 미지정 시 3구분 병렬
bidNtceNoYes입찰공고번호 (예: R25BK00932003). 이 도구는 공고의 변경이력(정정·변경 항목)을 반환. 기초금액은 get_bid_basis_amount, 참가자격은 get_bid_eligibility로 조회
Behavior5/5

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

Annotations provide readOnlyHint and openWorldHint. The description adds that changes only exist for 3 types (물품·공사·용역) and not for others, and that missing history yields empty results. No contradiction.

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?

Four sentences, front-loaded with purpose. Each sentence adds value: function, use case, alternatives, and behavioral details. No wasted words.

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 2 parameters, no output schema, the description covers behavior (empty results, enum constraints, sibling references). It is complete for a query 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?

Schema coverage is 100%, so baseline 3. The description adds beyond schema by providing example for bidNtceNo, explaining bidKind enum values with Korean, and noting the 3-type restriction. This adds meaningful context.

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 it queries change history (정정·변경 항목, 변경 전/후 값) by bid announcement number, and distinguishes from siblings like get_bid_basis_amount and get_bid_eligibility.

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

Usage Guidelines5/5

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

Explicitly specifies when to use (to check post-announcement changes) and provides alternatives (get_bid_basis_amount, get_bid_eligibility). Also explains behavior when bidKind is specified vs omitted.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/opendata-kr/narajangteo-bid-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server