Korean SaaS directory: search 3,700+ services, find Korean API/MCP tools and AI API providers.
Scored across 11 tools
Most tools target clearly distinct actions (submit, check, claim, verify, compare, get, list, search), but the three specialized finders (agent-ready, AI providers, partners) are essentially filtered variants of search_korean_saas and could be confused by an agent that doesn't read descriptions carefully.
Nearly all tools follow a snake_case verb_noun pattern (submit_korean_saas, get_korean_saas, compare_korean_saas). Minor deviations exist—list_saas_categories drops the 'korean' qualifier and find_agent_ready_korean_saas uses an adjective—but the convention remains predictable.
11 tools is well-scoped for a directory service, covering discovery, detail retrieval, submission lifecycle, and ownership verification without bloat. Each tool earns its place.
The surface covers discovery (search, find variants, categories), detail (get, compare), and the full submission/claim/verify lifecycle. Gaps remain: no explicit update/edit listing tool and no review-writing operation, though the claim flow partially addresses ownership-based editing.
saaskr 한국 SaaS 디렉토리: submit_korean_saas 로 등록한 서비스가 발행됐는지, 심사 중인지, 보류됐다면 사유가 무엇인지 확인한다. 사용자가 "saaskr 등록 됐어?", "왜 안 올라왔어?"라고 물을 때 사용.
| Name | Required | Description | Default |
|---|---|---|---|
| website_url | Yes | 등록할 때 쓴 공식 사이트 URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely new behavioral content: the possible outcomes (published, under review, on hold with a stated reason), which tells the agent what the call can reveal. It does not describe latency or whether a not-yet-submitted URL errors versus returns an empty status.
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?
Two sentences, front-loaded with the resource scope followed by the routing trigger, with essentially no filler. Slightly dense in the first sentence (three outcome states enumerated), but every clause contributes to tool selection.
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 one-parameter, read-only status check with no output schema, the description supplies the missing piece an agent needs: the set of status outcomes the call can return. It does not spell out what an identifier mismatch produces, but nothing critical for correct invocation is absent.
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?
There is a single parameter with 100% schema description coverage ('등록할 때 쓴 공식 사이트 URL'), so the schema already carries the semantics. The description restates the same idea via its reference to submit_korean_saas but adds no format, normalization, or matching caveats beyond the schema, which is the correct baseline of 3.
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 a specific verb (확인한다/check) applied to a specific resource (the publication status of a service submitted via submit_korean_saas), and explicitly names the sibling tool that created the submission, so it is distinguishable from submit_korean_saas or get_korean_saas without opening either schema.
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?
It gives concrete when-to-use triggers in the form of user utterances ("saaskr 등록 됐어?", "왜 안 올라왔어?") and implies a prerequisite (a prior submit_korean_saas call). It does not, however, state any exclusions or name an alternative tool for adjacent questions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saaskr 한국 SaaS 디렉토리: 이미 saaskr 에 올라와 있는 내 서비스의 소유권을 인증(클레임)한다. 사용자가 "내 서비스 saaskr 에 이미 있네, 내 걸로 인증해줘", "saaskr 정보 내가 고치고 싶어"라고 할 때 사용. 인증 토큰을 발급하고, 공식 사이트에 넣을 파일/태그를 알려준다. 사용자가 그 사이트의 코드·빌더에 접근할 수 있으면 AI 가 직접 파일(또는 meta 태그)을 추가·배포한 뒤 verify_korean_saas_claim 으로 확인하면 된다. 토큰만으로는 아무 권한도 없다 — 서비스 도메인에 게시돼야 인증된다.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | saaskr 의 서비스 slug(search_korean_saas/get_korean_saas 로 확인). slug 나 website_url 중 하나. | |
| Yes | 인증 후 메이커 콘솔에 로그인할 이메일 — 이 이메일의 구글 계정으로 로그인한다 | ||
| website_url | No | 서비스 공식 사이트 URL(slug 를 모를 때) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, destructive=false, idempotent=false, but the description goes well beyond them: it issues a token, names the artifact (file or meta tag) to publish, states that the token alone grants no permissions until published on the domain, and clarifies that the AI may deploy the file directly when it has builder/code access. That is real workflow and authorization context the annotations cannot carry.
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 purpose is front-loaded and the flow (issue token → publish → verify) follows in logical order. It is slightly long, but each sentence contributes distinct information rather than restating the name or schema.
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?
No output schema exists, yet the description explains the full lifecycle a caller must drive, including the next tool to call and the condition that makes the claim valid. It is essentially complete for a 3-parameter, no-output tool, with only minor gaps around repeated-call behavior.
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 100%, so all three parameters (slug, email, website_url) are already documented with their purpose, including the email's role as the maker-console login. The description adds no syntax or format detail beyond what the schema states, so the baseline 3 applies.
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?
States a specific verb (claim/verify ownership) and resource (an already-listed service on the saaskr directory), with scope limited to existing listings. It names the sibling that completes the flow (verify_korean_saas_claim) and implies submit_korean_saas is for the not-yet-listed case, so an agent can place it without opening a schema.
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?
Gives explicit trigger phrases from the user ('my service is already on saaskr, verify it as mine'), which is strong when-to-use guidance, and routes to verify_korean_saas_claim as the follow-up step. It stops short of stating an explicit exclusion, e.g. 'use submit_korean_saas instead if the service is not listed', leaving that inference to the reader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saaskr 한국 SaaS 디렉토리: 한국 SaaS 두 개를 나란히 비교한다(카테고리·운영 상태·인기도·소개).
| Name | Required | Description | Default |
|---|---|---|---|
| slug_a | Yes | 첫 번째 SaaS slug | |
| slug_b | Yes | 두 번째 SaaS slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds genuine context the annotations do not: it enumerates what the comparison surfaces (category, operational status, popularity, intro), which is valuable given there is no output schema. It stops short of describing invalid-slug behavior, so a 4 rather than 5.
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?
A single front-loaded sentence naming the source ('saaskr 한국 SaaS 디렉토리') before the action and the compared dimensions. No wasted text, though quite terse for the amount it must carry.
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 read-only, two-parameter comparison tool with no output schema, the description compensates by listing the comparison dimensions the agent will receive. Nothing essential to invoking it correctly is missing, though error/edge behavior on unknown slugs is unaddressed.
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 100% for both slug parameters, so the schema already documents them fully. The description adds no format, source, or lookup guidance beyond naming the two items being compared. Baseline 3 is appropriate.
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?
States a specific verb ('비교한다'/compares) and resource (two Korean SaaS) plus the dimensions compared, which separates it from single-item siblings like get_korean_saas. Sibling differentiation is implicit through the 'two, side by side' scope rather than an explicit contrast, so it falls just short of a 5.
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 two-SaaS comparison framing implies when to reach for this over get_korean_saas or search_korean_saas, but no explicit when-to-use, prerequisites, or exclusions are stated. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saaskr 한국 SaaS 디렉토리: AI 에이전트가 직접 호출할 수 있는 한국 서비스(API·MCP 서버·웹훅이 확인된 곳)를 찾는다. "한국 결제 API", "MCP 되는 국산 CRM", "알림톡 보내는 API" 처럼 에이전트/자동화에 붙일 도구를 찾을 때 사용.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 결과 수(기본 10, 최대 30) | |
| query | No | 검색어(선택). 예: "결제", "알림톡", "회계" | |
| category | No | 카테고리 slug(선택) | |
| requires | No | 반드시 있어야 하는 연동 방식(선택). 기본은 API 또는 MCP 중 하나. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description does not need to restate safety. It adds genuinely new context by defining what "agent-ready" means — the integration (API/MCP/webhook) must be verified — which is a behavioral filter not captured by any annotation. It stops short of describing result shape or how unverified services are handled.
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?
Two sentences, front-loaded with the identity of the directory before the use-case trigger. Dense but every clause earns its place; no filler or repetition of the name/title.
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 read-only, optional-parameter search tool with no output schema and full schema coverage, the description supplies the missing piece — what qualifies as an "agent-ready" result. It is nearly complete, with only minor gaps around result format and pagination that are not critical for correct 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 description coverage is 100%, so all four parameters (limit, query, category, requires) are already documented, including the default/cap on limit and the default behavior of requires. The description only adds example query terms, which is illustrative but marginal; the schema does the heavy lifting, so baseline 3 is appropriate.
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?
States a specific verb (find) and a precise resource (Korean SaaS that agents can call), and defines the discriminating filter: only services with confirmed API, MCP server, or webhook. This implicitly separates it from sibling `search_korean_saas`, but it never names that sibling or states the contrast explicitly, so the differentiation is inferred rather than asserted.
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?
Gives concrete usage context and example queries ("Korean payment API", "MCP-capable domestic CRM", "API that sends AlimTalk") that map cleanly to the `query` and `requires` parameters, telling the agent what situation calls for this tool. It does not, however, say when NOT to use it or route the agent to `search_korean_saas`/`find_korean_ai_providers` for broader or adjacent lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saaskr 한국 SaaS 디렉토리: 다른 서비스에 AI 를 API 로 공급하는 한국 기업(LLM·OCR·음성·번역·임베딩 등)을 찾는다. "한국어 OCR API", "국산 LLM API", "한국어 STT 업체" 처럼 AI 기능을 제품에 넣을 공급사를 찾을 때 사용.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 결과 수(기본 10, 최대 30) | |
| query | No | 검색어(선택) | |
| capability | No | 필요한 AI 능력(선택). 가능한 값: llm(LLM(대규모 언어모델)), ocr(OCR·문서 인식), stt(음성 인식(STT)), tts(음성 합성(TTS)), translation(번역), embedding(임베딩·검색), vision(이미지 인식), video(영상 이해·생성), rag(RAG·사내 문서 검색), inference(모델 추론 인프라), agent(AI 에이전트 플랫폼), voice-clone(음성 복제), avatar(AI 아바타·휴먼) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false, so the safety profile is covered structurally. The description adds domain scoping (only AI-API suppliers in Korea) but says nothing about result format, pagination, or caps. With annotations carrying the behavioral burden, this is adequate but not rich.
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?
Two sentences, front-loaded with the directory and scope, then the use case. No filler, though the parenthetical category list partially duplicates the capability enum already in the schema.
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 read-only, zero-required-parameter search with no output schema, the description covers what it returns conceptually (a directory lookup of AI suppliers) and when to use it. Missing only minor details like default result caps, which the schema's limit param already states.
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 100% and the capability parameter already enumerates all thirteen values, so the schema does the heavy lifting. The description echoes a few categories (LLM, OCR, voice, translation, embedding), reinforcing intent but adding no syntax or format detail beyond the schema. Baseline 3 applies.
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 names a specific verb (find) and a tightly scoped resource: Korean companies that supply AI as an API (LLM, OCR, voice, translation, embedding). That scope clearly separates it from broader siblings like search_korean_saas or find_korean_partners, though it does not explicitly name an alternative tool to route against.
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?
It gives clear usage context and concrete query examples ('한국어 OCR API', '국산 LLM API', '한국어 STT 업체') that show when to reach for this tool. However, it never states when NOT to use it or points to a sibling tool for adjacent needs, 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.
saaskr 한국 SaaS 디렉토리: 협업·제휴 제안을 받겠다고 직접 밝힌 한국 서비스를 찾는다. slug 를 주면 그 서비스와 경쟁이 아닌 보완 관계(다른 분야, 연동 가능)인 곳을 우선한다. "우리 서비스랑 제휴할 국내 서비스", "연동 파트너 찾기"에 사용.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | 기준이 되는 내 서비스의 slug(선택) | |
| limit | No | 최대 결과 수(기본 10, 최대 30) | |
| query | No | 찾는 파트너 분야·키워드(선택) | |
| category | No | 파트너 카테고리 slug(선택) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world. Beyond that, the description discloses real behavior: results are filtered to services that publicly opted in, and supplying a slug re-ranks toward complementary rather than competing services. That ranking/filtering logic is not recoverable from the 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?
Three dense sentences with no filler; the opt-in constraint, the slug behavior, and the use cases each carry distinct information. Minor: the lead 'saaskr 한국 SaaS 디렉토리:' is background framing before the actual purpose verb.
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?
All four params are optional and fully documented in the schema, and the description covers the tool's distinctive filtering and ranking semantics. No output schema exists, so return-shape detail is not owed. Adequate for a read-only discovery 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?
Schema coverage is 100%, so the baseline is 3. The description adds real meaning for slug — it is the caller's own service and it changes ranking to favor complementary (different-domain, integrable) partners — which the schema only labels as 'the reference service's slug'.
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?
States a specific verb (찾는다/find) and a sharply scoped resource: Korean SaaS that have explicitly opted in to partnership proposals. The scope qualifier '직접 밝힌' (explicitly declared) distinguishes it from a generic search or from find_agent_ready_korean_saas.
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?
Gives concrete usage triggers in quotes ('우리 서비스랑 제휴할 국내 서비스', '연동 파트너 찾기') and explains the slug-driven mode, which tells the agent when this tool fits. No explicit when-not or named alternative sibling, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saaskr 한국 SaaS 디렉토리: 특정 한국 SaaS의 상세 정보(소개·카테고리·공식 사이트·운영 상태·후기)를 가져온다.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | search_korean_saas 가 반환한 slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description's only added behavioral value is enumerating the returned fields, which is helpful for a no-output-schema tool but not rich disclosure.
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?
A single well-formed sentence with the resource and returned fields front-loaded; the 'saaskr 한국 SaaS 디렉토리' prefix is mild branding overhead, but nothing is padded or repeated.
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 read-only single-entity lookup with full annotation coverage and full schema coverage, the description is nearly sufficient, and listing the return fields compensates for the missing output schema. The only real gap is routing guidance against the many sibling tools.
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?
There is a single required parameter with 100% schema description coverage, and the schema already documents that slug comes from search_korean_saas. The description adds no format or validation detail beyond that, so the baseline 3 applies.
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?
States a specific verb ('가져온다' / fetches) and resource (detailed info for a specific Korean SaaS), and even enumerates the fields returned (intro, category, site, status, reviews). It reads clearly as a single-item lookup, but it never names or contrasts with siblings like search_korean_saas or compare_korean_saas, so sibling differentiation is left implicit.
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?
Usage is only implied: the slug parameter's schema note ('the slug returned by search_korean_saas') signals the intended chain, but the description itself never says when to use this versus search_korean_saas, find_agent_ready_korean_saas, or compare_korean_saas, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saaskr 한국 SaaS 디렉토리: 한국 SaaS 카테고리 16개와 각 카테고리의 서비스 수, 고르는 기준을 반환한다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, non-open-world behavior, so safety is covered. The description adds return-content detail (16 categories, service counts, selection criteria) that the agent would otherwise not know, since there is no output schema. It stops short of stating stability or pagination, but for a fixed no-param listing that is a minor gap.
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?
A single front-loaded sentence with no filler, moving straight from identifier to payload. Slight redundancy with the annotation title is the only inefficiency.
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 parameterless, no-output-schema tool, the description adequately communicates the return contents (category count, service counts, selection criteria). Nothing critical for calling it correctly is missing.
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 tool takes zero parameters, so the baseline is 4. The description does not need to explain any inputs, and it correctly spends its words on the result shape instead.
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?
States a specific verb and resource: returns the 16 Korean SaaS categories along with per-category service counts and selection criteria. The agent can tell this enumerates categories rather than fetching a specific SaaS entry. It does not explicitly name a sibling to contrast against, but the distinction from find_/search_/get_ tools is clear from the scope.
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?
Usage is only implied — an agent would infer this is a browse/overview step before using search_korean_saas or find_korean_saas. There is no explicit when-to-use, when-not-to-use, or named alternative, so guidance is minimum viable at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saaskr 한국 SaaS 디렉토리: 한국에서 만든 SaaS를 검색한다. 이름·태그라인·소개·태그를 대상으로 하며, 운영 중이 확인된 서비스만 반환한다. 카테고리로 좁힐 수 있다. "한국 AI 도구", "국산 협업툴" 같은 요청에 사용.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 결과 수(기본 10, 최대 30) | |
| query | No | 검색어(한국어). 예: "회의록", "결제", "디자인" | |
| category | No | 카테고리 slug로 좁히기. 가능한 값: ai, productivity, social, design, developer-tools, marketing, fintech, ecommerce, education, health, media, lifestyle, hr, gaming, travel, food | |
| kr_feature | No | 한국 특화 속성으로 좁히기(확인된 서비스만). 가능한 값: tax_invoice(전자세금계산서 발행), kakao_alimtalk(카카오 알림톡 연동), kr_pg(국내 PG 결제(카드·계좌이체)), kr_data_residency(데이터 국내 저장), isms(ISMS/ISMS-P 인증), korean_support(한국어 고객지원), kakao_login(카카오 로그인), naver_login(네이버 로그인), hwp(한글(HWP) 파일 지원) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world. Beyond that, the description discloses a meaningful behavioral trait: only services confirmed as operating are returned, and search is scoped to specific text fields.
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?
Four tight sentences, each earning its place: identity, search scope, return filter, and usage trigger. Front-loaded with what the tool is.
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 read-only search tool with fully documented parameters, the description covers purpose, scope, return semantics, and usage triggers. No output schema exists, but the description states what is returned (운영 중 확인된 서비스), which is adequate; finer return-shape detail is the only minor gap.
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 100%, with limit, query, category, and kr_feature all documented including enum values in the schema. The description only restates that category narrowing is possible, adding no syntax or format detail beyond the schema — baseline 3.
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?
States a specific verb (검색) and resource (한국 SaaS 디렉토리), plus the exact fields searched (이름·태그라인·소개·태그) and the return filter (운영 중이 확인된 서비스만). This distinguishes it from siblings like get_korean_saas, compare_korean_saas, and find_korean_ai_providers.
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?
Gives concrete example requests ("한국 AI 도구", "국산 협업툴") that signal when this tool applies, and notes category narrowing. It does not explicitly name alternative tools or exclusions, but the triggering context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saaskr 한국 SaaS 디렉토리: 내가 만든 SaaS를 saaskr 디렉토리에 등록한다. 사용자가 "내 서비스 등록해줘", "saaskr에 올려줘"라고 할 때 사용. 이미 등록된 서비스면 기존 페이지를 알려주고, 새 서비스면 심사 큐에 넣는다(링크가 살아있는지 등 자동 검증 후 보통 1시간 안에 발행). 등록 전 사용자에게 이름·URL·한 줄 설명을 확인받는다. 본인 서비스라면(is_owner) 공식 사이트를 직접 읽고 가격·API·웹훅·MCP·연동·한국 특화 기능 중 사이트에서 실제로 확인되는 것만 함께 넣는다 — 확인 안 되는 항목은 비워둘 것(추측 금지). 소개는 사용자가 준 정보와 공식 사이트 내용으로만 채운다(임의로 지어내지 말 것). 상세히 작성한다: 한 줄 소개만 보내지 말고 profile(해결하는 문제·대상 고객·주요 기능·사용 상황·차별점·시작 방법·고객 유형·플랫폼·단계)과 본인 서비스면 회사 정보(회사명·설립연도·지역·팀 규모)까지 채운다. 이 내용이 saaskr 상세 페이지 본문이 된다. 사이트와 사용자 대화에서 확인되지 않는 항목은 비운다 — 모르는 걸 만들어 채우지 말고, 필요하면 사용자에게 물어본다.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 서비스 이름 | |
| has_api | No | 외부 개발자용 API 제공 여부(확인된 경우만) | |
| has_mcp | No | MCP 서버 제공 여부(확인된 경우만) | |
| mcp_url | No | MCP 서버 주소 또는 설치 안내 URL(선택) | |
| profile | No | 서비스·사업자 상세 소개(선택이지만 가능한 한 채울 것). 상세 페이지 본문이 되고 통계에도 쓰인다. 확인 안 되는 키는 생략. | |
| tagline | Yes | 한 줄 설명(5자 이상, 200자 이내) | |
| category | No | 카테고리 slug(선택). 가능한 값: ai, productivity, social, design, developer-tools, marketing, fintech, ecommerce, education, health, media, lifestyle, hr, gaming, travel, food | |
| is_owner | No | 본인이 만든 서비스면 true. 아래 사실 항목은 true 일 때만 반영된다. | |
| description | No | 서비스 소개(선택, 4000자 이내) | |
| has_webhook | No | 웹훅 제공 여부(확인된 경우만) | |
| kr_features | No | 사이트에서 확인되는 한국 특화 기능(선택): tax_invoice(전자세금계산서 발행), kakao_alimtalk(카카오 알림톡 연동), kr_pg(국내 PG 결제(카드·계좌이체)), kr_data_residency(데이터 국내 저장), isms(ISMS/ISMS-P 인증), korean_support(한국어 고객지원), kakao_login(카카오 로그인), naver_login(네이버 로그인), hwp(한글(HWP) 파일 지원) | |
| website_url | Yes | 서비스 공식 URL (https:// 로 시작) | |
| api_docs_url | No | API 문서 URL(선택) | |
| pricing_model | No | 가격 형태(선택): free=완전 무료, freemium=무료 플랜+유료, paid=유료만, contact=도입 문의 | |
| integrates_with | No | 연동되는 서비스 이름(선택, 최대 20) | |
| submitter_email | No | 연락받을 이메일(선택) |
saaskr 한국 SaaS 디렉토리: claim_korean_saas 로 받은 토큰이 공식 사이트에 제대로 게시됐는지 바로 확인한다(saaskr.json 파일 또는 홈페이지 meta 태그). 확인되면 1시간 안에 자동으로 메이커 인증이 완료된다.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | saaskr 서비스 slug | |
| token | Yes | claim_korean_saas 가 준 saaskr-verify-… 토큰 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive behavior. The description adds genuinely useful behavior beyond that: where the token must appear (saaskr.json or homepage meta tag) and the 1-hour automatic maker-verification SLA. The auto-completion implies a downstream state change that sits in mild tension with readOnlyHint, and no error/retry behavior is described.
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?
A single compact sentence front-loads the directory context, the verification action, and the outcome, with no filler. The colon-joined structure packs several ideas into one sentence, which is efficient though slightly dense.
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 two-parameter verification tool with no output schema, the description covers the prerequisite, the two places the token is looked for, and the resulting outcome. What is missing is failure handling (token absent or malformed) and confirmation of what a successful check returns.
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 100%, and both parameters (slug, token) are already documented in the schema, including that the token is the saaskr-verify-… value from claim_korean_saas. The description adds no format or validation detail beyond what the schema states, so the baseline 3 applies.
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 names a specific verb (확인/verify) and resource (whether the token issued by claim_korean_saas has been published on the official site), and it names the sibling that produces the input token. It does not, however, distinguish itself from check_korean_saas_submission, so a sibling boundary is left for the agent to infer.
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 establishes the prerequisite workflow by stating the token comes from claim_korean_saas, which tells the agent when in the sequence to call this tool. It gives no explicit when-not-to-use guidance or contrast with check_korean_saas_submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
submit_korean_saas1 field changedInput schema / properties / profile / properties / launched_atAdded value: +{
+ "description": "서비스를 실제로 공개(출시)한 시점 \"YYYY-MM\"(월을 모르면 \"YYYY\"). saaskr 등록일과 다르다. 사이트·소개글·앱스토어 등에서 확인되는 경우만, 모르면 비워두고 사용자에게 물어볼 것.",
+ "type": "string"
+}submit_korean_saas1 field changedInput schema / properties / profileAdded value: +{
+ "description": "서비스·사업자 상세 소개(선택이지만 가능한 한 채울 것). 상세 페이지 본문이 되고 통계에도 쓰인다. 확인 안 되는 키는 생략.",
+ "properties": {
+ "audience": {
+ "description": "구체적인 대상(예: \"배달앱 3개를 같이 쓰는 사장님\") 최대 6개, 각 40자 이내",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "audience_segments": {
+ "description": "주 사용자층(복수): individual(개인·프리랜서), small_business(소상공인), startup(스타트업), sme(중소기업), enterprise(대기업), developer(개발자), marketer(마케터), designer(디자이너), creator(크리에이터), student_edu(학생·교육기관), public_sector(공공기관)",
+ "items": {
+ "enum": [
+ "individual",
+ "small_business",
+ "startup",
+ "sme",
+ "enterprise",
+ "developer",
+ "marketer",
+ "designer",
+ "creator",
+ "student_edu",
+ "public_sector"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "company": {
+ "description": "is_owner=true 일 때만 반영. 사업자등록번호·대표자명·연락처는 받지 않는다.",
+ "properties": {
+ "founded_year": {
+ "description": "설립(또는 서비스 시작) 연도",
+ "type": "integer"
+ },
+ "location": {
+ "description": "상세 위치(선택, 예: 성수동)",
+ "type": "string"
+ },
+ "name": {
+ "description": "회사·팀 이름",
+ "type": "string"
+ },
+ "region": {
+ "description": "소재 시·도: seoul(서울), gyeonggi(경기), incheon(인천), busan(부산), daegu(대구), gwangju(광주), daejeon(대전), ulsan(울산), sejong(세종), gangwon(강원), chungbuk(충북), chungnam(충남), jeonbuk(전북), jeonnam(전남), gyeongbuk(경북), gyeongnam(경남), jeju(제주), overseas(해외)",
+ "enum": [
+ "seoul",
+ "gyeonggi",
+ "incheon",
+ "busan",
+ "daegu",
+ "gwangju",
+ "daejeon",
+ "ulsan",
+ "sejong",
+ "gangwon",
+ "chungbuk",
+ "chungnam",
+ "jeonbuk",
+ "jeonnam",
+ "gyeongbuk",
+ "gyeongnam",
+ "jeju",
+ "overseas"
+ ],
+ "type": "string"
+ },
+ "team_size": {
+ "description": "팀 규모: 1(1인), 2-5(2~5명), 6-10(6~10명), 11-50(11~50명), 51-200(51~200명), 200+(200명 이상)",
+ "enum": [
+ "1",
+ "2-5",
+ "6-10",
+ "11-50",
+ "51-200",
+ "200+"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "customer_type": {
+ "description": "주 고객 유형: b2b(기업 대상(B2B)), b2c(개인 대상(B2C)), b2b2c(기업·개인 모두), b2g(공공기관 대상)",
+ "enum": [
+ "b2b",
+ "b2c",
+ "b2b2c",
+ "b2g"
+ ],
+ "type": "string"
+ },
+ "differentiator": {
+ "description": "비슷한 서비스와 다른 점(400자 이내). 근거 없는 최상급(\"최고\", \"유일\") 금지.",
+ "type": "string"
+ },
+ "features": {
+ "description": "주요 기능 최대 8개. 사이트에서 확인되는 것만.",
+ "items": {
+ "properties": {
+ "desc": {
+ "description": "한 줄 설명(140자 이내)",
+ "type": "string"
+ },
+ "title": {
+ "description": "기능 이름(30자 이내)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "getting_started": {
+ "description": "처음 쓰는 방법 한두 문장(240자 이내). 예: \"가입 후 카카오 채널 연동까지 5분\"",
+ "type": "string"
+ },
+ "platforms": {
+ "description": "제공 형태(복수): web(웹), ios(iOS 앱), android(안드로이드 앱), desktop(데스크톱), api(API), plugin(플러그인·확장)",
+ "items": {
+ "enum": [
+ "web",
+ "ios",
+ "android",
+ "desktop",
+ "api",
+ "plugin"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "problem": {
+ "description": "이 서비스가 해결하는 문제를 사용자 입장에서 2~4문장(500자 이내). 기능 나열이 아니라 \"누가 어떤 상황에서 무엇이 불편한가\".",
+ "type": "string"
+ },
+ "stage": {
+ "description": "서비스 단계: idea(준비 중), beta(베타), launched(정식 출시), growing(성장 중(유료 고객 있음))",
+ "enum": [
+ "idea",
+ "beta",
+ "launched",
+ "growing"
+ ],
+ "type": "string"
+ },
+ "use_cases": {
+ "description": "\"이럴 때 쓴다\" 상황 문장 최대 5개, 각 140자 이내",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}claim_korean_saasverify_korean_saas_claimcheck_korean_saas_submissionsubmit_korean_saas9 fields changedInput schema / properties / api_docs_urlAdded value: +{
+ "description": "API 문서 URL(선택)",
+ "type": "string"
+}Input schema / properties / has_apiAdded value: +{
+ "description": "외부 개발자용 API 제공 여부(확인된 경우만)",
+ "type": "boolean"
+}Input schema / properties / has_mcpAdded value: +{
+ "description": "MCP 서버 제공 여부(확인된 경우만)",
+ "type": "boolean"
+}Input schema / properties / has_webhookAdded value: +{
+ "description": "웹훅 제공 여부(확인된 경우만)",
+ "type": "boolean"
+}Input schema / properties / integrates_withAdded value: +{
+ "description": "연동되는 서비스 이름(선택, 최대 20)",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / is_owner / descriptionPrevious value: -"본인이 만든 서비스면 true"New value: +"본인이 만든 서비스면 true. 아래 사실 항목은 true 일 때만 반영된다."Input schema / properties / kr_featuresAdded value: +{
+ "description": "사이트에서 확인되는 한국 특화 기능(선택): tax_invoice(전자세금계산서 발행), kakao_alimtalk(카카오 알림톡 연동), kr_pg(국내 PG 결제(카드·계좌이체)), kr_data_residency(데이터 국내 저장), isms(ISMS/ISMS-P 인증), korean_support(한국어 고객지원), kakao_login(카카오 로그인), naver_login(네이버 로그인), hwp(한글(HWP) 파일 지원)",
+ "items": {
+ "enum": [
+ "tax_invoice",
+ "kakao_alimtalk",
+ "kr_pg",
+ "kr_data_residency",
+ "isms",
+ "korean_support",
+ "kakao_login",
+ "naver_login",
+ "hwp"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / mcp_urlAdded value: +{
+ "description": "MCP 서버 주소 또는 설치 안내 URL(선택)",
+ "type": "string"
+}Input schema / properties / pricing_modelAdded value: +{
+ "description": "가격 형태(선택): free=완전 무료, freemium=무료 플랜+유료, paid=유료만, contact=도입 문의",
+ "enum": [
+ "free",
+ "freemium",
+ "paid",
+ "contact"
+ ],
+ "type": "string"
+}find_agent_ready_korean_saasfind_korean_ai_providersfind_korean_partnerssearch_korean_saas1 field changedInput schema / properties / kr_featureAdded value: +{
+ "description": "한국 특화 속성으로 좁히기(확인된 서비스만). 가능한 값: tax_invoice(전자세금계산서 발행), kakao_alimtalk(카카오 알림톡 연동), kr_pg(국내 PG 결제(카드·계좌이체)), kr_data_residency(데이터 국내 저장), isms(ISMS/ISMS-P 인증), korean_support(한국어 고객지원), kakao_login(카카오 로그인), naver_login(네이버 로그인), hwp(한글(HWP) 파일 지원)",
+ "type": "string"
+}compare_korean_saasget_korean_saaslist_saas_categoriessearch_korean_saassubmit_korean_saasSearch 400k+ SaaS and software companies by category, technology, country, pricing, and more.
Korea-native MCP gateway: Korean commerce, payments, messaging, gov & finance APIs for AI agents.
AI-powered SaaS tool discovery API. Search 150+ curated business tools and get recommendations.
Agent-callable B2B SaaS directory: capability-structured, continuously verified listings.
Add one secure layer between your agents and this server.
