crowdin_get_language_progressPer-target-language translation & approval completion percentages for a project — the headline localization status. Crowdin API: GET /projects/{projectId}/languages/progress.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows (max 500, default 25). | |
| offset | No | Rows to skip (default 0). | |
| projectId | Yes | Numeric project id. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the endpoint and clarifies the output is per-target-language percentages, but does not disclose pagination behavior, response shape, or potential empty/failed states beyond what the schema already implies through limit/offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that states the tool's purpose immediately, followed by the concrete API endpoint. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list-like endpoint with full schema coverage and a readOnlyHint annotation, the description provides the core context: target language, translation vs. approval, and project scope. It does not describe the response format, but given the absence of an output schema and the low complexity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (projectId, limit, offset) is already documented with type, bounds, and purpose. The description adds no extra parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: getting per-target-language translation and approval completion percentages for a project. It clearly differentiates this from the sibling tools, which cover adding strings/translations, listing files/branches, and getting project metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool returns but gives no explicit guidance on when to prefer it over alternatives or when not to use it. The 'headline localization status' phrase implies it is the primary progress view, but no sibling comparison or exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool targets a distinct resource and action, such as strings, translations, branches, files, members, and tasks. There is no meaningful overlap or ambiguity between the list/get/add operations.
All tools follow a consistent crowdin_ verb_noun pattern using list_, get_, and add_ prefixes. The naming is uniform and predictable across the entire set.
12 tools is a well-scoped size for a localization management server, covering discovery, project details, progress, strings, translations, and tasks without feeling bloated or thin.
The server covers discovery and additive operations well, but lacks update/delete functionality for strings and translations, and provides no way to list or retrieve existing translations. These are notable gaps that could require workarounds.