Skip to main content
Glama

계약방법 판정

decide_contract_method
Read-onlyIdempotent

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

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" 등
    is_sme_competition_product: 중소기업자간 경쟁제품 여부
    negotiation_reason: 수의 사유 "urgent"|"rebid_failure"|"technical_difficulty"|
        "patent_new_tech"|"specific_person"|"small_repeat"|"other_justified"
    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천만 이하) 요건 충족 시에만 수의 가능하므로,
        해당하면 플래그를 세워라. 미충족이면 경쟁입찰이 원칙이다.
    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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
org_typeNopublic_corp
project_nameNoMCP 조회
service_typeNo
contract_typeYes
estimated_priceYes
is_youth_startupNo
selected_rule_idNo
follow_up_answersNo
negotiation_reasonNo
is_small_enterpriseNo
is_women_enterpriseNo
is_social_enterpriseNo
construction_specialtyNo
is_disabled_enterpriseNo
selected_alternative_kindNo
is_sme_competition_productNo

TDQS

A4.6/5.0
Behavior5/5

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

With annotations already declaring readOnly/openWorld/idempotent behavior, the description adds meaningful behavioral detail: first vs. second call behavior, server-side continuation without session ids, and the selection_ignored_reason mechanism. It also discloses that omitting enterprise flags can silently remove negotiated-contract candidates.

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 purpose is front-loaded and the parameter explanations are dense with necessary legal detail. It is long and somewhat repetitive—especially the warning about women/disabled/social enterprise flags—but each section contributes operational value for a complex tool.

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

Completeness4/5

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

Given the tool's high complexity and lack of output schema, the description covers the two-stage recom-mendation flow, key return objects (follow_up_questions, final_recommendation, selection_ignored_reason), and per-parameter rules. Still, it does not fully describe the structure of candidate/final_recommendation objects or provide a concrete output example.

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 schema provides 0% description coverage, so the description fully compensates by explaining each parameter's meaning, conditional relevance, legal thresholds, and examples. It even gives concrete JSON format for follow_up_answers and explains when fields like selected_rule_id are ignored.

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 clearly states the tool's function: the rule engine returns applicable contract-method candidates and statutory basis. The verb "반환" plus the specific resource (계약방법 후보/법령 근거) distinguishes it from sibling search/case/law tools.

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 gives an explicit two-stage workflow: call once to get follow_up_questions, then call again with follow_up_answers to get final_recommendation. It also warns not to guess when answers are unknown and explains when flags must be set. However, it does not explicitly compare this tool with sibling alternatives.

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.

TDQS

A4.6/5.0
Disambiguation4/5

Most tools have clearly distinct purposes: calculation tools (check_price_adjustment, estimate_delay_penalty, decide_contract_method), reference tools (get_law_article, get_case), and search tools. The only potential confusion is between search_law and search_references since both cover statutes, but their descriptions explicitly delineate scope (statutes-only vs. statutes+guidelines+rulings).

Naming Consistency4/5

Tool names overwhelmingly follow a snake_case verb_noun pattern (check_price_adjustment, estimate_delay_penalty, get_law_article, search_cases). One outlier is delay_exemption_guide, which uses a noun-led pattern rather than a verb-led one, but it is still readable and consistent in style.

Tool Count5/5

Eleven tools is well within the ideal range for a specialized legal advisory server. Each tool covers a distinct function: rule-based determinations, calculations, legal research, historical lookup, case retrieval, and issue reporting. No tool feels redundant or superfluous.

Completeness4/5

The toolset covers the core advisory workflow well: searching statutes, guidelines, and cases; retrieving full texts and historical versions; and performing key calculations for price adjustments and delay penalties. Minor gaps exist such as calculators for other contract lifecycle adjustments, but those are reasonably addressable through the search and reference tools.