narajangteo-pro

by kyj2294

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: analysis per company or market, detail retrieval, profile/watchlist management, fit scoring, search, and lifecycle tracing. No two tools overlap significantly.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, e.g., analyze_competitor, manage_watchlist. No mixing of camelCase or other conventions.
Tool Count5/5
8 tools is ideal for this domain, covering search, detail, analysis, management, scoring, and tracing without being too few or too many.
Completeness4/5
Covers core procurement activities well, but lacks a direct tool for comparing bids or exporting reports. The analysis tools provide aggregated data, mitigating minor gaps.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does not disclose side effects (e.g., whether adding or removing is destructive), access requirements, rate limits, or what 'check_new' returns. Only bare action descriptions are given.
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 description is relatively concise (3 lines plus bullet list). It front-loads the main purpose and lists actions cleanly. However, it could be more structured (e.g., parameter descriptions in a table) and the Korean language may limit universal clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 5 parameters and an output schema. The description covers the overall purpose and action-specific parameter requirements but misses some parameters. With no annotations, more detail on behavior and return values would improve completeness. The output schema may compensate for return values, so score is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only two parameters (keyword, watch_id) are mentioned in context of specific actions, but business_type and institution are omitted despite being in the schema. With 0% schema description coverage, the description should explain all parameters; it fails to do so, leaving ambiguity about the role of business_type and institution.
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?
Title is missing but description states 'keyword monitoring' and lists four specific actions (add, remove, list, check_new). The name 'manage_watchlist' together with the actions makes the tool's purpose unambiguous. It is clearly distinct from sibling tools like analyze_competitor or search_procurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description lists actions but does not provide context such as 'use this to manage keywords, use search_procurement to find announcements' or when to prefer one action over another. Implicit usage is derived only from action names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It indicates a read-only analysis (no mutation implied), but does not explicitly state side effects, permissions, or rate limits. Partially transparent but could be clearer.
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?
Description is concise and front-loaded with the main purpose. The Args section is a bit repetitive but functional. No unnecessary words, though structure could be more streamlined.
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 presence of an output schema, the description lists the analytical aspects (bid counts, etc.) which gives agent expectation of output content. Parameter documentation covers all three parameters. Lacks output format details but sufficient for basic understanding.
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 description coverage is 0%, but the description adds useful parameter semantics: company_name accepts partial matches, period_months is analysis period, business_type has default 'all'. This adds meaningful context beyond the schema's titles and defaults.
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 the tool analyzes a specific company's procurement market activity, listing specific metrics (bid counts/amounts, core sectors, average win rate, buyer patterns). This distinguishes it from siblings like analyze_market (market-level) and score_bid_fit (bid fit scoring).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Missing context on prerequisites, limitations, or typical use cases. The Args section lists parameters but does not explain the context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It describes the expected outputs (e.g., monthly trends, top organizations) but does not mention any critical behavioral aspects such as data source freshness, authentication requirements, rate limits, or absence handling. The presence of an output schema partially compensates, but the description lacks deeper behavioral context.
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 description is well-structured with a clear purpose sentence followed by a bulleted list of outputs and an Args section. It is front-loaded and every sentence adds value. Minor redundancy could be trimmed, but overall it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 parameters, 1 required) and presence of an output schema, the description covers the parameter semantics and output briefly. However, it lacks usage guidelines and behavioral details, which leaves some completeness gaps. It is adequate but not fully comprehensive.
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 has 0% description coverage, so the description adds essential meaning. Each parameter is explained: 'keyword' is the analysis keyword with examples ('AI 챗봇', '클라우드'); 'period_months' is described as the analysis period with a default of 12 months; 'business_type' is explained as a business type or 'all' summing 4 types. This goes far beyond the bare schema types and defaults.
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 the tool's purpose with a specific verb ('분석') and resource (시장 동향, market trends). It lists concrete outputs (monthly trends, average bid ratio, etc.), making it easy to understand. It also distinguishes from siblings like 'analyze_competitor', which focuses on competitors rather than market trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus its siblings, nor does it mention any prerequisites or limitations. It only describes what the tool does, leaving the agent to infer usage from context. No 'when-not' or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only describes input mapping and does not mention idempotency, side effects, authentication needs, or rate limits. The phrase 'detailed information retrieval' implies read-only but is not explicit.
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 concise with a clear front-loaded purpose and a structured Args block. Every sentence adds value, and the Korean/English bilingual presentation is efficient for the target audience.
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 output schema exists (no need to describe return values), the description covers parameter domain mapping and usage. It lacks explanation of error handling or edge cases, but for a detailed retrieval tool with moderate complexity, it is largely complete.
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 description coverage is 0%, so the description adds significant value by explaining each parameter's meaning (domain enumeration with Korean labels, notice_no mapping across domains, business_type context, notice_ord default). However, business_type possible values are not fully enumerated, and notice_ord format is vague.
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 retrieves detailed information for various procurement domains (bid, award, contract, request, shopping). It distinguishes from siblings like search_procurement and trace_procurement_lifecycle by focusing on single item details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameter usage but does not explicitly state when to use this tool versus alternatives. Usage is implied from context (e.g., search vs detail retrieval), but no when-not or alternative references provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description explains update behavior for save (same ID updates) and revenue format (natural language). Lacks details on authentication, error handling, or idempotency for delete/list.
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?
Structured with action list and revenue note. Concise with minimal fluff. Could be slightly more condensed but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values not needed. Covers basic usage but lacks details on list output format, error cases, or edge conditions for a CRUD tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description explains action enum, profile_id/name requirement for save, and revenue format. But other params (licenses, certifications, prior_contracts, notes) are 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?
Description clearly states it manages company profiles for suitability evaluation, listing actions (save, load, list, delete). Distinct from sibling tools like analyze_competitor or score_bid_fit.
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?
Context is clear: used for company profile CRUD in evaluation. Action list with required parameters guides usage, but no explicit when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it returns a timeline and is read-only based on context, but does not disclose side effects, auth needs, or rate limits.
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?
Two concise sentences in Korean followed by Args list. Front-loaded with purpose and value. No wasted words.
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?
Output schema exists, so return values are covered. Description explains all parameters and basic behavior. Lacks error handling or edge case details, but sufficient for standard use.
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 descriptions coverage is 0%, but description adds meaning by explaining id_type enum values and naming the parameters. Could further elaborate on id_value format and business_type options.
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?
Description clearly states it traces the entire procurement lifecycle from pre-spec to contract, returning a timeline. It distinguishes itself from siblings like search_procurement, get_procurement_detail, etc., which are for specific aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use comparisons with siblings. The description implies it's for full lifecycle tracing, but lacks direct guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the return type (score + recommendation) but does not state whether the tool is read-only, has side effects, or requires specific permissions. The absence of contradictions is noted.
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 concise: a one-line purpose statement followed by a clean parameter list. Every sentence adds value, no redundancy. The structure is front-loaded with the primary action.
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 the tool has 5 parameters, no annotations, and an output schema (implied by mentioning score), the description covers purpose, all parameters, and return value. It also references a sibling tool (manage_company_profile) for context. No gaps are apparent.
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 must compensate. It provides detailed explanations for all 5 parameters, including the structure of inline_profile (dict with licenses, certifications, revenue, prior_contracts) and the relationship between profile_id and manage_company_profile. This adds significant meaning beyond the schema's titles and types.
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 the tool evaluates bid fit by matching company profile (licenses, revenue, performance) with notice requirements and outputs a 0-100 score plus recommendation. This specific verb-resource combination distinguishes it from siblings like analyze_competitor or manage_company_profile.
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 implies usage when a company profile and bid notice are available, and explicitly mentions that profile_id is stored via manage_company_profile, indicating a prerequisite. However, it does not explicitly state when not to use or compare to alternatives like analyze_competitor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses parameter interactions (period overrides date_from/to, shopping ignores business_type) and return format (items, total_count, page_no). Minor omission: no mention of read-only vs destructive nature.
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?
Structured with sections and bullet-pointed parameters, making it scannable. However, the parameter explanations are somewhat verbose; some could be shortened without loss of clarity.
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 8 parameters, no annotations, and an output schema, the description covers all necessary aspects: domain behavior, parameter interactions, return values, and limits. Complete for a search tool.
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 coverage is 0%, so description must compensate. It does so thoroughly, explaining each parameter, including enum values for domain, natural language processing for business_type, and default behavior for period. Adds significant meaning beyond 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 explicitly states it's a unified search tool for 5 areas (bid, award, contract, request, shopping) of the Korean procurement system, with clear definitions. This distinguishes it from sibling tools like get_procurement_detail or trace_procurement_lifecycle.
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 domain-specific usage notes (e.g., 'shopping' ignores business_type; 'request' is the earliest stage). However, it does not explicitly state when to use this tool versus alternatives, though sibling tool names give context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![naramarket-pro-MCP MCP server](https://glama.ai/mcp/servers/kyj2294/naramarket-pro-MCP/badges/card.svg)](https://glama.ai/mcp/servers/kyj2294/naramarket-pro-MCP)

Score Badge

Copy to your README.md:

[![naramarket-pro-MCP MCP server](https://glama.ai/mcp/servers/kyj2294/naramarket-pro-MCP/badges/score.svg)](https://glama.ai/mcp/servers/kyj2294/naramarket-pro-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/kyj2294/naramarket-pro-MCP'

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