MCP Acadêmico

by Werverton

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: listing, registering, extracting, comparing, searching, citing, structuring, and generating sections. No overlap is apparent; even similar tools like 'fichar_artigo' and 'extrair_pdf' have different outputs (structured summary vs raw text).
Naming Consistency5/5
All tool names follow a consistent verb_infinitive_noun pattern in Portuguese (e.g., listar_artigos, cadastrar_artigo, extrair_pdf). No mixing of naming conventions or styles.
Tool Count5/5
10 tools is well-scoped for the domain of academic paper management and writing support. Each tool serves a necessary function without redundancy, covering the full workflow from import to writing assistance.
Completeness5/5
The toolset covers the entire lifecycle: adding articles (cadastrar, extrair), organizing (listar, buscar, comparar), structured extraction (fichar), citation formatting (extrair_citacao), and writing guidance (estruturar, gerar_secao). Minor gaps like automatic bibliography generation are mitigated by combining existing tools.
Average 3.8/5 across 10 of 10 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations provided, so description carries full burden. It reveals upsert behavior (cadastra ou atualiza) but lacks details on side effects, required permissions, idempotency, or error handling. Minimal behavioral info beyond the obvious write 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?
Three sentences, front-loaded with core purpose, followed by use explanation and sequence instruction. No redundant information; every sentence adds value.
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?
With 16 parameters (6 required), no output schema, and no annotations, the description is insufficient. It explains the tool's role in the workflow but omits explanations for required parameters like 'id' and 'tipo', and does not cover error cases or behaviors.
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 69%, leaving several parameters with no description in schema. The tool description only mentions a few fields (autores, título, ano, revista, DOI) without adding meaning to the undocumented ones. It does not compensate for the missing 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?
Description clearly states it registers or updates article metadata, listing specific fields (authors, title, year, journal, DOI). It distinguishes from siblings like listar_artigos by positioning as a metadata registration tool to be used after PDF placement.
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?
Provides clear context: use after placing PDF in referencias/ folder and for recording metadata used in ABNT citations. However, it does not mention when not to use this tool or suggest alternatives like extrair_pdf for metadata extraction.
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 'sugere' (suggests) a structure, indicating a read-only or generative operation with no side effects. However, it does not clarify whether the structure is saved, if it requires specific permissions, or what happens if no articles exist. The mention of Brazilian academic norms adds context.
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 (three sentences) and front-loads the main purpose. Each sentence adds value: the first states the overall function, the second lists the sections, and the third mentions adherence to norms and use of available material. Slight repetition of 'artigos' but overall efficient.
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 description explains what the tool does but lacks important details: there is no output schema, so the return format is not described. Prerequisites (having articles registered) are implied but not explicit. Error conditions (e.g., no articles found) are not mentioned. For a tool with 3 parameters and no annotations, more completeness is needed.
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 (tema, objetivo, abordagem) are described in the input schema (100% coverage). The description adds context by listing the sections that will be structured, but does not provide additional semantics beyond the schema. It does not explain how each parameter affects the output. 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?
The description clearly states that the tool generates a suggested structure for a master's thesis based on registered articles. It lists specific sections (introdução, referencial teórico, etc.) and differentiates from sibling tools like 'comparar_metodologias' or 'gerar_secao' by focusing on overall structure generation.
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 when a master's article structure is needed and articles are registered, but it does not explicitly state when to use this tool versus alternatives like 'gerar_secao' (which might generate one section in detail) or 'listar_artigos'. No exclusions or when-not-to-use conditions are provided.
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?
Nenhuma anotação fornecida; a descrição não menciona efeitos colaterais, requisitos de permissão ou comportamento de leitura/escrita. A ferramenta parece ser de consulta, mas a transparência é apenas implícita.
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?
Duas frases concisas que apresentam claramente o propósito principal e as variações. Sem excessos.
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?
A descrição cobre os três tipos de saída, mas não menciona pré-requisitos (ex.: artigo deve existir), tratamento de erros ou detalhes do formato de saída. Adequada, mas com lacunas.
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?
A cobertura de descrição do esquema é 100%, então a linha de base é 3. A descrição não adiciona informações significativas além do que já está no esquema.
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?
A descrição indica claramente que a ferramenta retorna uma referência formatada em ABNT ou citações diretas/indiretas, o que a distingue das ferramentas irmãs como listar_artigos ou buscar_nos_artigos. No entanto, não oferece diferenciação explícita em relação aos irmãos.
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?
A descrição sugere uso quando se necessita de citações ABNT ou busca de termos, mas não fornece orientações explícitas sobre quando evitar ou alternativas.
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 bears full burden. It explains the tool extracts text and returns a structured output listing specific elements, which is helpful. However, it does not disclose potential side effects, prerequisites (e.g., file access), performance characteristics, or whether it modifies state.
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, well-structured sentence that front-loads the main action and lists the output components concisely. It avoids repetition and unnecessary details, making it efficient for quick understanding.
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 simple parameter and no output schema, the description adequately explains the tool's functionality and the structure of the returned fichamento. It lists all major output sections (ABNT reference, abstract, objective, etc.), which is sufficient for understanding 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 only parameter 'arquivo' has a clear description in the schema ('Nome do arquivo PDF ou ID do artigo cadastrado'), and the tool description reinforces that it expects a PDF file or registered article ID. Schema coverage is 100%, so the description adds minimal additional value beyond the schema.
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 it extracts text from an article and organizes it into a structured fichamento format, including specific components like ABNT reference, abstract, objective, methodology, results, conclusions. This distinguishes it from sibling tools such as 'extrair_pdf' (simple extraction) or 'extrair_citacao' (extract citation only).
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 when a full structured fichamento is needed, but does not explicitly state when not to use it (e.g., for simple extraction or when only a citation is needed) or mention alternatives like 'extrair_pdf' or 'estruturar_artigo'. No exclusions or alternative recommendations are given.
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 full burden. It only mentions the return type (trechos, contexto, referência ABNT) but lacks details on behavior such as synchronicity, rate limits, destructiveness (likely read-only), or pagination. Minimal behavioral disclosure.
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, front-loaded with the main action, no wasted words. Efficiently conveys the core purpose and value.
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 no output schema and no annotations, the description covers the essential action and output type. However, it lacks details on the exact structure of returned data and any constraints, which would be beneficial for a tool with 4 parameters.
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%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for each parameter; it only reinforces the general purpose.
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 ('Busca') and resource ('todos os artigos extraídos'), clearly stating the tool's function. It distinguishes itself from siblings like 'listar_artigos' by focusing on searching within article content, and explains the output (snippets with context and ABNT reference).
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 provides clear context for use ('essencial para encontrar como diferentes autores abordam um mesmo tema e construir o referencial teórico'), but does not explicitly state when not to use or mention alternative tools.
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 explains the extraction and tabular output with specific columns, but does not disclose potential side effects, permissions, or limitations (e.g., read-only assumption).
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 long, front-loads the purpose, and immediately lists the output columns with no 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 one-parameter tool without output schema, the description adequately covers input, output format, and use case, though it does not address edge cases like invalid input.
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 a clear parameter description for 'artigos'. The tool description adds overall context but does not provide additional parameter-level details beyond the schema.
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 specifies the verb 'Compara' and the resource 'metodologias de dois ou mais artigos', and uniquely distinguishes from sibling tools like 'fichar_artigo' and 'gerar_secao' by focusing on comparative methodology extraction.
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 states it is 'Essencial para escrever a seção de metodologia do seu artigo', providing a clear context for use, but does not explicitly exclude scenarios or name alternative tools.
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 provided; description adds caching behavior but does not disclose error handling, auth needs, or limitations (e.g., only works with text PDFs). 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, front-loaded with purpose, no fluff. Every sentence adds value (purpose, caching, combination advice). Excellent structure.
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?
With schema covering parameters and no output schema, description includes caching and combination hint. Lacks output format details, but is fairly complete for a simple extraction 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% with descriptions; description adds no extra parameter meaning. Baseline 3 is appropriate as 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?
Description clearly states verb 'extrair' and resource 'PDF', specifies it extracts full text, and distinguishes from siblings by mentioning caching and combination with buscar_nos_artigos. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use this tool to get raw content' and suggests combining with buscar_nos_artigos for excerpts. Lacks explicit when-not-to-use or prerequisites, but provides clear context.
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 must fully disclose behavior. It correctly states that the tool clears cache, implying destructive action. However, it does not explicitly warn that cached data will be lost, nor does it mention any side effects (e.g., increased load on re-extraction).
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 extremely concise: two sentences that front-load the core action and then immediately provide a usage hint. No unnecessary words.
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 tool (1 optional param, no output schema, no annotations), the description adequately covers purpose and when to use. It lacks information about return values or confirmation of success, but the context is fairly complete given the tool's simplicity.
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% (the only parameter 'arquivo' is described in the schema). The description adds no new parameter information beyond what is already in the input schema, so a baseline score 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 tool's purpose: clearing the cache of extracted texts. It also provides a concrete use case ('if you updated a PDF and want to force re-extraction'), distinguishing it clearly from sibling tools that handle other article operations.
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 gives a specific scenario when to use the tool ('after updating a PDF'), which is helpful for the agent. However, it does not explicitly exclude other cases or mention alternatives, though the context is clear.
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, the description carries full burden. It discloses the tool reads from a specific folder, returns metadata and indexing status, and implies a read-only operation. However, it does not mention sorting, pagination, or response size limits.
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, front-loaded sentences with no redundancy. Every detail is relevant and efficiently communicated.
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 no output schema, the description adequately explains the return content (metadata fields and indexing indicator). It could specify the structure (e.g., list of objects) but is sufficient for a simple listing.
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 no parameters, so the baseline is 4. The description does not need to add parameter-level detail.
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 all registered articles and PDFs from a specific folder, showing metadata and indexing status. It distinguishes from sibling tools like 'cadastrar_artigo' (create) and 'extrair_pdf' (extract).
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, such as 'buscar_nos_artigos' for searching. No explicit when-not or prerequisite information is given.
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 bears the full burden. It describes the tool's behavior (searches articles, organizes excerpts, returns ABNT citations) but does not disclose whether it is read-only, destructive, or any side effects. This is adequate but leaves some behavioral aspects unclear.
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 leads with the core purpose, then details the process, and ends with an action directive. Each sentence adds value without repetition, making it efficient for an agent to parse.
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 no output schema, the description should ideally describe the return format. It mentions 'já retorna as citações ABNT prontas' but does not detail the structure. The description covers all parameters and usage context, but lacks details on what the agent can expect in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, and the tool description adds significant meaning beyond the schema. It explains the purpose of each parameter, such as 'secao' with examples and 'tema_pesquisa' for context. This helps the agent understand how to use them effectively.
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: preparing reference material for writing a specific section of an academic paper. It provides concrete examples of section names and explains the automatic search and citation generation. This distinguishes it from sibling tools like 'buscar_nos_artigos' which are more general.
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 advises using it as a starting point for writing each section ('Use como ponto de partida para redigir cada seção'). While it does not explicitly list alternatives or when not to use it, the guidance is clear and contextually appropriate given the sibling 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:

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

Score Badge

Copy to your README.md:

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

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/Werverton/mcp-academico'

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