librascript-mcp

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Most tools have distinct purposes, but text_to_gloss and translate_and_validate could be confused as both involve translation. Descriptions help clarify: translate_and_validate is an all-in-one shortcut while text_to_gloss is a standalone step. Similarly, batch_translate and translate_and_validate might overlap for multiple items, but batch_translate is for without audit.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., audit_content, batch_translate, lookup_sign). No deviations or mixed conventions are present, making the naming predictable and easy to parse.
Tool Count5/5
With 9 tools, the server is well-scoped for its purpose of translating Portuguese to LIBRAS. Each tool covers a specific step in the workflow (audit, translate, batch, validate, lookup, script generation, stats, feedback) without unnecessary bloat or missing essentials.
Completeness4/5
The tool surface covers the core translation workflow end-to-end, including audit, translation, validation, and feedback. Minor gaps exist, such as a tool for direct audio/video translation or user account management, but these are reasonable omissions for the stated domain.
Average 3.5/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on June 23, 2026
- 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 full burden. It discloses the 20-item limit, but fails to mention other behavioral traits such as whether the translation is stored, what output is returned, or any authentication/rate limits. A translate action likely has side effects or return values that are not described.
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 action and key constraint (max 20 items). Every word contributes meaning with zero redundancy.
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?
Despite the simple input schema, the description is incomplete. It does not specify the target language for translation or what happens after translation (e.g., output format). Without an output schema, the description should clarify return behavior, which it does not.
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%, and the schema already describes the 'texts' parameter as a list of Portuguese texts and enforces maxItems=20. The description adds no additional semantic value beyond the schema, meriting the baseline score.
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 translates multiple text snippets at once, with examples (slides, sections, FAQ) and a maximum of 20 items. However, it does not explicitly differentiate from the sibling tool 'translate_and_validate', which may also handle translations.
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, nor does it mention any prerequisites or conditions. For example, it does not explain how batch_translate relates to the sibling translation tool.
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 convey behavior. It states the tool transforms a gloss into a script with estimated times, but does not disclose error handling, prerequisites, side effects, or output format. Essential behavioral traits are missing.
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: one sentence plus a short phrase, front-loaded with the core action. No wasted words, though it could be slightly more 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?
Given two parameters and no output schema or annotations, the description lacks important context: output structure, estimation method, input validation, and edge cases. It is insufficient for an agent to reliably invoke the tool.
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% as both parameters have descriptions. The description adds no additional meaning beyond the schema; it simply restates the transformation purpose. Baseline of 3 is appropriate.
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 transforms a gloss into a script with estimated times, and mentions suitable use cases (videos, lessons, interpreters). It is specific but does not distinguish from sibling tools like text_to_gloss or validate_gloss.
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 gives a vague usage context ('Ideal para vídeos, aulas gravadas e intérpretes') but no explicit when-to-use or when-not-to-use instructions, nor alternatives to consider among 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, the description must fully disclose behavior. It states the tool analyzes and detects issues, but does not clarify whether it is read-only, what side effects exist, or what happens after detection (e.g., returns a report). This leaves gaps for agent decision-making.
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?
A single concise sentence that is front-loaded with the key action and timing. It is appropriately brief, though it could benefit from a slightly more structured breakdown of output or usage notes.
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 no output schema and sparse annotations, the description is incomplete. It describes what the tool detects but does not explain the return value or how results are presented, leaving the agent without enough context to interpret tool output.
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 only parameter 'text' is described identically in schema and description. Since schema coverage is 100%, the description adds no extra meaning beyond what the schema already provides, resulting in baseline performance.
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 analyzes Portuguese text before translation, detecting specific issues like long sentences, acronyms, and hard-to-sign excerpts. It distinguishes from siblings that perform translation or validation.
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?
Explicitly mentions 'ANTES de traduzir' (BEFORE translating), providing clear usage timing. However, it does not explicitly list alternative tools or exclusions, though the context inherently differentiates it from post-translation 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 lacks any behavioral details such as read-only nature, permissions needed, rate limits, or side effects. The description only states the action without transparency.
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?
Two sentences, no redundancy. Front-loaded with the primary action and purpose. Every word earns its place.
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?
For a simple lookup tool with 2 parameters and no output schema, the description is minimally adequate. It explains the what and when, but lacks information about return values or output format, which would be helpful given no output schema.
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 both parameters documented in the schema. The tool description adds no extra meaning beyond what is in the schema. Baseline score of 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?
Description uses specific verb 'Busca' and resource 'sinal no dicionário oficial VLibras', and states the use case: 'conferir se uma palavra tem sinal cadastrado'. This clearly distinguishes from sibling tools like dictionary_stats or translate_and_validate.
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 says 'Use para conferir se uma palavra tem sinal cadastrado', which implies when to use (checking existence), but does not explicitly mention when not to use or provide alternatives among 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?
No annotations are provided, so the description should disclose behavior. It only mentions sending feedback, without detailing side effects (e.g., storage, notifications), safety (e.g., destructive nature), or prerequisites (e.g., authentication). This under-disclosure leaves uncertainty about the tool's impact.
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, well-structured sentence that immediately conveys the tool's purpose. Every word is necessary, and there is no redundancy or extraneous information.
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 has 4 parameters with conditional validation (suggestion required for 'bad' rating) and no output schema, the description lacks details on return values, post-submission behavior, or error handling. This makes it incomplete for a tool with moderate 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 coverage is 100%, with all parameters described in the input schema. The description adds no additional meaning beyond what is already in the schema, so baseline score 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 tool's purpose: sending feedback about translation quality to the VLibras team. It uses a specific verb ('send feedback') and resource ('translation'), and distinguishes it from sibling tools which focus on translation, validation, or auditing rather than user feedback submission.
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 implies when to use the tool ('when a translation is good or needs correction'), providing clear context. However, it does not explicitly state when not to use it or mention alternative tools among siblings, slightly reducing guidance completeness.
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 states a read-only behavior (shows count) but does not disclose output format (e.g., integer, string), potential caching, or whether the count reflects only the currently loaded dictionary. For a simple stat tool, this is adequate but minimal.
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 sentence, front-loaded, and concise. Every word is relevant. It could be slightly more descriptive (e.g., mentioning it returns a number), but for a tool with no parameters, it is appropriately sized.
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 (0 parameters, no complex logic), the description is reasonably complete. It explains what the tool does and the source (official dictionary). Without an output schema, the agent might infer the return type, but additional clarity on the output format would improve completeness. Still, for a straightforward stat tool, it suffices.
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 0 parameters and schema description coverage is 100%. The description adds meaning beyond the schema by specifying that the stat is for the 'official dictionary' and that it shows a count. With no params, the baseline is 4, and the description meets expectations.
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 'Mostra quantos sinais existem no dicionário oficial carregado' (Shows how many signs exist in the loaded official dictionary). It specifies the verb (shows) and the resource (count of signs in the official dictionary), distinguishing it from sibling tools that focus on translation, glossing, or content auditing.
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 guidance is provided on when to use this tool versus alternatives. With multiple sibling tools like lookup_sign, text_to_gloss, and validate_gloss, the description should clarify that this is for obtaining a rapid statistic, not for detailed lookups or validation. It gives no context on prerequisites or exclusions.
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 provided, so description must disclose behavioral traits. It only states the function without details on output format, error behavior, or idempotency. The max length constraint is in schema but not in description.
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?
Two concise sentences: first states purpose, second gives usage context. No redundant information.
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?
With one parameter and no output schema or annotations, description covers purpose and usage but omits output format and error handling. Adequate but not fully self-contained.
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% (text param described). The tool description does not add extra meaning beyond restating 'text in Portuguese'. Therefore 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?
Description clearly states the tool translates Portuguese text to LIBRAS gloss, a specific verb+resource. It distinguishes from siblings by specifying the target (LIBRAS gloss) and provides explicit usage context ('use when user asks for LIBRAS').
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?
Explicitly says when to use: when user asks for translation to LIBRAS, sign language, or VLibras. However, it does not mention when not to use or give alternatives, though siblings exist (e.g., batch_translate for multiple texts).
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 combined operations and mentions the auditFirst parameter default, but does not explain what happens if validation fails, output format, or side effects. Adequate but not thorough.
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?
Two sentences, concise and front-loaded. First sentence states purpose, second gives usage recommendation. No wasted words.
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 no output schema and two parameters, the description covers purpose and recommendation but lacks details on return values, error conditions, or step ordering. Adequate for selection but insufficient for full invocation understanding.
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 descriptions for both parameters (text and auditFirst). The tool description reiterates the audit and translate context but does not add new meaning beyond the schema. Baseline 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?
Description clearly states the tool does three things (audit, translate, validate) in one call with the phrase 'audita, traduz e valida em uma única chamada'. This distinguishes it from siblings like audit_content (only audit) or validate_gloss (only validation).
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?
Description explicitly recommends use for most translation requests ('Use para a maioria dos pedidos de tradução'), giving clear guidance on when to apply. Lacks explicit exclusions or alternatives, but the recommendation is strong.
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 validates and shows dictionary signs, implying a read operation, but does not disclose potential side effects, authentication needs, or rate limits. Adequate for a simple tool but could be more explicit.
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?
Two sentences with no redundancy. Purpose is front-loaded, and every word serves a clear function. Highly 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?
Given one required parameter and no output schema, the description covers the core functionality and usage timing. Minor omission: could briefly describe the output format (e.g., lists existing signs), but context is simple enough that the description is largely 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?
Schema description coverage is 100% for the gloss parameter, and the description adds 'mostra quais sinais existem no dicionário' but does not provide additional meaning beyond the schema's description. Baseline score 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 tool validates a gloss and shows dictionary signs, distinguishing it from siblings like lookup_sign or translate_and_validate. It uses a specific verb (validate) and resource (gloss), making purpose evident.
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?
Explicitly says 'Use sempre após traduzir' (Always use after translating), providing clear when-to-use guidance and implying not to use before translation, which differentiates it from other 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:

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

Score Badge

Copy to your README.md:

[![librascript-mcp MCP server](https://glama.ai/mcp/servers/fabricioartur/librascript-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fabricioartur/librascript-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/fabricioartur/librascript-mcp'

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