Bareun (바른) is a Korean natural-language engine. This MCP server lets any MCP-compatible client hand Korean text to a dedicated Korean engine instead of guessing: analyze_syntax (morphological analysis with 47 POS tags and beta homograph sense disambiguation), analyze_syntax_raw (raw model output, no post-processing), tokenize, correct_grammar (spelling and spacing correction with per-edit blocks and rule categories), and list_pos_tags. Resources expose the POS tag table, server info, and the cu
Scored across 6 tools
The overlapping pair analyze_syntax / analyze_syntax_raw shares a name prefix, but the raw variant's description explicitly tells agents when to use the other one instead, so misselection risk is low. tokenize vs analyze_syntax and correct_grammar vs both are cleanly separated by their stated outputs (word boundaries vs morphemes vs correction blocks), and search_dict/list_pos_tags occupy distinct niches.
All six names use lowercase snake_case with a verb-initial pattern (analyze_*, correct_*, list_*, search_*, tokenize), which is predictable and readable. The only deviation is the bare verb 'tokenize' and the '_raw' qualifier, both of which read naturally within the same convention.
Six tools is well within a sensible range for a focused Korean NLP service, and each one maps to a distinct capability (morphology, raw morphology, spell check, tokenization, tag reference, dictionary pattern search). No tool looks like filler or a near-duplicate added just for volume.
The surface covers the core Korean NLP lifecycle: tokenize, analyze, correct, and look up tags/dictionary patterns. Minor gaps remain — there is no exact-word or lemma-based dictionary lookup (search_dict is jamo-pattern oriented), no document/batch-level operation, and no dedicated dictionary-entry detail tool, but agents can approximate these with the existing calls.
한국어 문장의 형태소 분석을 수행합니다. 문장을 어절·형태소로 나누고 품사를 부착합니다. format=compact 면 '표층형/품사' 요약 문자열을, full 이면 전체 구조 JSON 을 돌려줍니다. with_sense=true 를 주면 동형이의어(같은 표기, 다른 뜻: 배[腹]/배[船]/배[梨])의 의미까지 구분해 어깨번호·뜻풀이를 함께 돌려줍니다(베타).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 분석할 한국어 텍스트(필수) | |
| format | No | 결과 형식. full(전체 구조, 기본) 또는 compact(표층형/품사 요약 문자열) | |
| encoding | No | 오프셋 계산 인코딩. utf8(바이트·Go/C++)/utf16(JS·Java)/utf32(코드포인트·Python) 중 하나. 기본값 utf32 | |
| with_sense | No | true면 동형이의어 의미 구분(WSD, 베타) 결과를 형태소마다 함께 돌려준다. 어깨번호·뜻풀이·우리말샘 번호·선택 확률이 sense 에 실린다. 기본값 false | |
| auto_spacing | No | true면 분석 전 자동 띄어쓰기를 적용한다. 기본값 false | |
| auto_jointing | No | true면 자동 붙여쓰기를 적용한다. 기본값 false | |
| custom_dict_names | No | 적용할 사용자 사전 이름 목록(선택) | |
| auto_split_sentence | No | true면 문장을 자동으로 분리한다. 기본값 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the output shape depends on format (compact gives a 'surface/POS' string; full gives the full JSON structure) and that with_sense is a beta WSD feature that returns sense numbers and definitions. This is useful context, but it says nothing about performance, limits, or errors. For a read-only analysis tool with annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is four dense sentences, front-loaded with the core purpose and then the output formats and the beta option. Every sentence carries information; only the beta caveat adds mild noise.
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?
There are 8 parameters and no output schema, so the description must carry the return-value burden, and it partly does by describing both output formats and the sense payload. The remaining parameters are fully covered by schema descriptions, making this nearly complete for a read-only analysis 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 a baseline of 3 applies, but the description goes beyond the schema by giving a concrete disambiguation example for with_sense (배[腹]/배[船]/배[梨]) and by spelling out the compact-versus-full output contract. It does not explain encoding, auto_spacing, or auto_jointing, but those are fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It states a specific verb and resource: Korean morphological analysis that splits sentences into eojeol and morphemes and attaches POS tags. That distinguishes it from siblings like correct_grammar or search_dict, but it never contrasts with analyze_syntax_raw or tokenize, the closest alternatives.
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 explains what each format and with_sense value produces, which implicitly guides parameter choice, but it gives no explicit statement of when to use this tool instead of analyze_syntax_raw or tokenize. Usage is only inferable from the described outputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
후처리 없는 순수 형태소 분석을 수행합니다. 분절·품사 태깅 모델의 추론 결과를 그대로 반환하며 복합명사·복합동사 분해, 자동 띄어쓰기·붙여쓰기, 사용자 사전을 적용하지 않습니다. 모델 성능 평가나 말뭉치 재태깅처럼 후처리가 섞이지 않은 출력이 필요할 때만 쓰고, 일반적인 분석에는 analyze_syntax 를 쓰세요. with_sense=true 면 동형이의어 의미 구분(WSD, 베타) 결과도 후처리 없이 함께 돌려줍니다.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 분석할 한국어 텍스트(필수) | |
| format | No | 결과 형식. full(전체 구조, 기본) 또는 compact(표층형/품사 요약 문자열) | |
| encoding | No | 오프셋 계산 인코딩. utf8(바이트·Go/C++)/utf16(JS·Java)/utf32(코드포인트·Python) 중 하나. 기본값 utf32 | |
| with_sense | No | true면 동형이의어 의미 구분(WSD, 베타) 결과를 형태소마다 함께 돌려준다. 기본값 false | |
| auto_split_sentence | No | true면 문장을 자동으로 분리한다. 기본값 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: which post-processing layers are deliberately suppressed, that output is the raw model inference, and that with_sense routes through a beta WSD path. It omits return-shape and any latency/size caveats, which keeps it below a 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?
Four compact sentences, front-loaded with the core differentiator (no post-processing) followed by the exclusion behaviour and then the alternative route. No filler, and the most decision-relevant clause comes first.
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 analysis tool with a fully documented schema and no output schema, the description covers purpose, suppression behaviour, and sibling routing adequately. The remaining gap is that the shape of the returned morpheme/tag structure is only sketched via the schema's format hints, not described.
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 five parameters are already documented in the schema, establishing a baseline of 3. The description only adds a marginal nuance for with_sense ('후처리 없이 함께 돌려줍니다') that the schema already conveys as WSD beta; format, encoding, and auto_split_sentence get no extra treatment in prose.
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 and resource ('순수 형태소 분석 수행') plus a precise scope qualifier: no post-processing (compound decomposition, auto spacing, user dictionary). It also explicitly names the sibling it is not, analyze_syntax, so the agent can distinguish it without opening any 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 an explicit when-to-use condition ('모델 성능 평가나 말뭉치 재태깅처럼 후처리가 섞이지 않은 출력이 필요할 때만') and an explicit alternative ('일반적인 분석에는 analyze_syntax 를 쓰세요'). Both the selecting condition and the routing target are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한국어 문장의 맞춤법·띄어쓰기를 교정합니다. 교정된 문장과 교정 블록(원문/교정문) 목록을 돌려줍니다. 원문을 다시 쓰지 않고 어긋난 자리만 고치므로 글의 문체·말투가 그대로 남습니다. 고친 자리마다 근거가 되는 한글맞춤법 조항(예: 제1장 총칙 제2항)과 설명·예시가 함께 실려 오므로, 교열 근거를 대야 하는 일에 적합합니다. 띄어쓰기가 전혀 없는 음성 인식 결과·자동 자막 원고도 복원하고 문장 경계를 찾아 문장 부호를 넣습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 맞춤법/띄어쓰기를 교정할 한국어 텍스트(필수) | |
| encoding | No | 오프셋 계산 인코딩. utf8/utf16/utf32 중 하나. 기본값 utf32 | |
| treat_as_title | No | 입력 문장을 기사 등의 제목으로 취급. 기본 false | |
| custom_dict_names | No | 적용할 사용자 사전 이름 목록(선택) | |
| disable_confusion | No | 혼동모델 비활성화. 기본 false | |
| disable_bias_check | No | 혐오·차별 표현(낮잡는 말·차별 어휘) 확인 블록 비활성화. 기본 false(= 켬) | |
| disable_vx_spacing | No | 보조 용언 띄어쓰기 비활성화. 기본 false | |
| enable_contested_fix | No | 논란 여지가 있는 고침 활성화(되세요·에 있어서·복수 -들 남용 등 지침 기반 고침). 기본 false | |
| disable_caret_spacing | No | 복합명사 분리 사전 적용 비활성화. 기본 false | |
| enable_sentence_check | No | 문장 단위 점검 활성화(호응·접속·성분 생략·번역투 피동). 기본 false | |
| disable_split_sentence | No | 문장 단위 분할 비활성화. 기본 false | |
| disable_typo_correction | No | 오타(오탈자) 교정 비활성화. 기본 false | |
| enable_cleanup_whitespace | No | 불필요한 공백 정리 활성화. 기본 false | |
| enable_public_term_refine | No | 공공 용어 순화 제안 활성화(어려운 한자어·외래어·일본어 투를 쉬운 말로, 확인 블록만). 기본 false | |
| enable_limited_punctuation | No | 제약된 구두점 사용 기능 활성화. 기본 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint, yet the description adds real behavioral detail: style and tone are preserved, output includes corrected sentence plus original/corrected blocks, and each fix carries a Hangul spelling rule clause with explanation and example. It omits the hate/discriminative-expression check block, which is a notable side output an agent would want to know about.
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 sentences, front-loaded with the core action and return shape, then distinguishing traits and the special ASR case. No filler, though the sentence about rule citations and the ASR sentence could be slightly tighter.
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 15-parameter, no-output-schema tool, the description supplies the missing return-value picture (corrected text, correction blocks, rule evidence) and notes style preservation. The numerous toggle flags are left entirely to the schema, which is acceptable given 100% coverage.
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% across all 15 parameters, so the schema carries the semantics. The description only loosely gestures at a few behaviors (spacing restoration, sentence boundary punctuation) without mapping them to the many enable_/disable_ flags, 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 and resource ('한국어 문장의 맞춤법·띄어쓰기를 교정합니다') and adds the distinctive trait that it only fixes erroneous spots rather than rewriting. It never names the sibling analysis tools, but its corrective role is naturally distinct from tokenize/analyze_syntax.
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 clear usage context: suited to work where proofreading grounds must be presented, and explicitly covers the ASR/auto-caption case with no spacing at all. It does not state when to avoid the tool or point to a sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
바른 형태소 분석이 사용하는 47개 품사 태그 목록(코드·이름·대분류·소분류·enum)을 JSON 으로 돌려줍니다. analyze_syntax 결과의 품사 코드(NNG, JKS 등)를 해석할 때 참고하세요.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context — that the output is JSON containing 47 entries with code/name/major/minor/enum fields — though it doesn't state that the result is static and parameter-free.
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 tight sentences, front-loaded with what is returned, followed by the usage cue. No filler sentences.
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?
There is no output schema, but the description compensates by listing the exact fields returned, and the zero-param lookup nature is fully conveyed. Nothing an agent needs in order to call it 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?
Zero parameters, so the baseline is 4 per the rubric. The description additionally enumerates the returned field set, which is return-value information rather than parameter semantics, so it doesn't push higher.
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+resource: returns the 47 POS tags used by 바른 형태소 분석, with the exact fields included. An agent can immediately distinguish this static lookup table from the analysis/generation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to consult it when interpreting POS codes (NNG, JKS…) from analyze_syntax results, which ties it to the right sibling. It gives no explicit 'when not to use' or full alternatives list, keeping it 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.
우리말샘 사전을 자소(음소) 단위 슬롯 패턴으로 검색합니다. 완성형으로 표현할 수 없는 조건 — 초성·중성·종성 각각에 대한 조건('받침이 ㅎ인 용언', '중성이 ㅚ이고 받침 없는 1음절 어간') — 을 걸 수 있고, anchor=suffix 로 '-아지'·'-둥이'처럼 끝소리 검색도 됩니다. 각운(라임) 찾기, 초성 퀴즈·끝말잇기, 불규칙 활용 후보 수집처럼 글자를 자소로 쪼개야 풀리는 일에 씁니다. 색인 없이 사전 전체(약 100만 항목)를 훑으므로 넓은 패턴은 count_only 로 규모부터 확인하세요.
| Name | Required | Description | Default |
|---|---|---|---|
| pos | No | 품사 필터(비우면 전체, OR). 우리말샘 표기('동사'·'명사'·'보조 동사') 또는 별칭('용언'·'동사류'·'형용사류'·'체언'·'부사류'·'수식언'·'관계언') | |
| limit | No | 돌려줄 표제어 최대 개수. 기본 100, 상한 1000 | |
| anchor | No | 패턴 위치. word(표제어 전체, 기본)/prefix(앞)/suffix(뒤 — '-아지'로 끝나는 말 등)/contains(포함) 중 하나 | |
| offset | No | 건너뛸 표제어 개수(페이지 넘기기). 기본 0 | |
| pattern | Yes | 자소 슬롯 패턴(필수). 음절 리터럴('다'), {초/중/종} 슬롯({ㅅ//ㄴ}=초성ㅅ·종성ㄴ, {/ㅚ/-}=중성ㅚ·받침없음, {//ㅎ}=받침ㅎ), '*'(음절 0개 이상), '?'(음절 1개)를 조합한다. 슬롯 필드에는 자모(ㄱ), 겹받침·이중모음의 두 자모 이어쓰기(ㄹㄱ→ㄺ, ㅗㅏ→ㅘ), 선택(ㄱ|ㅋ), 문자 클래스([ㄱㄴㄷ]·[^ㄱ]·[ㄱ-ㄷ]), 종성 전용 '-'(받침 없음)/'+'(받침 있음)를 쓸 수 있다. 예: '{ㅅ//ㄴ}다' → 신다, '*{//ㅎ}다' → 낳다·넣다·내놓다 | |
| std_only | No | true면 비표준어·방언·북한어 항목을 제외한다. 기본 false | |
| count_only | No | true면 항목 없이 개수만 돌려준다(넓은 패턴의 규모 확인용). 기본 false | |
| with_definition | No | true면 표제어마다 뜻풀이·용례까지 돌려준다. 응답이 커지므로 필요한 때만. 기본 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint/openWorldHint already establish the safety profile, and the description adds genuinely new cost information: an unindexed full scan of ~1M entries and the advice to probe scale with count_only. It also flags that with_definition inflates responses. Result ordering and truncation behavior are left unstated.
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 front-loaded sentences: capability, concrete conditions/use cases, then the performance caveat. Dense but each sentence carries distinct information; no filler or repetition of the 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?
With 8 parameters all schema-documented, annotations present, and no output schema, the description covers what an agent needs to call it correctly and avoid expensive broad queries. It stops short of describing the shape of returned entries (beyond the with_definition hint), which would help given the missing output schema.
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 pattern grammar is thoroughly documented there, so the baseline applies. The description's mention of anchor=suffix with '-아지'/'둥이' largely restates what the anchor and pattern schema fields already say, adding little new parameter semantics.
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 (우리말샘 사전) plus the distinguishing mechanism — jaso/phoneme slot patterns that composed-form search cannot express. The concrete examples ('받침이 ㅎ인 용언', anchor=suffix endings like '-아지') make it unmistakable versus tokenize or analyze_syntax.
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 when-to-use scenarios — rhyme finding, 초성 quizzes, 끝말잇기, irregular-conjugation candidate collection — and a when-caution rule (broad patterns → check scale with count_only first). It does not explicitly say when to prefer a sibling such as tokenize for plain string splitting, so the routing is implied rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한국어 문장을 어절(토큰) 단위로 분리합니다. 품사 정보 없이 어절 경계만 필요할 때 쓰고, 형태소·품사가 필요하면 analyze_syntax 를 쓰세요. auto_spacing=true 를 주면 띄어쓰기가 어긋난 문장도 바로잡아 나눕니다.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 토큰화할 한국어 텍스트(필수) | |
| encoding | No | 오프셋 계산 인코딩. utf8/utf16/utf32 중 하나. 기본값 utf32 | |
| auto_spacing | No | true면 자동 띄어쓰기를 적용한다. 기본값 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the meaningful behavioral detail that auto_spacing=true repairs mis-spaced input before splitting, but it says nothing about the return shape (tokens or offsets), which matters since no output schema exists.
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 short sentences, the splitting purpose is front-loaded, followed by the sibling routing and then the auto_spacing nuance. Nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tokenizer the purpose and alternative routing are complete, but with no output schema the description never indicates what is returned (token list vs. offset tuples), which the encoding parameter implies is relevant. That gap keeps it at minimum-viable-plus.
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, but the description genuinely adds meaning: it explains that auto_spacing corrects incorrectly spaced sentences, beyond the schema's bare '자동 띄어쓰기를 적용한다'. The encoding parameter's effect on offsets is left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('한국어 문장을 어절(토큰) 단위로 분리') and immediately contrasts it with the POS-producing sibling analyze_syntax. An agent can pick it apart from the other syntax tools without opening any 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?
Explicit when-to-use ('품사 정보 없이 어절 경계만 필요할 때') and names the concrete alternative for the opposite case ('형태소·품사가 필요하면 analyze_syntax'). No inference required.
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.
correct_grammar4 fields changedInput schema / properties / disable_bias_checkAdded value: +{
+ "description": "혐오·차별 표현(낮잡는 말·차별 어휘) 확인 블록 비활성화. 기본 false(= 켬)",
+ "type": "boolean"
+}Input schema / properties / enable_contested_fixAdded value: +{
+ "description": "논란 여지가 있는 고침 활성화(되세요·에 있어서·복수 -들 남용 등 지침 기반 고침). 기본 false",
+ "type": "boolean"
+}Input schema / properties / enable_public_term_refineAdded value: +{
+ "description": "공공 용어 순화 제안 활성화(어려운 한자어·외래어·일본어 투를 쉬운 말로, 확인 블록만). 기본 false",
+ "type": "boolean"
+}Input schema / properties / enable_sentence_check / descriptionPrevious value: -"문장 단위 점검 활성화. 기본 false"New value: +"문장 단위 점검 활성화(호응·접속·성분 생략·번역투 피동). 기본 false"analyze_syntaxanalyze_syntax_rawcorrect_grammarlist_pos_tagssearch_dicttokenize
Add one secure layer between your agents and this server.