Skip to main content
Glama
jaykim429

report-mcp

by jaykim429
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

report-mcp

사용자가 업로드한 문서 양식(DOCX / HWP / HWPX / PDF)에 챗봇이 생성한 내용을 채워 넣고 원본 서식·표·이미지를 그대로 보존한 채 파일로 저장하는 Model Context Protocol 서버.

  • 입력: 사용자가 첨부한 빈 양식 파일 + 챗봇의 답변

  • 출력: 양식의 디자인을 그대로 따른 보고서 파일 (DOCX→DOCX, HWP/HWPX→HWPX)

  • 핵심 가치: "재생성"이 아니라 원본 IR을 그대로 수정. 글자 크기·색·표·이미지·페이지 레이아웃 손상 없음.

동작 흐름

사용자 첨부 양식.hwpx        챗봇이 만든 답변 텍스트
        ↓                              ↓
    describe / inspect          ←──→  목차·셀·길이 한도 파악
    list_template_targets
        ↓                              ↓
    edits 목록 (target_id, new_text)
        ↓
    fill_and_save  →  결과.hwpx (원본 서식 유지, 내용만 교체)

Related MCP server: Word MCP Server

노출되는 도구 (7개)

도구

용도

register_template(template_b64, template_filename)

템플릿을 서버에 캐싱해서 template_id 받음. 같은 파일에 여러 도구 호출 시 base64 재업로드 회피

unregister_template(template_id)

캐시 해제 (자동 만료 1시간)

describe_template(...)

한눈 요약 — 포맷, 페이지·표·이미지 개수, 상위 단락

inspect_template(..., start, limit)

페이지네이션된 단락 보기

list_template_targets(..., target_kinds, start, limit)

편집 가능한 모든 위치 + target_id + text_hash + 길이 정보

fill_and_save(..., edits, ...)

검증 → 필터 → 적용 → 저장

convert_to_hwpx(...)

HWP/HWPX/HWTX → HWPX 변환 (편집 없이)

입력·출력 모드 (파일시스템 격리 대응)

모든 도구는 두 가지 방식 중 하나로 템플릿을 받습니다:

  • template_path — 서버가 실행되는 머신의 파일 경로 (예: C:/Users/.../template.hwpx). 빠르고 복사 비용 없음.

  • template_b64 + template_filename — base64 인코딩된 원본 바이트 + 원본 파일명 (예: template_b64="UEsDBBQ...", template_filename="template.hwpx"). 챗봇 세션과 MCP 서버가 다른 파일시스템에 있을 때 (예: Anthropic 샌드박스 ↔ 사용자 Windows) 사용.

fill_and_save는 추가로:

  • output_path — 서버 머신에 결과 파일 저장

  • return_output_bytes=True — 응답에 output_b64 (base64 바이트) + output_size_bytes 포함. 챗봇이 사용자에게 직접 전달 가능.

챗봇 세션(샌드박스)에서 호출 예

import base64
file_bytes = open("template.hwpx", "rb").read()
b64 = base64.b64encode(file_bytes).decode("ascii")

# 1. 양식 분석
desc = describe_template(template_b64=b64, template_filename="template.hwpx")

# 2. 편집 가능 위치 조회
targets = list_template_targets(template_b64=b64, template_filename="template.hwpx")

# 3. 챗봇이 edits 구성 후 적용
result = fill_and_save(
    template_b64=b64,
    template_filename="template.hwpx",
    edits=[...],
    return_output_bytes=True,
)
output_bytes = base64.b64decode(result["output_b64"])
# output_bytes를 사용자에게 첨부로 전달

설치

사전 요구사항

  • Python 3.13+ (document-processor 의존성)

  • JDK 11+ (HWP 또는 PDF 입력 시에만 필요. DOCX·HWPX만 쓸 거면 생략 가능)

  • git (document-processor를 git에서 직접 받아옴)

프로젝트 설치

git clone https://github.com/jaykim429/report-mcp.git
cd report-mcp
py -3.13 -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -e .

document-processor의 알려진 _edited 누적 버그는 apply_library_patches()가 import 시 자동 monkey-patch하므로 별도 조치 불필요. 더 영구적인 fix를 원하면 patches/document_processor_edited_cumulation.patch 적용.

MCP 클라이언트 등록

Claude Code (프로젝트 단위)

.claude/mcp_servers.json이 이미 포함돼 있어 이 폴더에서 Claude Code를 실행하면 자동 인식.

Claude Desktop (전역)

%APPDATA%\Claude\claude_desktop_config.json에 추가:

{
  "mcpServers": {
    "report-mcp": {
      "command": "C:\\path\\to\\report-mcp\\.venv\\Scripts\\python.exe",
      "args": ["-m", "report_mcp"],
      "env": { "PYTHONIOENCODING": "utf-8" }
    }
  }
}

저장 후 Claude Desktop 재시작하면 도구 메뉴에 4개 도구가 표시됨.

챗봇이 받는 응답 표준

모든 도구는 다음 필드를 포함한 dict를 반환:

status        : ok / dry_run_ok / 그 외 13종 실패 상태
recovery_hint : 실패 시 챗봇이 다음에 무엇을 할지 (실패 target_id + 현재 hash 포함)

정의된 status

status

상황

ok

정상 적용

dry_run_ok

검증만 통과 (파일 안 씀)

not_found

템플릿 경로 없음

bad_argument

잘못된 인자 (음수 start, 잘못된 target_kinds, 디렉터리 경로 등)

edit_parse_failed

edits 스키마 오류

duplicate_target_id

같은 target_id에 두 편집

style_field_target_mismatch

run 속성을 paragraph 타겟에 (또는 반대)

validation_failed

hash mismatch 등 (failed_targets에 상세)

output_extension_mismatch

출력 확장자가 템플릿 포맷과 안 맞음

format_not_writable

PDF 출력 등

format_requires_java

PDF·binary HWP 입력 시 Java 미설치

file_error / permission_error

OS-level 파일 문제

apply_failed / runtime_error

그 외 라이브러리 예외

자체 흡수한 함정 (챗봇은 신경 쓸 필요 없음)

  1. 컨테이너/자식 편집 충돌 자동 해소 — 단락과 셀(또는 그 안의 run)을 동시에 편집해도 우선순위 결정 후 충돌 항목을 skipped_redundant_edits로 안내.

  2. 중복 target_id 사전 검사 — 챗봇이 같은 위치에 두 번 보내면 즉시 duplicate_target_id 응답.

  3. 출력 확장자 검증 — .pdf로 잘못 보내도 output_extension_mismatch로 안전 거절.

  4. 방어적 타입 처리 — edits=None / edits="string" 모두 깨끗하게 처리.

  5. EAW 인지 길이 가드레일 — 한글 한 글자는 2 display cell로 계산해서 length_warnings에 정확히 반영.

  6. document-processor _edited 누적 버그 monkey-patch — pip 재설치 후에도 idempotent하게 유지.

  7. in-place 덮어쓰기 — template_path == output_path 케이스에서 임시 파일 경유하여 안전 처리.

프로젝트 구조

report-mcp/
├── src/report_mcp/
│   ├── server.py        FastMCP wiring + 4개 도구 정의
│   ├── documents.py     TemplateReader 클래스 (읽기 API)
│   ├── pipeline.py      FillPipeline 클래스 (검증→필터→적용)
│   ├── length.py        LengthGuardrail 클래스 (EAW 폭 계산)
│   ├── errors.py        ExceptionClassifier 클래스
│   ├── responses.py     ok/error/not_found 팩토리
│   └── patches.py       document-processor monkey-patch
├── tests/               10개 probe·test 스위트
├── archive/             일회용 데모 스크립트
├── patches/             document-processor 패치 파일
└── .claude/             Claude Code MCP 등록 설정

테스트

.\.venv\Scripts\Activate.ps1
foreach ($f in Get-ChildItem tests\*.py) { python $f.FullName }

10개 스위트 항목:

  • verify_patch_no_batching.py — 라이브러리 패치 검증 (32 edits 단일 호출)

  • probe_edge_cases.py — 빈 편집 / 중복 / 미지 target / 제자리 덮어쓰기 등 10건

  • probe_pdf_input.py — Java 없을 때 PDF 입력의 깨끗한 거절

  • probe_round_two/three/four/five.py — describe + StructuralEdit + StyleEdit + MCP transport + stdout 청정 등 누적 검증

  • probe_real_defects.py — 6대 본질적 결함 회귀 방지

  • test_mcp_production_ready.py — 서버 instructions / 도구 docstring / batching / cell-conflict 등 게이트

  • test_length_guardrail.py — EAW 길이 경고

알려진 제약

  • HWP (binary, .hwp): Java 11+ 필요. 출력은 HWPX로만 가능.

  • PDF: 입력만 가능. 출력 불가능 (라이브러리 미지원). DOCX로 저장하도록 요청 권장.

  • 이미지 제거: 현재 미지원. 라이브러리에 remove_image 구조 편집 없음.

  • 표시 폭 휴리스틱: max_recommended_chars는 EAW 기반 근사. 비례 글꼴에서는 정확도 한계.

라이선스 / 의존 라이브러리

이 프로젝트의 핵심 기능은 CGINSIDE-ROOKIES/document-processor에 의존합니다. 사내 레포 접근 권한이 필요합니다.

관련 문서

Available Tools

4 tools
describe_templateA

One-call summary of a template's overall shape — page count, target counts by kind, and a small text sample.

USE WHEN: first encounter with a template. You want to know format, page count, presence of tables/images, and a sample of headings before pulling the full target list. DO NOT USE WHEN: you already need the full edit list — go straight to list_template_targets().

Provide the template either as template_path or as template_b64 + template_filename.

Returns: dict with source_doc_type, total_paragraphs, target_counts (per target_kind), page_count, top_paragraphs (first 5 non-empty), has_tables, has_images.

ParametersJSON Schema
NameRequiredDescriptionDefault
template_pathNo
template_b64No
template_filenameNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains the return format and input constraints, but does not explicitly state whether the operation is read-only or has side effects. However, the description is sufficiently transparent about what the tool does.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear first sentence stating purpose, followed by usage guidelines, input instructions, and a list of return values. Every sentence adds value.

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 simplicity, the description provides complete context including inputs, outputs (matching the output schema), and when to use it. It adequately differentiates from sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains that either template_path or template_b64+template_filename can be used, adding meaning beyond the schema. However, it does not define each parameter's semantics, so the compensation is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as a one-call summary of a template's overall shape, listing specific outputs like page count and target counts. It also differentiates from sibling tools by explicitly mentioning when to use list_template_targets instead.

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 includes explicit 'USE WHEN' and 'DO NOT USE WHEN' sections, providing clear guidance on when to use the tool and when to use the alternative list_template_targets.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fill_and_saveA

Apply a batch of edits to the template and write/return the result.

USE WHEN: You have called list_template_targets() and composed an edits list mapping the chatbot's generated content into the right target_ids. DO NOT USE WHEN: You have not yet fetched target_ids and text_hashes from list_template_targets() — fill_and_save will fail validation.

INPUT modes: provide the template via template_path OR template_b64 + template_filename.

OUTPUT modes: provide output_path (server-side write) OR set return_output_bytes=True (response includes output_b64). Required unless dry_run=True. Use bytes when the chatbot is in a different filesystem than the MCP server.

Each edit dict must include edit_type ("text" | "structural" | "style") plus the fields required for that type:

  • text: target_id, expected_text_hash, new_text (+ optional target_kind, reason)

  • structural: operation, target_id (+ position, text/rows/values, row_index, column_index)

  • style: target_id (+ any style fields: bold, color, font_size_pt, etc.)

STYLE EDIT TARGETING: Run-level fields (bold / italic / underline / color / font_size_pt) must use target_kind='run' against a run target. Paragraph-level fields (paragraph_align / left_indent_pt / etc.) use target_kind='paragraph'. Mixing the two raises a clean style_field_target_mismatch response.

BUILT-IN ROBUSTNESS:

  1. Auto-skip of container/child edit conflicts (cell↔paragraph, paragraph↔run). Skipped entries in skipped_redundant_edits.

  2. Pre-check for duplicate target_id.

  3. Output extension validation.

  4. Defensive type coercion (None edits → empty list).

Output format follows the template: DOCX→DOCX, HWP/HWPX→HWPX. PDF input cannot be written back as PDF.

Returns: dict with

  • status: ok / dry_run_ok / validation_failed / apply_failed / edit_parse_failed / not_found / duplicate_target_id / style_field_target_mismatch / format_requires_java / file_error / permission_error / runtime_error / bad_argument / output_extension_mismatch / format_not_writable

  • output_path OR output_b64 + output_size_bytes (status=ok)

  • length_safe, length_warnings, skipped_redundant_edits

  • recovery_hint (when status != ok)

  • edits_applied

ParametersJSON Schema
NameRequiredDescriptionDefault
template_pathNo
editsNo
output_pathNo
dry_runNo
template_b64No
template_filenameNo
return_output_bytesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: input/output modes, edit type requirements, style targeting rules, built-in robustness (conflict skipping, duplicate checks, type coercion), output format limitations, and an exhaustive list of possible status values and return fields.

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 long but well-organized with sections (USE WHEN, INPUT modes, OUTPUT modes, edit dict structure, STYLE EDIT TARGETING, BUILT-IN ROBUSTNESS). Every sentence adds value, though it could be slightly more concise.

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 complexity (7 parameters, edit types, multiple modes) and lack of annotations, the description covers all necessary aspects: preconditions, input/output options, error handling, and return format. The presence of an output schema (not shown but flagged) makes the return description somewhat redundant but still 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 coverage is 0% (only titles), but the description adds comprehensive meaning for all 7 parameters, including the complex edits structure with required fields per edit type, and alternative input/output modes. It fully compensates for the lack of schema descriptions.

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 'Apply a batch of edits to the template and write/return the result,' which is a specific verb+resource. It distinguishes itself from sibling tools like list_template_targets, describe_template, and inspect_template by focusing on writing/returning the modified template.

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 provides explicit 'USE WHEN' and 'DO NOT USE WHEN' sections, advising to call list_template_targets first and warning that fill_and_save will fail without proper target_ids. It also details when to use different input/output modes, making usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_templateA

Read a template's paragraphs (paginated) so the chatbot can understand its structure before composing edits.

USE WHEN: You want a sequential, page-aware view of the template — e.g. to scan section headings, see how bullets are organized, or quote surrounding context for the user. DO NOT USE WHEN: You just need a flat list of every editable spot — use list_template_targets() instead.

Provide the template either as template_path (file on the server's machine) or as template_b64 + template_filename (inline base64 bytes for cross-filesystem calls). Paginate large documents with start + limit; next_start in the response says where to resume.

ParametersJSON Schema
NameRequiredDescriptionDefault
template_pathNo
template_b64No
template_filenameNo
startNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It correctly identifies the tool as read-only ('Read'), explains pagination (start, limit, next_start), and describes two methods for providing a template (path or base64+filename). Minor omission: no mention of what happens if both are provided or error handling, but still adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a purpose sentence, then usage guidelines, then parameter explanation. No unnecessary words, and important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (so return format is covered), the description provides sufficient context: purpose, usage, parameter semantics. It doesn't discuss error conditions or edge cases, but for a read tool with moderate complexity, it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the purpose of template_path vs. template_b64+template_filename as alternative inputs, and describes start and limit for pagination. It could be more explicit about default values, but overall adds 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 the tool reads a template's paragraphs in a paginated way to understand structure before editing. It uses a specific verb ('Read') and resource ('template's paragraphs'), and provides context for its use. It also distinguishes itself from the sibling tool 'list_template_targets'.

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 includes a 'USE WHEN' and 'DO NOT USE WHEN' section, providing clear guidance on when to use this tool and when to use an alternative (list_template_targets). This is exemplary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_template_targetsA

List every editable target in the template (paragraphs, runs, cells, tables, images) so the chatbot can build a precise edit list.

USE WHEN: Canonical first call before fill_and_save. You need target_ids

  • text_hashes to construct edits, and char_count / display_width / max_recommended_chars to keep generated content within container limits. DO NOT USE WHEN: You only need a human-readable overview — use inspect_template instead.

Provide the template either as template_path or as template_b64 + template_filename. Filter with target_kinds (any subset of {paragraph, run, cell, table, image}); leave None for all kinds. Paginate via start + limit; next_start is non-None when more targets remain. (max_targets is a deprecated alias for limit.)

Each target carries (where applicable):

  • target_id, target_kind, current_text, text_hash

  • char_count (code points), display_width (EAW-aware), max_recommended_chars

  • page_number

  • parent_paragraph_id / parent_table_id — the container

  • row_index / column_index / rowspan / colspan — for cells

ParametersJSON Schema
NameRequiredDescriptionDefault
template_pathNo
template_b64No
template_filenameNo
target_kindsNo
startNo
limitNo
max_targetsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description must carry behavioral info fully. It describes pagination, filtering, deprecated parameters, and returned fields. It is non-destructive but doesn't explicitly state read-only nature; still, transparency is high.

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?

Well-structured with sections, front-loaded purpose, and concise sentences. Slightly verbose in listing returned fields but each line adds value.

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 presence of an output schema (not shown), the description covers all necessary context: usage scenario, parameter details, pagination behavior, and returned fields. Complete and actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds rich semantics: explains alternative ways to provide template (path vs b64+filename), allowable target kinds, pagination start/limit with note on next_start, and deprecation alias for limit. Greatly aids correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists editable targets in a template for building an edit list, distinguishing it from siblings like inspect_template (human-readable overview) and fill_and_save (later step).

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?

Explicit 'USE WHEN' and 'DO NOT USE WHEN' conditions are given, directing to use as first call before fill_and_save and to avoid if a human-readable overview suffices, recommending inspect_template instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: describe_template gives an overview summary, inspect_template provides a page-aware structural view, list_template_targets enumerates editable elements, and fill_and_save applies edits. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to remember (describe_template, fill_and_save, inspect_template, list_template_targets).

Tool Count5/5

With exactly 4 tools, the set is well-scoped for a template editing workflow. It covers the essential operations—summarizing, inspecting, listing targets, and applying edits—without unnecessary bloat.

Completeness4/5

The tool set covers the core workflow of understanding and modifying templates. Minimally missing an undo or versioning capability, but for the stated purpose of editing templates, it is reasonably complete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • GongMun Doctor MCP

    sinmb79
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables secure local proofreading of Korean official documents (.hwpx/.hwp) using 3-layer AI correction for spelling, grammar, and official document style. Provides 50 administrative document templates for generating standardized official correspondence without cloud dependencies or API keys.
    23
    MIT

Latest Blog Posts

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/jaykim429/report-mcp'

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