naver-land-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: paginated vs single-page articles, complex details vs list, region info vs hierarchical search, price trends, school info, and coordinate-based search. No two tools overlap in purpose.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case (get_*, search_*), making the API predictable and easy to navigate.
Tool Count5/5
With 9 tools, the server covers all necessary operations for a real estate data API without being bloated or sparse. Each tool serves a clear role.
Completeness4/5
The tool set provides comprehensive read-only access to complex info, listings, price history, school info, and region data. Minor gap: no tool for individual listing details beyond the article list, but the overall coverage is strong.
Average 3.7/5 across 9 of 9 tools scored. Lowest: 2.4/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. The description only states what the tool does, not any behavioral traits such as data freshness, authentication requirements, error handling, or any side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single line and an Args section. While it is front-loaded with the main purpose, it lacks additional context that could be provided without adding much length. It is not overly verbose but misses opportunities to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (though not shown), the description is still incomplete. It does not explain what the output contains, how to interpret the results, or any edge cases. For a simple tool, a slightly richer description would be expected.
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?
The schema has 0% description coverage, meaning the parameter complex_no only has a title and type. The description adds '단지 코드' (complex code), which provides minimal semantic value. It does not explain the format (e.g., numeric, alphanumeric), how to obtain it, or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves school districts around a complex (elementary, middle, high school). It uses specific nouns and verbs, making the purpose understandable. However, it does not distinguish itself from siblings like get_complex_detail or get_region_info, which could also provide location-related data.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or scenarios where this tool is appropriate. For example, it does not explain if it should be used after obtaining a complex_no from another tool.
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, and the description does not disclose behavioral traits such as read-only nature, authorization requirements, or rate limits. It only parameter details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes unnecessary formatting like 'Args:' and line breaks. The key information is front-loaded, but could be more streamlined.
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 that an output schema exists, the description adequately covers parameter usage. However, it lacks context on what the output contains or how to interpret the results.
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?
With 0% schema description coverage, the description adds critical meaning: trade_type codes and year default. It also hints at area_no source (get_complex_detail → pyeongNo). However, complex_no is not explained further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides market price/actual transaction price trends, with a clear list of parameters. It distinguishes itself from siblings like get_complex_detail and get_region_info, but could more explicitly differentiate.
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. The description only lists parameters without specifying use cases or exclusions.
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 carry the full burden. It only lists the parameter and example fields but fails to disclose behavioral traits such as whether the operation is read-only, requires authentication, or has rate limits. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, containing both Korean and English text. It is mostly concise, but the parameter description is redundant with the schema. It could be more streamlined.
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 that an output schema exists, the description does not need to explain return values. The tool has only one parameter and the description covers its purpose. However, due to the lack of behavioral transparency and usage guidelines, the description is minimally complete.
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?
Schema description coverage is 0%, so the description must add meaning. It provides 'complex_no: 단지 코드' (complex code) which is a minor addition, but does not explain the format or source of the code. The description adds limited value beyond the 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 clearly states '단지 상세 정보' (complex detail info) and lists example fields (households, area, move-in year, construction company). It distinguishes from siblings like 'get_complexes' which likely lists complexes, and 'get_price_info' etc.
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 implies usage for retrieving detailed info for a specific complex, but provides no explicit guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites.
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?
The description mentions 'auto paging' and a max_pages parameter, implying it fetches multiple pages. However, it does not disclose whether the tool is read-only, has side effects, or the nature of pagination (sequential vs parallel). With no annotations, the description provides moderate but incomplete behavioral insight.
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 concise, using a title line and an Args section. It efficiently conveys the tool's purpose and parameters without extra words. However, the order parameter explanation could be slightly more structured (e.g., listing meaning of each suffix).
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 description covers parameter semantics well but lacks usage context, such as how auto-paging works, limits, or when to prefer this over get_articles. Given the output schema exists, return values are not needed, but behavioral and contextual details are missing for a comprehensive 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?
The description fully explains each parameter: complex_no as complex code, trade_type with three options (매매, 전세, 월세 via codes A1/B1/B2), order with three choices (가격순/면적순/최신순 via codes), and max_pages as page limit. This compensates for 0% schema coverage, though order value suffixes are not explained (e.g., ascending vs descending).
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 '단지별 매물 전체 (자동 페이징)' meaning 'All articles by complex (auto paging)'. It specifies the scope (all articles for a complex) and a key feature (automatic paging), which distinguishes it from sibling tools like get_articles.
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 is provided on when to use this tool versus alternatives like get_articles or search_listings. There is no mention of prerequisites, performance considerations, or explicit scenarios for choosing this tool.
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?
The description discloses that only the first page is returned (1페이지). Without annotations, this is useful behavioral information. However, it does not mention rate limits, authentication needs, or data freshness, leaving gaps.
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 concise and structured with a header and argument list. Every sentence adds value, though the Korean text could be slightly more compact. No unnecessary content.
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 output schema exists, return value explanation is not needed. However, the description does not mention pagination details beyond the first page, default page size, or how to get subsequent pages. This limits completeness for a paginated list 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?
The description adds thorough explanations for all parameters: complex_no (source), trade_type (values A1/B1/B2), order (values prc_/spc_/date_), and page (number). The schema had 0% description coverage, so this fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns a list of listings per complex (단지별 매물 목록) and explicitly limits to the first page. This clearly indicates the tool's scope. However, it does not differentiate from sibling tools like get_all_articles, which could fetch all pages.
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 lists trade types and sort orders, providing some usage guidance. However, it does not explain when to use this tool versus alternatives, nor does it specify prerequisites or exclusions.
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 are provided, so the description must cover behavioral traits. It mentions stability and parameter defaults but does not disclose side effects, authentication needs, rate limits, or response structure. Some transparency is present in parameter behavior (e.g., max_pages).
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 bold title, explanatory text, and a parameter list. It is front-loaded with purpose. Slightly verbose due to repeated explanations of code formats, but overall efficient.
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 parameter count of 7 and 2 required parameters, the description covers input semantics well. It does not mention output schema (which exists) or return value details, but that is acceptable. It also explains pagination via max_pages. Missing a note on output structure or error handling.
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 0% schema description coverage, the description fully compensates by providing detailed explanations for all 7 parameters, including examples, allowed values (trade types, property types), defaults, and the meaning of delta and max_pages. This is excellent coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: 'coordinate-based listing search (most stable method)'. It distinguishes itself from get_region_info (used as a prerequisite) but does not explicitly differentiate from other siblings like get_articles or get_complex_detail.
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 advises using get_region_info first to verify coordinates and explains trade/property type codes. It provides context for when to use (coordinate-based search) but does not specify when not to use or mention alternative tools.
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, the description must disclose behavior. It reveals an automatic fallback on rate limiting, which is a key behavioral trait. However, it does not mention other aspects like authentication, read-only nature, or error states. The disclosure is partial but adds value.
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 short, starting with the core purpose, then the behavioral note, then parameter documentation. Every sentence contributes without redundancy. It is efficiently structured for an AI agent to parse quickly.
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 has only 2 parameters and an output schema, the description covers purpose, parameters, and a critical behavioral quirk (rate limit fallback). It lacks mention of authentication or pagination, but the output schema likely handles return details, making it reasonably 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 bears full responsibility. It explains cortar_no as a 10-digit administrative district code and lists real_estate_type values (APT, OPST, VL etc.), with a default noted. This provides essential meaning absent from the 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 the tool retrieves a list of complexes for a specific neighborhood, with a clear verb (조회/retrieve) and resource (단지 목록/complex list). This distinguishes it from siblings like get_complex_detail (single complex) and search_listings (property listings).
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 a specific usage scenario: when rate-limited, the tool auto-switches and directs to search_listings. This gives agents a conditional alternative. However, it doesn't cover when to prefer this tool over other siblings in normal conditions.
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?
No annotations provided, so description carries full burden. It discloses hierarchical navigation, default code, and rate limit fallback. Does not detail error handling for invalid codes, but output schema exists and read-only nature is clear from 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?
Description is concise with bullet points and a clear example. Front-loaded with purpose. Minor redundancy (e.g., '지역 검색' repeated), but overall efficient.
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 single parameter and existence of an output schema, the description covers hierarchy, default, example, and fallback. Lacks details on error cases or edge conditions, but adequate for a fairly simple 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 description coverage is 0%, requiring description to compensate. It fully explains the parameter 'cortar_no' as a 10-digit region code with default for entire country, and demonstrates usage in the example. This adds significant meaning beyond the 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?
Description clearly states the tool is for region search with hierarchical exploration (시도 → 시군구 → 읍면동). It provides specific verb 'search/explore' and resource 'regions hierarchy', distinguishing it from sibling tools like get_complexes or get_articles.
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?
Explains step-by-step usage with examples and default behavior. Missing explicit 'when not to use', but context from sibling tools and the description itself implies it's for region code navigation only. Mentions automatic fallback for rate limiting.
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 are provided, so the description carries full responsibility. It mentions that the tool is 'rate limit 강건' (robust against rate limits), which is a behavioral trait. However, it does not explicitly state that the operation is read-only or safe, nor does it disclose any potential side effects or permission requirements. Given the lookup nature, a 3 is appropriate.
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, with a lead sentence summarizing the tool, followed by a usage hint and parameter documentation. Each sentence adds value, though the parameter descriptions could be slightly more succinct. Still, it is well-structured and front-loaded.
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's moderate complexity (3 parameters, output schema exists) and the presence of sibling tools, the description covers the necessary context: what it does, when to use it (vs search_regions), how to use outputs, and parameter details. The output schema existing means describing return values is unnecessary, so no gap.
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%, but the description provides detailed meaning for all three parameters: cortar_no is '지역 코드 (읍면동 10자리)', real_estate_type includes examples like 'APT, OPST, VL 등', and trade_type lists A1, B1, B2 with their Korean equivalents. This significantly adds value beyond 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 clearly states that the tool retrieves region information and coordinates (지역 정보 + 좌표 조회) based on cortarNo. It specifies the outputs: exact coordinates, region name, and cluster count. It distinguishes itself from siblings by mentioning it is an alternative when search_regions is rate-limited.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: as an alternative when search_regions hits rate limits. It also explains how the output can be directly used in search_listings, providing integration guidance. No contradictory usage advice is given.
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:

[![naver-land-mcp MCP server](https://glama.ai/mcp/servers/kimduksoo/naver-land-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kimduksoo/naver-land-mcp)

Score Badge

Copy to your README.md:

[![naver-land-mcp MCP server](https://glama.ai/mcp/servers/kimduksoo/naver-land-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kimduksoo/naver-land-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/kimduksoo/naver-land-mcp'

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