contract-compass
Server Details
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- kwenhwang/contract-compass
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 6 of 6 tools scored. Lowest: 3.6/5.
Each tool has a clearly distinct purpose: decide_contract_method for method determination, get_case and search_cases for case law, get_law_article and search_law for statutes, and search_references for broader references. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern with underscores (e.g., decide_contract_method, search_law). No mixing of conventions, making it predictable for agents.
With 6 tools, the server is well-scoped for a contract law research assistant. It covers decision support, case law, statutes, and references without being too sparse or overwhelming.
The tool set covers the full lifecycle of contract law research: determining the method, searching and retrieving cases and laws, and accessing broader references. There are no obvious gaps for the stated domain.
Available Tools
6 toolsdecide_contract_methodARead-onlyIdempotentInspect
계약방법 결정론 판정 — 룰엔진이 적용 가능한 계약방법 후보와 법령 근거를 반환.
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"
| Name | Required | Description | Default |
|---|---|---|---|
| org_type | No | public_corp | |
| project_name | No | MCP 조회 | |
| service_type | No | ||
| contract_type | Yes | ||
| estimated_price | Yes | ||
| negotiation_reason | No | ||
| construction_specialty | No | ||
| is_sme_competition_product | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, openWorld hints. The description adds that it uses a rule engine and returns candidates and legal basis, but no further behavioral details (e.g., permissions, rate limits). No contradiction with annotations.
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, front-loading the purpose, then listing parameters efficiently. No unnecessary repetition or fluff.
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?
While the description covers inputs well, it lacks details on the output format or structure beyond 'returns candidates and legal basis'. Given no output schema, more completeness would be helpful.
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?
Despite 0% schema description coverage, the description explains each parameter's meaning and possible values (e.g., contract_type options, service_type categories), adding significant semantic value beyond the schema's minimal titles.
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 determines contract method candidates using a rule engine and returns legal basis. It is distinct from sibling tools which are for searching laws and cases.
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 lists parameters but does not explicitly state when to use this tool versus alternatives. The context is implied by the tool's purpose, but no when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_caseARead-onlyIdempotentInspect
판례/해석례 본문 조회 — 판시사항·판결요지·참조조문(판례) 또는 질의요지·회답·이유(해석례).
Args:
kind: "prec" | "expc" (search_cases 결과의 kind)
case_id: search_cases 결과의 case_id
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| case_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds some behavioral context by listing the content sections returned, but does not disclose any additional behavioral traits such as authentication requirements, rate limits, or error handling. Moderate value beyond annotations.
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 and well-structured. It begins with a clear one-sentence overview of the tool's purpose, followed by a brief parameter explanation. No unnecessary information is included, and the most critical details are front-loaded.
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?
For a simple retrieval tool with two parameters and no output schema, the description is fairly complete. It explains the tool's purpose, the origin of the parameters, and the content of the response. However, it could be improved by briefly noting the return format or any error conditions, but this is not critical for functionality.
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 description adds significant meaning to the parameters beyond the raw schema (which has 0% coverage). It specifies that 'kind' must be 'prec' or 'expc' and that both parameters are sourced from search_cases results. This provides crucial context for parameter values, compensating for the lack of schema descriptions.
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 retrieves the full text of a case/precedent or interpretive example ('판례/해석례 본문 조회'). It lists the specific content sections returned (판시사항, 판결요지, etc.), making the purpose unambiguous and distinct from sibling tools like search_cases which only return summaries.
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 the tool should be used after search_cases by stating that the arguments 'kind' and 'case_id' come from search_cases results. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusion criteria or usage restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_law_articleARead-onlyIdempotentInspect
법령 조문 원문 전체 조회.
Args:
ref: 정확한 조문 참조 (예: "국가계약법 시행령 제26조")
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only (readOnlyHint: true), idempotent, and non-destructive. The description adds that it retrieves the full text of a legal clause, which is consistent. No additional behavioral details (e.g., required permissions, response format) are provided, but the annotations cover safety aspects adequately.
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 very short (two sentences), front-loading the purpose and quickly addressing the parameter. There is no extraneous information. However, it could be slightly more structured (e.g., separating purpose and usage), but overall it is efficient.
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 low complexity (one parameter, simple purpose) and rich annotations covering safety and idempotency, the description is fairly complete. It explains what the tool returns (full text) and how to specify the reference. The lack of output schema is acceptable for a straightforward retrieval 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?
The schema has 0% coverage, with no description for the 'ref' parameter. The description compensates by providing an example of the expected format ('국가계약법 시행령 제26조'), which clarifies the parameter semantics significantly. This is helpful for the agent, though it could be more explicit about the exact syntax requirements.
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 states 'Full text lookup of legal clause' which clearly indicates the tool retrieves the entire text of a specific law article. The name 'get_law_article' is self-explanatory. However, it does not explicitly distinguish from sibling tools like 'search_law' or 'search_references', which might be used when the exact reference is unknown.
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 an example of a precise reference ('국가계약법 시행령 제26조'), implying the tool is intended for cases where the exact article reference is known. However, there is no explicit guidance on when to use this tool versus siblings such as 'search_law' or 'search_cases', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_casesARead-onlyIdempotentInspect
판례·법령해석례 검색 — law.go.kr 실시간 조회(항상 현행). LLM 미사용.
분쟁·처분취소·해석 다툼("~해도 되나", "~취소될 수 있나")에 조문만으로 부족할 때
쓰라. 본문은 get_case(kind, case_id)로 이어서 조회.
Args:
query: 핵심 명사 위주 검색어 (예: "부정당업자 제한", "유찰 수의계약")
top_k: 종류당 반환 건수 (기본 5, 최대 10)
kind: "prec"(법원 판례) | "expc"(법제처 법령해석례) | "all"(둘 다, 기본)
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | all | |
| query | Yes | ||
| top_k | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the description need not repeat safety. It adds valuable context: real-time data from law.go.kr, always current, and no LLM usage, enhancing trust. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and densely packed: first sentence states purpose and source, second sentence gives usage context, then Args section for parameters. No wasted words, front-loaded with key information.
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 no output schema, the description explains how to proceed (use get_case for details). However, it does not describe the return format or pagination, leaving some ambiguity for an agent. Still, the workflow is clear enough for selection and invocation.
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% coverage, so description fully carries the burden. It explains query: '핵심 명사 위주 검색어' with examples; top_k: '종류당 반환 건수' with defaults; kind: enums 'prec', 'expc', 'all' with meanings. This adds significant semantic value beyond the schema's type/default info.
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?
Describes the tool as searching case law and legal interpretations via law.go.kr in real-time, with a clear use case for disputes beyond statutes. The description distinguishes it from siblings like get_case (which retrieves full text) and search_law (likely statutes).
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?
Explicitly states when to use: when disputes or interpretation questions arise and statutes alone are insufficient. Also directs to use get_case for full text, providing a clear workflow and indicating when not to use this tool (i.e., when you need the full text).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_lawARead-onlyIdempotentInspect
법령 조문 검색 — 키워드 또는 조문번호로 조문 스니펫 반환(상위 top_k건).
전문이 필요하면 get_law_article(ref)로 이어서 조회.
Args:
query: "수의계약", "시행령 제26조", "제21조" 등
top_k: 반환 건수 (기본 8, 최대 20)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds that it returns snippets and limits to top_k results, which is useful but not extensive. No contradictions.
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 very concise: a clear header line, a follow-up instruction, and a parameter list. No extraneous information; every sentence serves a purpose.
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?
Without an output schema, the description does not specify what fields the returned snippets contain, leaving some ambiguity. However, for a simple search tool, this may be acceptable. The description is adequate but not fully 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?
Although schema has 0% description coverage, the description compensates by explaining query as 'keyword or article number' with examples, and top_k as 'return count (default 8, max 20)'. This adds significant meaning beyond the bare 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 clearly states the verb 'search' and resource 'law articles', specifies it returns snippets by keyword or article number, and explicitly mentions a sibling tool for full text, distinguishing it from get_law_article.
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 explicit guidance: use this tool for snippets, and follow up with get_law_article for full text. Example queries are given, making the context of use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_referencesARead-onlyIdempotentInspect
전 코퍼스 통합 검색 — 법령+계약예규+조달청·행안부 세부기준+실무가이드. LLM 미사용.
search_law가 법령 조문 전용인 것과 달리 예규·적격심사 세부기준·실무가이드까지
검색한다. 낙찰하한율·적격심사 배점·실무 절차 등 법령 본문 밖 질문에 사용하라.
AI 생성 없이 검색 근거 원문만 반환한다(백엔드 LLM 예산 미차감).
Args:
query: 자연어 검색어 (예: "적격심사 낙찰하한율 50억 미만")
top_k: 반환 건수 (기본 6, 최대 12)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, non-destructive behavior. The description adds valuable context: no LLM usage, returns only original text, and does not consume backend LLM budget. This goes beyond annotations.
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 extremely concise, with no redundant sentences. It front-loads the core purpose and uses bullet-style formatting for clarity. Every sentence adds value.
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 complexity of a multi-source search tool and no output schema, the description covers scope, usage, and return type (original text only). It lacks details on ordering or pagination, but overall complete for agent 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%, so the description carries the burden. It provides an example query for 'query' and specifies 'top_k' maximum of 12 (not in schema), adding meaning. However, no detailed format or constraints beyond that.
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 performs a full corpus search across laws, contracts, guidelines, etc., distinguishing it from the sibling tool 'search_law' which is limited to law articles. The verb 'search' and specific scope are well-defined.
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 explicitly advises when to use this tool (questions about procedures, lowest winning bid ratio, etc., outside law text) and contrasts with 'search_law'. It also states that it does not use LLM, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!