POEditor MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between add_terms_with_translations and the separate add_terms/add_translations pair, which could cause confusion despite clear guidance. Tools like list_available_languages and list_languages are well-differentiated by scope.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores, such as add_language, delete_terms, and update_translations. This predictability makes the set easy to navigate and understand.
Tool Count5/5
With 11 tools, the server is well-scoped for managing translations in POEditor, covering core operations like adding, updating, deleting, and listing terms, languages, and translations. Each tool serves a clear purpose without bloat.
Completeness4/5
The tool set provides comprehensive CRUD coverage for terms, translations, and languages, with minor gaps such as no direct tool for creating a project or managing project settings. However, core workflows for translation management are fully supported.
Average 3.3/5 across 11 of 11 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 provided, the description carries the full burden of behavioral disclosure. While it mentions that translations are 'update/overwrite' (implying mutation) and provides one important constraint about context matching, it lacks critical information about permissions needed, whether changes are reversible, rate limits, error conditions, or what happens to existing translations not included in the update. For a mutation tool with zero annotation coverage, this is insufficient.
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 appropriately brief with two sentences. The first sentence states the core purpose, and the second provides a critical constraint. There's no unnecessary verbiage, though it could be more structured by separating usage guidance from behavioral constraints.
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?
For a mutation tool with 3 parameters (including a complex nested array structure), no annotations, and no output schema, the description is inadequate. It provides one important behavioral constraint but misses essential context about permissions, error handling, return values, and how this tool differs from similar sibling tools. The agent would struggle to use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description provides minimal parameter guidance. It only mentions the 'context' parameter indirectly in the constraint about matching context values, but doesn't explain what 'project_id', 'language', or the complex 'items' array structure represent. The description fails to compensate for the complete lack of schema descriptions.
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 clearly states the action ('update/overwrite translations') and the target resource ('for a language'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'add_translations' or 'update_terms', which appear to have related functionality.
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 a specific constraint about matching context values for terms created with context, but offers no guidance on when to use this tool versus alternatives like 'add_translations' or 'update_terms'. There's no mention of prerequisites, typical use cases, or when this tool would be preferred over other translation-related tools.
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 carries full burden. It states 'Add a new language' which implies a mutation operation, but doesn't disclose behavioral traits such as required permissions, whether the operation is idempotent, error conditions, or what happens on success. This is a significant gap for a mutation tool with zero annotation coverage.
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 appropriately sized with two concise sentences that are front-loaded with the core purpose. Every sentence earns its place by stating the action and providing parameter guidance, with zero waste.
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?
Given the complexity (mutation tool with 2 parameters), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't cover the 'project_id' parameter, lacks behavioral context, and provides minimal usage guidance, making it inadequate for the tool's requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 only explains the 'language' parameter with an example ('e.g., 'en', 'de', 'fr''), but completely ignores the 'project_id' parameter (which is required in the schema but not mentioned). This leaves half the parameters undocumented, failing to adequately compensate for the schema gap.
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 clearly states the action ('Add a new language') and the resource ('to the project'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_languages' or 'list_available_languages', which would require a 5.
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 like 'list_languages' or 'add_terms_with_translations'. It mentions providing a language code but doesn't specify prerequisites (e.g., needing a project_id) or exclusions, leaving usage context unclear.
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?
With no annotations, the description carries full burden but only states the action without disclosing behavioral traits like permissions needed, whether deletion is permanent, rate limits, or error handling. It mentions 'exact term and context combination' which adds some context but is insufficient for a mutation tool.
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 with two sentences that are front-loaded and waste no words. Every part contributes directly to the tool's purpose and basic usage.
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?
For a destructive mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks critical details like return values, side effects, or error scenarios, making it inadequate for safe and effective use by an AI agent.
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%, but the description adds minimal semantics by hinting at parameters ('exact term and context combination'), which loosely maps to the 'items' array structure. However, it doesn't explain 'project_id' or provide details beyond what the schema implies, leaving significant gaps.
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 clearly states the action ('Remove') and target ('terms from the project'), distinguishing it from siblings like 'delete_translations' or 'update_terms'. However, it doesn't specify what type of terms (e.g., glossary terms, taxonomy terms) or fully differentiate from all siblings like 'list_terms' beyond the verb.
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?
No explicit guidance on when to use this tool versus alternatives like 'update_terms' or 'delete_translations' is provided. The description implies usage for deletion but lacks context on prerequisites, error conditions, or comparisons to sibling tools.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List') but doesn't describe the return format (e.g., list structure, pagination), potential errors (e.g., invalid project_id), or any side effects. This leaves significant gaps for an agent to understand how to use it effectively.
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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't cover return values, error conditions, or behavioral nuances. For a tool with one parameter and no structured support, more detail is needed to guide an agent adequately.
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 description coverage is 0%, so the description must compensate. It mentions 'project' which relates to the 'project_id' parameter, adding some context. However, it doesn't explain the parameter's role (e.g., required vs. optional, what happens if omitted) or provide examples, resulting in only marginal value beyond the bare schema.
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 clearly states the verb ('List') and resource ('languages in the project'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'list_available_languages', which appears to serve a similar purpose, preventing a perfect score.
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 like 'list_available_languages' or 'list_terms'. It lacks context about prerequisites, such as whether a project must exist or be accessible, and offers no exclusions or recommended scenarios.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool updates metadata, implying a mutation operation, but doesn't cover critical aspects like required permissions, whether updates are reversible, error handling for invalid inputs, or rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
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 concise and front-loaded, with two sentences that directly convey the tool's purpose and a key usage note. There's no unnecessary verbosity, and each sentence adds value, though it could be slightly more structured by explicitly separating purpose from guidelines.
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?
Given the complexity (2 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't address the 'project_id' parameter, error conditions, response format, or how updates interact with existing data, making it inadequate for an agent to use the tool effectively without additional context.
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 description adds some value by explaining that terms are identified by 'current term/context values' and lists updatable fields ('display text, context, references, or tags'), which partially clarifies the 'items' parameter. However, with 0% schema description coverage and 2 parameters (including a complex nested array), it doesn't fully compensate for the lack of schema details, such as the purpose of 'project_id' or the specifics of each field in 'items'.
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 clearly states the action ('Update term metadata') and specifies what can be updated ('display text, context, references, or tags'), which goes beyond just restating the name. However, it doesn't explicitly differentiate from sibling tools like 'update_translations' or 'add_terms_with_translations', which prevents a perfect score.
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 minimal guidance by stating 'Identify each term by its current term/context values,' which hints at how to use the tool. However, it doesn't explain when to use this tool versus alternatives like 'update_translations' or 'delete_terms,' nor does it mention prerequisites such as requiring a project context or handling multiple items.
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 carries full burden. It discloses that the tool is destructive ('Delete') and advises caution, but lacks details on permissions required, whether deletions are reversible, rate limits, error handling, or what happens if items are missing. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.
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 with zero waste: the first states the purpose, and the second adds a crucial caution. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.
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?
Given the tool's destructive nature, 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on parameter usage, behavioral traits like side effects or auth needs, and expected outcomes. While concise, it doesn't provide enough context for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 mentions 'specific terms in a language,' which hints at the 'language' and 'items' parameters, but doesn't explain 'project_id' (implied by 'translations' context) or the structure of 'items' (objects with 'term' and optional 'context'). The description adds minimal meaning beyond the bare schema, failing to fully address the coverage gap.
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 clearly states the action ('Delete translations') and target ('for specific terms in a language'), which distinguishes it from siblings like delete_terms (which deletes terms rather than translations) and update_translations (which modifies rather than removes). However, it doesn't specify the resource scope (e.g., within a project) that the schema indicates via project_id, making it slightly less specific than ideal.
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 provides implied guidance with 'Only remove translations you are certain are obsolete,' suggesting caution for this destructive operation. It doesn't explicitly state when to use this tool versus alternatives like delete_terms or update_translations, nor does it mention prerequisites such as needing a project_id from project_details. This leaves some ambiguity in context.
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 carries the full burden of behavioral disclosure. It mentions that the tool 'Returns only term names, contexts, and translation content to minimize response size,' which adds useful context about output behavior. However, it lacks details on permissions, rate limits, pagination, or error handling, which are important for a list operation with multiple parameters.
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 appropriately sized and front-loaded, starting with the core purpose and following with parameter usage tips. Both sentences earn their place by adding value, though it could be slightly more structured (e.g., separating purpose from parameter guidance more clearly).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, no output schema), the description is partially complete. It covers the tool's purpose and hints at parameter usage but lacks details on output format, error cases, or integration with sibling tools. Without an output schema, more explanation of return values would be beneficial, though the mention of minimized response size helps.
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 description adds some meaning beyond the input schema by explaining the purpose of parameters like 'limit, search, count_only, and fields' to reduce token usage. However, with 0% schema description coverage and 6 parameters, it doesn't fully compensate for the lack of schema documentation—key parameters like 'project_id' and 'language' are mentioned but not elaborated on, leaving gaps in understanding.
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 clearly states the tool's purpose: 'List all project terms (optionally include translations for a specific language).' It specifies the verb ('List'), resource ('project terms'), and optional scope ('translations for a specific language'). However, it doesn't explicitly differentiate from sibling tools like 'list_available_languages' or 'list_languages', which reduces it from a perfect score.
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 usage context by mentioning parameters like 'limit' and 'search' to reduce token usage, but it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., 'list_available_languages' for languages instead of terms). No exclusions or prerequisites are stated, leaving usage somewhat open to interpretation.
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 carries the full burden. It mentions retrieving metadata but doesn't disclose behavioral traits such as required permissions, error handling, rate limits, or whether the operation is idempotent. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, front-loaded with the core purpose and followed by a usage hint. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and hints at usage but lacks behavioral details and output information. For a metadata retrieval tool, this is minimally viable but leaves gaps in understanding the full context.
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 description doesn't mention parameters, but the input schema has only one parameter (project_id) with 0% schema description coverage. Since there are zero parameters documented in the schema, the baseline is 4, as the description doesn't need to compensate for missing param info. However, it doesn't add any semantic context about the project_id beyond what the schema provides.
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 clearly states the verb 'retrieve' and the resource 'project metadata', specifying concrete attributes like name, terms count, and last activity. It distinguishes from siblings by focusing on metadata retrieval rather than modifications or listings, though it doesn't explicitly name alternatives.
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 provides implied usage guidance with 'useful before performing other operations on the project', suggesting a preparatory role. However, it doesn't explicitly state when to use this tool versus alternatives like list_terms or update_terms, nor does it mention exclusions or prerequisites.
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 full burden. It mentions that the tool 'ensures terms and translations are properly linked,' which adds useful behavioral context about atomicity and data integrity. However, it doesn't disclose other important traits like error handling, permissions required, rate limits, or what happens on failure, leaving gaps for a mutation tool.
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 front-loaded with the key purpose and usage guidelines in the first sentence. Every sentence adds value: the first states what it does, the second gives explicit alternatives, and the third provides additional context. There is no wasted text, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters with nested objects, no annotations, and no output schema), the description is incomplete. It excels in purpose and guidelines but lacks parameter explanations and behavioral details like error handling or return values. For a mutation tool with significant parameter complexity, more information is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the parameters are documented in the schema. The description does not explain any parameters—it doesn't mention 'project_id', 'language', or the structure of 'items' (including 'term', 'context', 'reference', 'tags', or 'translation' fields). This fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.
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 specific action: 'Create multiple new terms and add their translations in one operation.' It explicitly distinguishes this tool from its siblings by naming 'add_terms' and 'add_translations' as separate tools that should not be used, making the purpose highly specific and differentiated.
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 guidance on when to use this tool: 'PREFERRED METHOD' indicates it's the recommended approach, and it specifies 'Use this instead of calling add_terms followed by add_translations separately.' It also mentions a specific scenario where it's important: 'especially important when using context,' giving clear context for its use over alternatives.
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 full burden. It discloses key behavioral traits: the tool does not overwrite existing translations, requires terms to already exist, and has a context-matching requirement. However, it lacks details on error handling, rate limits, or what happens with duplicate translations, leaving some 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 efficiently structured in three sentences: the first states the purpose, the second provides usage guidelines, and the third adds a critical constraint. Every sentence adds value without redundancy, making it front-loaded and concise.
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 complexity (3 parameters, nested objects in 'items', no output schema, and no annotations), the description is reasonably complete. It covers purpose, usage rules, and a key constraint, but could improve by addressing error scenarios or output expectations, though the lack of output schema is a mitigating factor.
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 adds some semantic context by explaining that 'context' must match if a term was created with one, but does not clarify other parameters like 'fuzzy', 'plural', or 'content'. The description partially compensates but leaves many parameters unexplained.
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: 'Add translations for EXISTING terms in a language (does not overwrite).' It specifies the verb ('add'), resource ('translations'), and scope ('existing terms'), and distinguishes it from sibling 'add_terms_with_translations' by noting it's only for existing terms.
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 guidance on when to use this tool vs. alternatives: 'Use this only when terms already exist. If you need to create new terms AND add their translations, prefer using add_terms_with_translations instead.' It also includes a prerequisite about context matching, making usage conditions clear.
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 clearly indicates this is a read-only operation ('List'), but doesn't disclose behavioral traits like rate limits, authentication requirements, response format, or pagination. The description adds basic context about scope but lacks operational details.
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, efficient sentence that front-loads the core purpose and immediately clarifies the scope. Every word earns its place with zero waste, making it easy for an agent to parse quickly.
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 read-only tool with no parameters and no output schema, the description provides adequate context about what the tool does and when to use it. However, without annotations or output schema, it could benefit from mentioning the response format (e.g., list of language codes) to be fully 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?
With 0 parameters and 100% schema description coverage, the baseline for no parameters is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents the empty input object.
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 specific action ('List all available languages') and the resource ('POEditor'), with explicit scope differentiation ('not project-specific, but all possible language codes'). It distinguishes from the sibling 'list_languages' tool by specifying this lists all possible languages rather than project-specific ones.
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 guidance on when to use this tool versus alternatives: 'not project-specific' indicates this should be used for general language reference, while the sibling 'list_languages' (implied by context) would be for project-specific languages. This creates clear differentiation between tools.
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:

[![poeditor-mcp MCP server](https://glama.ai/mcp/servers/ryan-shaw/poeditor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ryan-shaw/poeditor-mcp)

Score Badge

Copy to your README.md:

[![poeditor-mcp MCP server](https://glama.ai/mcp/servers/ryan-shaw/poeditor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ryan-shaw/poeditor-mcp)

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/ryan-shaw/poeditor-mcp'

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