Servidor MCP local y de solo lectura para una cuenta del Portal Librus. Utiliza el flujo de inicio de sesión del Portal para obtener un token de API de Librus de corta duración para una cuenta de Synergia elegida.
Las credenciales se leen únicamente de LIBRUS_EMAIL y LIBRUS_PASSWORD.
Las cookies y los tokens se mantienen en memoria y se descartan cuando el proceso finaliza o se llama a librus_logout.
El servidor solo permite solicitudes HTTPS a portal.librus.pl y api.librus.pl.
Expone una lista permitida de recursos de API de solo lectura; no puede enviar mensajes, marcar avisos como leídos ni enviar solicitudes arbitrarias.
Deliberadamente no escribe ninguna solicitud, respuesta, credencial, token o payload de API en stdout/stderr. Stdout está reservado para el tráfico del protocolo MCP.
No pongas credenciales en package.json, en la configuración de MCP planificada en git controlado, ni en un archivo .env que esté bajo seguimiento.
Related MCP server: Librus Read-only MCP
cd /home/xadix0wy/librus-mcp
npm install
npm run buildUsa variables de entorno en la configuración privada del host o en su almacén de secretos:
{
"mcpServers": {
"librus": {
"command": "node",
"args": ["/home/xadix0wy/librus-mcp/dist/index.js"],
"env": {
"LIBRUS_EMAIL": "your-email@example.com",
"LIBRUS_PASSWORD": "your-password"
}
}
}
}LIBRUS_CLIENT_ID es opcional. El valor predeterminado es el ID de cliente público del flujo móvil heredado de Librus. No se trata como un secreto.
librus_profiles: enumeras las cuentas de Synergia vinculadas a la cuenta del Portal.
librus_get: lee calificaciones, asistencia, horario, tareas, avisos, información del colegio y otros recursos de API compatibles. Pasa account_login de librus_profiles.
librus_logout: borra todo el material de autenticación en memoria.
El Portal puede requerir un reCAPTCHA o una acción de cuenta. En ese caso, el servidor se detiene con un error claro; completa la acción requerida directamente en https://portal.librus.pl o en la aplicación oficial y vuelve a intentarlo.
Esto depende de un flujo de Portal/API no documentado observado en el código fuente heredado de Szkolny Android. Librus puede modificarlo o restringirlo sin previo aviso. Está destinado únicamente al propietario de la cuenta y debe usarse de acuerdo con los términos de Librus y la política escolar.
Read a supported Librus API resource. This tool is read-only and accepts no arbitrary URL or write operation.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes | The Librus resource to retrieve. | |
| week_start | No | Monday/date for timetable, in YYYY-MM-DD format. Ignored for other resources. | |
| account_login | Yes | The account login returned by librus_profiles. |
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, and it does assert the key safety-relevant trait: the tool is read-only and non-destructive. However, it does not describe return values, pagination, or failure behavior, and since the schema has no output schema, the agent knows neither the shape of the result nor what to expect on unsupported cases.
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?
Two short sentences with the primary verb+resource front-loaded. The second sentence earns its place by constraining scope (read-only, no arbitrary URL), even though it partially restates the word 'read.' Overall it is tight and free of filler.
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?
The description plus fully documented schema adequately cover what the tool does and how to call it, including the dependency expressed in the account_login parameter. Yet with no output schema and no description hint about return shape, an agent invoking this across 27 heterogeneous resources has an at-a-glance fixed description of the response.
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%: the enum of 27 resources, the YYYY-MM-DD pattern with 'ignored for other resources', and the 'account_login returned by librus_profiles' dependency are all already documented in the input schema. The tool description adds no parameter-specific meaning, which fits the baseline of 3 for high schema coverage.
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 ('Read') and resource ('a supported Librus API resource'), so the core capability is clear. The added boundary — 'accepts no arbitrary URL or write operation' — separates it from any generic API-access tool, and the read-only framing naturally distinguishes it from the auth-oriented siblings (librus_profiles, librus_logout), though it never names them.
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 conveys when to use the tool implicitly: when a supported Librus resource needs to be retrieved. It makes explicit exclusions (no arbitrary URLs, no writes), which helps an agent know what NOT to do here, but it does not name an alternative tool or state a precondition such as retrieving account_login via librus_profiles first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all in-memory Librus cookies and tokens. Nothing is persisted to disk.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It clearly states the exact state that changes ('cookies and tokens') and adds persistence context with 'Nothing is persisted to disk.' This goes beyond a bare verb and gives an agent a solid understanding of the tool's boundary, even though it does not explicitly describe post-logout authentication state.
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?
Two short sentences with no filler, and the main action is front-loaded. The second sentence adds an important clarifier about disk persistence without redundancy.
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 zero-parameter, no-annotation, no-output-schema tool, the description is largely complete: it says what is deleted, in what scope, and what is not deleted. An agent may need to infer that subsequent tool calls will require reauthentication, but that follow from the stated clearing of cookies and tokens and does not make the description inadequate.
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?
The tool has zero parameters and 100% schema coverage, so there are no parameter semantics to clarify. The description correctly does not mention parameters, and the baseline of 4 for no-parameter tools 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 states a specific action ('Clear all in-memory Librus cookies and tokens') with a concrete resource. It clearly distinguishes the tool from siblings like librus_get and librus_profiles by targeting session/logout state rather than profiles or data retrieval. There is no ambiguity about what the tool is for.
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 implies the tool is for logging out or ending a session by clearing auth data, so an agent can infer when to use it. However, it does not explicitly say when to use this tool instead of siblings like librus_profiles or librus_get. It could have named these alternatives and given conditions, but the use case is reasonably clear from the token-based action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Librus Synergia accounts linked to the configured Librus Portal account. Use the returned login with librus_get.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description conveys that this is a read-only listing operation and that it depends on the 'configured Librus Portal account,' which is useful. However, no annotations are provided, and the description does not elaborate on possible return formats, errors, or whether multiple accounts may be returned.
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 two short sentences with no filler. The first states the primary purpose; the second gives an essential workflow tidbit. It is front-loaded and each sentence earns its place.
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 no-parameter tool with no output schema, the description is largely complete: it specifies what the tool lists and how the return value should be used. It does not describe the return structure in detail, but that is a minor omission given the tool's straightforward nature.
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?
The tool has zero parameters and an empty input schema, so there are no parameter details to clarify. A baseline of 4 for a 0-parameter tool is appropriate.
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 states a clear action and resource: 'List Librus Synergia accounts linked to the configured Librus Portal account.' It also explicitly names the sibling librus_get as the consumer of the returned data, which distinguishes it from related tools.
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 gives direct workflow guidance: 'Use the returned login with librus_get.' This tells an agent exactly what to do with the result, though it does not explicitly cover when not to use the tool or mention alternate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0librus_getlibrus_logoutlibrus_profilesScored across 3 tools
Each tool has a clear, distinct responsibility: list linked accounts, read a specific API resource, and clear the session. The profiles tool explicitly points to librus_get, removing ambiguity.
All tools share the consistent librus_ prefix and snake_case style, making them easy to recognize. There is a minor inconsistency between noun-based librus_profiles and verb-based librus_get/librus_logout.
Three tools is a minimal but well-scoped set for a read-only, session-based Librus API bridge. Each tool serves a real workflow step: discovering accounts, reading data, and ending the session.
The session lifecycle is covered, but librus_get is generic and does not enumerate which resources are supported. An agent may struggle to know what API resources can actually be requested.
Read Kisi places, doors, users, groups, access rights and access logs (no unlocking).
Read-only access to your CodeMouse accounts, repositories, and AI pull-request reviews.
Read-only access to Genie accounts, transactions, investments, and financial summaries.
Read-only access to your bank, investment, and crypto accounts: balances, transactions, holdings.
