contract-compass

계약방법 판정

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

Name	Required	Default
`org_type`	No	public_corp
`project_name`	No	MCP 조회
`service_type`	No
`contract_type`	Yes
`estimated_price`	Yes
`is_youth_startup`	No
`selected_rule_id`	No
`follow_up_answers`	No
`negotiation_reason`	No
`is_small_enterprise`	No
`is_women_enterprise`	No
`is_social_enterprise`	No
`construction_specialty`	No
`is_disabled_enterprise`	No
`selected_alternative_kind`	No
`is_sme_competition_product`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed3 schema fields changedAug 20, 2026

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"
+}

Changed1 schema field changedAug 11, 2026

addedInput schema / properties / is_small_enterprise

Added value: +{
+  "default": false,
+  "title": "Is Small Enterprise",
+  "type": "boolean"
+}

Changed4 schema fields changedJul 31, 2026

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"
+}

Changed3 schema fields changedJul 30, 2026

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"
+  }
+]

First observedJul 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses the two-stage decision flow, the behavior of selected_rule_id when invalid (selection_ignored_reason), and the critical consequence of omitting enterprise flags (negotiation candidates disappear). This is rich behavioral context that annotations alone do not provide.

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 long but appropriately so for a 16-parameter legal rule engine. It is front-loaded with the core purpose, then systematically walks through each argument with necessary legal context and warnings. No sentence is wasted; the length is justified by the complexity.

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, the description explains the return concepts: candidates, legal basis, follow_up_questions, final_recommendation, and selection_ignored_reason. It also covers the two-stage invocation model and the conditional logic for enterprise flags. For a tool of this complexity, the description is remarkably complete.

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 description coverage is 0%, so the description carries the full burden—and it delivers. Every meaningful parameter is explained with allowed values, legal references, conditional relevance, and warnings (e.g., is_small_enterprise, is_women_enterprise, follow_up_answers). This far exceeds the bare 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 opens with a specific verb and resource: '계약방법 결정론 판정 — 룰엔진이 적용 가능한 계약방법 후보와 법령 근거를 반환' (rule engine returns applicable contract method candidates and legal basis). This clearly distinguishes it from sibling tools like search_law or estimate_delay_penalty, which address different legal/calculation tasks.

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 provides clear workflow guidance: call once to get follow_up_questions, ask the user, then call again with follow_up_answers to receive final_recommendation. It also warns against guessing answers. However, it does not explicitly state when not to use this tool or name alternative tools, so it stops short of a 5.

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

All contract-compass tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: deterministic rule engines for contract method, price adjustment, and delay penalties; separate search tools for statutes, cases, and administrative references; and get_law_article_asof provides a unique temporal capability. Even the three search tools are cleanly differentiated by corpus and result type.

Naming Consistency4/5

The vast majority follow a verb_noun snake_case pattern (check_, decide_, estimate_, get_, report_, search_). delay_exemption_guide breaks the verb-first convention, but the naming style is consistent and readable.

Tool Count5/5

With 11 tools, the server is well-scoped for Korean public contract law advisory. The set balances three rule engines, five reference/lookup tools, one temporal variant, one reporting tool, and no redundant additions.

Completeness4/5

The tool set covers core contract lifecycle determinations—method selection, price escalation, delay penalties, and exemption grounds—and provides comprehensive legal research including historical law versions. Some lifecycle areas like termination or bidder sanctions lack dedicated rule engines, but they are accessible through the search and law-article tools.

계약방법 판정

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources