Skip to main content
Glama

계약방법 판정

decide_contract_method
Read-onlyIdempotent

계약방법 결정론 판정 — 룰엔진이 적용 가능한 계약방법 후보와 법령 근거를 반환.

상대방 지위(소기업·여성기업 등)를 안 넣었는데 그 지위로만 열리는 수의 후보가 있으면
`vendor_conditional_candidates`로 따로 온다 — 지위를 추정하지 말고 사용자에게 확인하라.

`law_currency`는 이 판정이 기대는 법령(공기업이면 계약사무규칙 포함 — `laws_checked`)의
현행 여부다(2026-10-15). `status`가 "verified"가 아니면 `note_currency`와
`laws_not_verified`가 온다 — 그 규범을 현행으로 단정해 인용하지 말고 그 사실을 밝혀라.

Args:
    contract_type: "construction"(공사) | "service"(용역) | "product"(물품)
    estimated_price: 추정가격(원)
    org_type: "national"(국가기관) | "local"(지자체) | "public_corp"(공기업·준정부, 기본)
    service_type: 용역일 때 "technical"|"academic"|"facility"|"it_service"|"other"
    construction_specialty: 공사일 때 "general"(종합)|"electrical"|"ict"|"fire_safety" 등.
        이 둘을 다른 계약유형에 넣으면 판정에 넣지 않고 `ignored_inputs`에 그 사실이 온다.
    is_sme_competition_product: 중소기업자간 경쟁제품 여부
    negotiation_reason: 수의 사유 "urgent"|"rebid_failure"|"technical_difficulty"|
        "patent_new_tech"|"specific_person"|"small_repeat"|"other_justified".
        "rebid_failure"는 **재공고입찰까지 했는데도 유찰**(입찰 불성립·낙찰자 없음·1인 응찰)된
        경우다 — 이 값만으로 재공고 수의 후보가 나온다(국가 시행령 제27조 / 지자체는 지방
        시행령 제26조). 지자체(org_type="local")의 사유 판정은 지방계약법 시행령 제25조①
        각 호·제26조를 근거로 나간다. "small_repeat"(소액)는 금액 사유라 사유 룰이 따로
        없고 추정가격 기준 금액 룰이 판정한다(상한 초과면 수의 후보가 나오지 않는다).
    is_women_enterprise: 여성기업 여부 — 지자체 물품·용역 2천만원 초과 1억원 이하
        수의계약(시행령 제25조제1항제5호바목) 판정에 필요. 사용자가 "여성기업",
        "장애인기업", "사회적기업"이라고 말하면 **반드시 해당 플래그를 세워라** —
        빠뜨리면 수의계약 후보가 통째로 빠지고 경쟁입찰만 제시된다.
    is_disabled_enterprise: 장애인기업 여부 (위와 같은 목)
    is_social_enterprise: 사회적기업·사회적협동조합·자활기업·마을기업 여부 (위와 같은 목).
        이 유형은 행정안전부 고시 취약계층 고용비율 충족이 추가 요건이다.
    is_youth_startup: 청년창업기업 여부 — 물품·용역 2천만원 초과 5천만원 이하
        수의계약(지방 제5호 다목 / 국가 시행령 제26조①5호가목7, 중소기업창업
        지원법 제2조제11호)
    is_small_enterprise: 상대방이 소기업·소상공인인지 여부 — 2천만원 초과 1억원
        이하 수의계약(국가 시행령 제26조①5호가목3 / 지방 시행령 제25조①5호라목)
        판정에 필요. **주의: 국가·공기업 2천만원 초과~1억원 이하는 무조건
        소액수의가 아니다** — 소기업·소상공인/특수 지식·기술(academic)/여성·
        장애인·사회적기업/청년창업(5천만 이하) 요건 충족 시에만 수의 가능하므로,
        해당하면 플래그를 세워라. 미충족이면 경쟁입찰이 원칙이다.
    is_special_expertise: 학술연구·원가계산·건설기술 등 **특수한 지식·기술·자격을 요구하는
        계약**인지 — 물품·용역 2천만원 초과 1억원 이하 수의(국가 시행령 제26조①5호가목4 /
        지방 시행령 제25조①5호마목) 판정에 필요. **물품에도 적용된다**(예: 항공사진 정사영상
        구매). 용역은 service_type="academic"과 같은 뜻이다.
    follow_up_answers: **후속질문 답변** — 이 도구를 한 번 부르면 `follow_up_questions`가
        함께 온다(제한경쟁·공동도급 등 판정을 바꾸는 조건). 사용자에게 물어 답을 얻었으면
        같은 인자에 이것만 더해 **다시 부르면 `final_recommendation`(최종 계약방법)이
        온다.** 형식은 `{질문id: true/false 또는 값}` (예: `{"regional_restriction": true,
        "joint_contract": true}`). 세션 id를 들고 다닐 필요가 없다 — 서버가 같은 호출
        안에서 1단계·2단계를 이어 판정한다. 답을 모르면 넣지 마라(추측 금지).
    selected_rule_id: 후보 중 사용자가 고른 룰 id(예: "SVC_004"). 후보에 없으면 무시되고
        그 사실이 `final_recommendation.selection_ignored_reason`에 적힌다.
    selected_alternative_kind: `practice_alternatives`에서 사용자가 고른 실무 옵션의 kind.
    bid_notice_date: 입찰공고(예정)일 "YYYY-MM-DD". 공고일 기준으로 갈리는 규정의 기준일이다
        (예: 지자체 중소기업자 우선조달 상한 — 판로지원법 제4조② 단서는 2026-12-30 시행 후
        최초 입찰공고분부터). 모르면 넣지 마라 — 서버는 오늘 날짜로 한 기간을 고르지 않고
        두 기간을 다 공시한다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
org_typeNopublic_corp
project_nameNoMCP 조회
service_typeNo
contract_typeYes
bid_notice_dateNo
estimated_priceYes
is_youth_startupNo
selected_rule_idNo
follow_up_answersNo
include_footnotesNotrue면 계산값 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다. 기본은 행마다 한 줄 요지
negotiation_reasonNo
is_small_enterpriseNo
is_women_enterpriseNo
is_social_enterpriseNo
is_special_expertiseNo
construction_specialtyNo
is_disabled_enterpriseNo
selected_alternative_kindNo
is_sme_competition_productNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_footnotes
      Added value: +{
      +  "default": false,
      +  "description": "true면 계산값 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다. 기본은 행마다 한 줄 요지",
      +  "title": "Include Footnotes",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / bid_notice_date
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Bid Notice Date"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / is_special_expertise
      Added value: +{
      +  "default": false,
      +  "title": "Is Special Expertise",
      +  "type": "boolean"
      +}
  4. Changed3 schema fields changed
    • addedInput schema / properties / follow_up_answers
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Follow Up Answers"
      +}
    • addedInput schema / properties / selected_alternative_kind
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Selected Alternative Kind"
      +}
    • addedInput schema / properties / selected_rule_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Selected Rule Id"
      +}
  5. Changed1 schema field changed
    • addedInput schema / properties / is_small_enterprise
      Added value: +{
      +  "default": false,
      +  "title": "Is Small Enterprise",
      +  "type": "boolean"
      +}
  6. Changed4 schema fields changed
    • addedInput schema / properties / is_disabled_enterprise
      Added value: +{
      +  "default": false,
      +  "title": "Is Disabled Enterprise",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / is_social_enterprise
      Added value: +{
      +  "default": false,
      +  "title": "Is Social Enterprise",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / is_women_enterprise
      Added value: +{
      +  "default": false,
      +  "title": "Is Women Enterprise",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / is_youth_startup
      Added value: +{
      +  "default": false,
      +  "title": "Is Youth Startup",
      +  "type": "boolean"
      +}
  7. Changed3 schema fields changed
    • addedInput schema / properties / contract_type / enum
      Added value: +[
      +  "construction",
      +  "service",
      +  "product"
      +]
    • addedInput schema / properties / org_type / enum
      Added value: +[
      +  "national",
      +  "local",
      +  "public_corp"
      +]
    • changedInput schema / properties / service_type / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "technical",
      +      "academic",
      +      "facility",
      +      "it_service",
      +      "other"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  8. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover read-only/idempotent safety, but the description adds substantial behavioral context: vendor_conditional_candidates for statuses not supplied (do not infer, ask the user), law_currency freshness with a dated snapshot and status='verified' semantics, ignored_inputs for mismatched type-specific args, and selection_ignored_reason. This is well beyond what the annotations convey.

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 text is long but front-loads purpose and output behavior before the Args list, and the length is justified by 19 parameters at 5% schema coverage. There is some repetition (the 'set the flag when the user says X' warning is restated for three separate enterprise flags), which slightly dilutes density.

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?

With no output schema and a highly complex domain, the description still names and explains the key return fields — follow_up_questions, final_recommendation, vendor_conditional_candidates, law_currency/laws_not_verified/note_currency, ignored_inputs — so an agent knows what it will get back and how to act on it.

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?

With schema description coverage at 5%, the description carries nearly the full burden and does so thoroughly — enums, defaults, legal citations, and edge cases for almost every parameter (e.g. rebid_failure defined as 유찰 after re-tender, small_repeat handled as an amount rule, is_special_expertise noted as applying to product as well). Only the trivial project_name is left undocumented.

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 opening sentence states a specific verb and resource: a deterministic rule-engine that returns applicable contract-method candidates plus their legal basis. This is clearly distinguishable from sibling tools like get_law_article and search_law, which only retrieve text rather than adjudicate.

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 lays out the two-stage call flow explicitly (call once to get follow_up_questions, re-call with follow_up_answers to get final_recommendation) and instructs the agent not to guess flags when the user mentions 여성기업/장애인기업/사회적기업. It gives strong in-context usage rules but never names an alternative tool or an explicit when-not-to-use condition.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.