Feature Request: Add glossary write tools (create-glossary, update-glossary, delete-glossary)

[shuji-bonji]

Summary

The DeepL MCP Server currently provides glossary read tools (list-glossaries, get-glossary-info, get-glossary-dictionary-entries) and supports glossaryId in translate-text. However, there are no tools to create, update, or delete glossaries.

This means users must leave the MCP ecosystem to register glossaries via direct API calls or the DeepL website, then return to use the glossaryId in translate-text. Adding glossary write tools would close this gap and enable fully MCP-native glossary workflows.

Related: #11 also requests glossary integration for document translation. Together, these suggest broader community demand for completing glossary support in the MCP server.

Use Case: Technical Specification Translation

I built a workflow that translates the PDF specification (ISO 32000-2) into Japanese with consistent terminology. The workflow combines two MCP servers:

1. pdf-spec-mcp — extracts 71 defined terms from the specification
2. deepl-mcp-server — translates specification sections with glossary-enforced terminology

The full workflow and translation comparison results are documented here:
👉 pdf-spec-mcp/examples/translation-glossary

I also shared this workflow on the DeepL Bridges community:
👉 From Bulk Translation to Terminology Consistency

Current workflow (with the gap):

pdf-spec-mcp get_definitions → 71 terms
       ↓
  Classify & format → TSV file (56 entries)
       ↓
  ❌ curl POST /v2/glossaries  ← Must leave MCP ecosystem
       ↓
  glossary_id obtained
       ↓
  ✅ deepl-mcp translate-text + glossaryId  ← Back in MCP

Ideal workflow (if write tools existed):

pdf-spec-mcp get_definitions → 71 terms
       ↓
  Classify & format → entries
       ↓
  ✅ deepl-mcp create-glossary  ← Stays in MCP
       ↓
  glossary_id returned
       ↓
  ✅ deepl-mcp translate-text + glossaryId

Measurable Impact

With the glossary, translation quality improves significantly:

Aspect	Without Glossary	With Glossary
null keyword	NULL / Null (inconsistent)	null (consistent — correct PDF keyword casing)
"entries"	項目 (generic)	エントリー (domain term)
Sentence omission	Second sentence dropped	Fully translated

(Full before/after comparison: README)

Proposed Tools

Based on the existing DeepL API (v2/v3) and the deepl-node SDK, I suggest adding three tools:

create-glossary

Create a new glossary with term entries.

Parameters:

• name (string, required): Glossary name
• sourceLangCode (string, required): Source language code (e.g., "en")
• targetLangCode (string, required): Target language code (e.g., "ja")
• entries (string, required): Tab-separated entries (TSV format) or JSON object
• entriesFormat (string, optional): "tsv" (default) or "csv"

Returns: glossary_id, name, entry_count

update-glossary-dictionary

Update entries in an existing glossary dictionary.

Parameters:

• glossaryId (string, required): Glossary ID
• sourceLangCode (string, required): Source language
• targetLangCode (string, required): Target language
• entries (string, required): Updated entries (TSV/JSON)

Returns: Updated glossary info

delete-glossary

Delete a glossary.

Parameters:

• glossaryId (string, required): Glossary ID

Returns: Confirmation

API Support

These operations are fully supported by the DeepL API:

Operation	v2 Endpoint	v3 Endpoint	deepl-node SDK
Create	POST /v2/glossaries	POST /v3/glossaries	createMultilingualGlossary()
Update	(recreate)	PUT /v3/glossaries/{id}/dictionaries	updateMultilingualGlossaryDictionary()
Delete	DELETE /v2/glossaries/{id}	DELETE /v3/glossaries/{id}	deleteMultilingualGlossary()

Workaround

Currently, I work around this limitation using a shell script that calls the DeepL API directly:
create-glossary.sh

This works, but it breaks the MCP workflow — users must switch between their MCP client and a terminal. Adding native tools would eliminate this friction.

Context

• The deepl-node SDK already implements the full glossary CRUD — the MCP server could leverage it directly
• Third-party MCP services (e.g., TranslateSheet) already offer create_glossary as an MCP tool, suggesting real demand
• Glossary creation is a natural complement to the existing read tools — having list-glossaries and get-glossary-dictionary-entries without create-glossary is an incomplete experience