Skip to main content
Glama
Sign In
sigaa-mcp

sigaa-mcp

by GallegoSz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_conteudo

Retrieves course topics and schedules from virtual classes, including dates, descriptions, materials, videos, assignments, and future planned content; optionally filter by course name.

Instructions

Tópicos de aula da turma virtual (cronograma com datas, descrição e materiais: arquivos, vídeos, tarefas).

Inclui tópicos futuros já planejados pelo professor. A saída pode ser grande; prefira filtrar.

Args:
    disciplina: parte do nome da disciplina (sem diferenciar acentos/caixa). Se omitido, todas.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_conteudo"
  }
}

Input Schema

NameRequiredDescriptionDefault
disciplinaNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It does disclose two useful behavioral traits: future teacher-planned topics are included, and the response can be large. It does not cover auth/permission needs, pagination, or whether results are ordered by date, which for a potentially large read is a meaningful gap.

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?

Front-loaded with the resource definition, then the inclusion caveat, then the size warning, then the parameter note. No wasted prose. The Args block is slightly redundant with the property but still earns its place given 0% schema coverage.

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?

An output schema exists, so return shape needn't be explained, and the description still summarizes the content types returned. Combined with the future-topics note and the filter semantics, an agent has enough to call it correctly; only ordering/pagination behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: disciplina is described as a partial name match, accent- and case-insensitive, optional with 'all courses' as the default. That is exactly the semantics an agent needs and cannot get from 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?

States a concrete resource and scope: 'Tópicos de aula da turma virtual' with the fields returned (cronograma com datas, descrição, materiais: arquivos, vídeos, tarefas). An agent can tell this apart from get_tarefas or get_agenda, though it never names a sibling explicitly to sharpen the boundary.

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 saída pode ser grande; prefira filtrar' implies the recommended call pattern (use the disciplina filter), and 'Se omitido, todas' tells the agent what happens without a filter. There is no explicit when-to-use vs. when-to-use-another-tool guidance, so the routing to get_tarefas/get_agenda for task-only or date-only needs is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools