DeepL MCP Server

Official

by DeepL

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v1.3.3
Disambiguation5/5
Each tool targets a distinct resource or action: language listing, translation, rephrasing, glossary listing/detail/entries, and style rule listing/detail/custom instructions. The only pairs that could be confused (writing styles vs tones, style rule vs custom instruction) are distinguished by their descriptions, so ambiguity is minimal.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using lowercase with hyphens (get-, list-, translate-, rephrase-). There are no mixed conventions or vague verbs like 'process'.
Tool Count5/5
13 tools is within the ideal 3-15 range. The count reflects the breadth of DeepL features (translation, rephrasing, glossaries, style rules) without being overwhelming.
Completeness3/5
Core translation and rephrasing workflows are covered (language lists, translate text/document, rephrase, styles/tones). However, the server only offers read operations for glossaries and style rules (list/get), with no create/update/delete, leaving a notable gap for managing these resources.
Average 4/5 across 13 of 13 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 45 commits in the last 12 weeks
- Last stable release on September 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only mentions use of the DeepL API, but does not disclose output file handling, potential overwrites, external rate limits, or any side effects. This is inadequate for a tool that reads and writes files.
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 a single, direct sentence with no filler or repetition, making it concise and easy to scan. However, it is so brief that it borders on under-specification, missing key behavioral details that could be included without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no output schema, and no annotations, yet the description provides almost no contextual information beyond the basic translation action. It does not explain output file handling, format conversions, or integration with other tools like list-style-rules or list-glossaries.
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 coverage is 100%, with each parameter having a description, so the baseline is 3. The tool description itself adds no additional meaning beyond what the schema provides; it does not clarify parameter formats or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'translate' and resource 'document file', clearly stating the tool's function. However, it does not distinguish this from sibling tools like translate-text or rephrase-text, leaving some ambiguity about which tool to use for document files specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No context is given for when document translation is preferred over text translation, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only states the core function and external API, without covering return format, side effects, rate limits, or authentication requirements, leaving significant gaps.
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 a single, front-loaded sentence that directly states the tool's purpose with no redundant words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should explain expected return values and edge cases (e.g., array handling is in schema, but not what the tool returns). The minimal description leaves the tool's behavior incomplete for an agent to know what to expect.
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?
The input schema provides descriptions for all parameters (100% coverage), so the description adds no additional meaning beyond what is already in the schema. Baseline 3 is appropriate because the schema handles the heavy lifting.
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 rephrases text, optionally into a different language, and specifies the API. This distinguishes it from the sibling 'translate-text' tool by focusing on rephrasing rather than direct translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when rephrasing is needed, but it does not explicitly mention alternatives like 'translate-text' or provide when-not-to-use guidance. The context is clear but not differentiated from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description relies on 'Get list' to convey a read-only operation. It doesn't mention return format, ordering, authentication, or any other behavioral traits, but for a simple list endpoint this is minimally 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?
A single sentence that front-loads the purpose and contains no filler. Every word earns its place.
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?
For a simple parameterless list tool, the description adequately explains that it returns writing styles for rephrasing. However, given sibling tools like get-writing-tones, some disambiguation would be helpful, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers all (none) parameters. With 0 params, the baseline is 4, and the description doesn't need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get list' and identifies the resource as 'writing styles' used by DeepL when rephrasing text. It is clear and somewhat distinguishes from siblings by mentioning the rephrasing context, but it doesn't explicitly contrast with get-writing-tones or list-style-rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the phrase 'while rephrasing text' implies it's for use before rephrasing. It lacks clear exclusions or references to sibling tools like get-writing-tones or list-style-rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions that the tool returns 'full detail' including 'configured rules and custom instructions', which is useful context, but it does not disclose potential errors, authorization requirements, or read-only semantics beyond the verb 'get'. This is reasonable for a read operation but lacks depth.
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 a single, front-loaded sentence that efficiently communicates the tool's purpose and key detail. No unnecessary words or redundant information.
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?
For a simple single-parameter get tool with no output schema, the description adequately indicates what the tool returns (full detail including configured rules and custom instructions). It could also mention error handling or differences from related tools, but given the low complexity, the description is nearly complete.
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?
The input schema already defines 'styleId' as 'The unique identifier of the style rule' with 100% coverage. The description only says 'Given an id', which adds no additional semantic meaning. Since schema coverage is complete, the baseline of 3 is appropriate.
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 operation ('get') and the resource ('single style rule'), and distinguishes it from sibling tools like list-style-rules by focusing on a single item and 'full detail'. This is a specific verb+resource combination that leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Given an id' implies that this tool is used when you have a specific style rule ID and want its complete details, but no explicit comparison or exclusion of alternatives like list-style-rules or get-custom-instruction is provided. The usage context is implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must convey safety and behavior. 'Get' implies a read-only operation, which is useful but not elaborated. It does not mention whether authentication is required, what format the list takes (e.g., codes or names), or any potential side effects, though for a simple list retrieval, this may be sufficient. No contradiction with annotations exists.
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 a single, front-loaded sentence that directly states the action and target. It contains no unnecessary words or repetition. For a tool with no parameters, this level of conciseness is ideal.
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?
The tool has no parameters, no output schema, and simple functionality. The description is sufficient for an agent to know what the tool does, though it does not specify the exact return structure (e.g., language codes vs. names). Given the low complexity, this is nearly complete, but a single detail about the output format would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is effectively complete (100% coverage). The description adds no parameter information, but none is needed. Per the rubric, with 0 parameters the baseline is 4, and the description does not detract from it.
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 function: 'Get list of available source languages for translation.' It uses a specific verb ('Get') and resource ('source languages'), and the phrase 'for translation' provides context. This distinguishes it from the sibling tool 'get-target-languages' without needing to read the sibling's description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—whenever a list of source languages is needed—but does not explicitly mention alternatives or exclusion criteria. The presence of sibling tools like 'get-target-languages' suggests a related counterpart, but the description does not guide the agent to choose between them explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states that the tool returns a list, which is safe and read-only, but adds no detail about response format, possible empty results, or any special behavior. For a simple getter, this is minimally 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It immediately communicates the purpose and uses a consistent verb+resource structure, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is sufficiently complete. It names the resource and purpose, and no return format or error handling is necessary for such a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description does not need to explain any. With schema coverage at 100% (all parameters accounted for), the baseline of 4 applies; no additional parameter semantics are required.
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 action ('Get list') and the specific resource ('available target languages for translation'). It distinguishes from the sibling 'get-source-languages' by explicitly naming 'target languages', making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool — when you need target languages rather than source languages — given the sibling 'get-source-languages'. However, it does not explicitly state when to choose this over alternatives or mention any prerequisites or exclusions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. The verb 'Get' implies a read-only operation, but the description does not explicitly disclose return format, error behavior, or whether the list is static or dynamic. It adds minimal context beyond the name.
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 a single, front-loaded sentence with no redundant wording, earning maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides adequate context by identifying the resource and its use case. It could mention the output format explicitly, but the high-level 'list' is sufficient for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, and the description correctly implies no parameters are needed. Since there are zero parameters, the baseline is 4, and the description does not need to add parameter details.
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 uses a specific verb ('Get list') and clearly identifies the resource ('writing tones') and the context ('while rephrasing text'), which distinguishes it from sibling tools like get-writing-styles that concern styles rather than tones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving tones used in rephrasing but does not explicitly state when to prefer it over get-writing-styles or other listing tools. It provides clear context but lacks exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output metadata fields (id, name, language, timestamps) and the relationship to translation contexts. However, it does not disclose pagination behavior, default values, or the effect of the 'detailed' parameter on the response, which are relevant behavioral aspects for a list endpoint.
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 three sentences long and every sentence adds value: the first defines the purpose and return fields, the second gives context, and the third directs users to the appropriate single-rule tool. There is no redundancy or filler.
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 that there is no output schema, the description adequately explains what the tool returns (metadata fields). It also provides enough context for a simple list tool with optional pagination parameters that are well-documented in the input schema. A slightly higher score would require more detail on pagination defaults or the precise behavior of the 'detailed' flag, but the schema already covers those.
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?
All three parameters are already described in the JSON schema with 100% coverage, so the baseline is 3. The description adds no additional parameter-level semantics beyond what the schema provides, but it doesn't need to because the schema descriptions are sufficient.
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 style rules with specific metadata fields (id, name, language, timestamps) and explicitly distinguishes it from get-style-rule, which fetches details for a single rule. This makes the purpose unambiguous and differentiated from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that style rules are used in translation and points users to get-style-rule for fetching a single rule's configured rules and instructions. It provides clear context for when to use this listing tool versus the alternative, though it doesn't mention all potential sibling tools or edge cases like pagination usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the read-only action 'Get' but does not disclose error behavior, permission needs, or return format. However, the tool is a simple getter, and the description is not misleading.
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 two sentences with no fluff. The first sentence states the purpose, the second gives usage guidance, and every word earns its place.
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?
For a simple getter with two IDs, the description provides necessary context by referencing the parent style rule and how to discover instruction IDs. It doesn't describe return values, but no output schema exists; still, the description is fairly complete for its complexity.
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 100% with clear descriptions for styleId and instructionId. The tool description adds no extra parameter meaning, so baseline 3 applies.
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 'Get a single custom instruction belonging to a style rule,' identifying the exact verb, resource, and scope. It distinguishes from siblings like get-style-rule and list-style-rules by specifying it fetches a single item.
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 says 'Use the get-style-rule tool to find out which custom instructions a style rule contains,' providing a clear alternative for listing instructions. This tells the agent when to use this tool versus the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the underlying API (DeepL), a constraint (glossary forces source language), and a tip (context improves accuracy). However, it does not mention authentication, rate limits, error behavior, or how array inputs are reflected in the response. Still, it adds meaningful usage constraints beyond the schema.
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?
Three sentences, front-loaded with the primary purpose. Every sentence earns its place: the first states what it does, the second guides parameter use, and the third clarifies a non-obvious rule and points to a sibling tool. No fluff or repetition.
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?
For a tool with 10 parameters, no output schema, and no annotations, the description covers key behavioral nuances (glossary constraint, optional parameters, glossary lookup path). It does not describe the return format, but the schema already explains array handling ('handled independently'), and translation output is intuitive. The guidance is sufficient for an agent to use it correctly in most scenarios.
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 coverage is 100%, so the baseline is 3. The description adds value by explaining the interaction between glossaryId and sourceLangCode (must specify source when glossary is used) and points to list-glossaries for resolving names. This goes beyond the schema's field-level descriptions, which don't mention the coupling.
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 opens with a clear verb+resource: 'Translate text to a target language using DeepL API.' This immediately distinguishes it from sibling tools like translate-document (which handles documents) and rephrase-text (which rewrites rather than translates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete guidance: 'Review all available optional parameters and use those applicable to your scenario' and specifies that a glossary requires the source language. It names an alternative tool (list-glossaries) for resolving glossary names to IDs, which helps with tool selection. It does not explicitly contrast with translate-document, but the text focus is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that the tool retrieves entries for a single dictionary, not an entire glossary, and clarifies the relationship between glossaries and dictionaries. This is a meaningful behavioral trait beyond the bare function name. However, it does not mention potential side effects (which are likely none) or error conditions, but for a simple read operation, the transparency is 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. It opens with the primary purpose, then provides the essential glossary/dictionary context, and ends with actionable usage instructions. Every sentence earns its place, and the information is front-loaded. Despite a minor typo ('consists one of one or more'), the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, but the description covers the essential context: what the tool does, how it relates to the overall glossary concept, and how to use it correctly in multi-dictionary scenarios. It does not describe return format or pagination, but for a straightforward retrieval tool, the description is sufficiently complete for an agent to decide when and how to invoke it. A small gap is the lack of explicit mention of what happens if no entries exist, but this is not critical.
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?
The input schema already provides full descriptions for all three parameters (glossaryId, sourceLangCode, targetLangCode) with 100% coverage, including format examples. The tool description adds conceptual context about language pairs and directions, which aligns with the parameters but does not add significant new semantics beyond what the schema already offers. Baseline 3 is appropriate because the schema does the heavy lifting.
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 function: 'Retrieve all the entries from a given glossary dictionary.' It also distinguishes this from sibling tools by explaining that a glossary consists of dictionaries, and this tool operates on a single dictionary for a specific language pair. This is a specific verb+resource description that avoids confusion with get-glossary-info or list-glossaries.
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 provides usage guidance: 'To retrieve all entries for a glossary with multiple dictionaries, use the get-glossary-info or list-glossaries tool to find out what dictionaries it contains, then use this tool for each dictionary.' This tells the agent when to use this tool, how to discover required parameters, and mentions alternative tools, offering clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly notes that the tool does not fetch glossary entries, which is a key behavioral constraint, and clarifies the exact metadata returned. While it does not discuss error handling or authentication, for a read-only metadata retrieval that is sufficient to meet most expectations.
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 two concise sentences, front-loaded with the core purpose and followed by a valuable scope clarification. Every word earns its place, with no repetition or filler.
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?
For a simple single-parameter tool with no output schema or annotations, the description is complete enough: it states what it returns, what it does not return, and points to the correct sibling for entries. It could optionally mention error behavior or the relationship to 'list-glossaries', but the core context is well covered.
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?
The schema already fully describes the only parameter (glossaryId as a unique identifier string), so the description adds little beyond the schema. It uses 'Given an id' but doesn't elaborate on format, constraints, or behavior related to the parameter, which is acceptable given 100% schema coverage.
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 function with a specific verb ('get metadata') and resource ('glossary'), and explicitly lists the returned metadata (name, available dictionaries, creation time). It also distinguishes itself from sibling tool 'get-glossary-dictionary-entries' by stating what it does not do, making its purpose unmistakable.
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 says when to use this tool (to get glossary metadata) and provides an alternative ('Use the get-glossary-dictionary-entries tool to fetch entries'), giving direct usage guidance and differentiating from a likely alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states what the tool returns (metadata) and what it excludes (entries). While it does not mention read-only status or pagination, the behavior is sufficiently transparent for a simple list operation.
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 two sentences with no redundant information. It front-loads the primary purpose, then adds a crucial exclusion and referral to a sibling tool. Every word earns its place.
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 (no parameters, no output schema), the description is complete. It explains what the return contains, clarifies the scope ('all glossaries'), sets expectations about entries, and provides a path to a related tool. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description adds no parameter-specific details since there are none, but it does enrich the understanding of the output, which is relevant for parameterless list operations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists all glossaries with specific metadata (name, dictionaries, creation time), and clearly distinguishes itself from sibling tools by noting it does not fetch glossary entries. The verb 'Get a list of' is precise and the scope is unambiguous.
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 clear guidance on when not to use this tool ('does not fetch any glossary entries') and explicitly recommends the alternative tool ('Use the get-glossary-dictionary-entries tool to fetch entries'). This gives the agent actionable decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![deepl-mcp-server MCP server](https://glama.ai/mcp/servers/DeepL/deepl-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/DeepL/deepl-mcp-server)

Score Badge

Copy to your README.md:

[![deepl-mcp-server MCP server](https://glama.ai/mcp/servers/DeepL/deepl-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/DeepL/deepl-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DeepL/deepl-mcp-server'

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