Librus Portal 계정을 위한 로컬, 읽기 전용 MCP 서버입니다. Portal 로그인 흐름을 사용하여 선택한 Synergia 계정에 대한 유효 기간이 짧은 Librus API 토큰을 획득합니다.
자격 증명은 LIBRUS_EMAIL 및 LIBRUS_PASSWORD에서만 읽습니다.
쿠키와 토큰은 메모리에만 보관되며, 프로세스가 종료되거나 librus_logout이 호출되면 폐기됩니다.
서버는 portal.librus.pl 및 api.librus.pl에 대한 HTTPS 요청만 허용합니다.
읽기 전용 API 리소스의 허용 목록(allowlist)을 노출하며, 메시지를 보내거나, 공지사항을 읽음으로 표시하거나, 임의의 요청을 제출할 수 없습니다.
요청, 응답, 자격 증명, 토큰 또는 API 페이로드를 의도적으로 stdout/stderr에 기록하지 않습니다. stdout은 MCP 프로토콜 트래픽 전용입니다.
자격 증명을 package.json, git에 커밋된 MCP 구성, 또는 추적되는 .env 파일에 넣지 마세요.
Related MCP server: Librus Read-only MCP
cd /home/xadix0wy/librus-mcp
npm install
npm run build호스트의 비공개 구성 또는 비밀 저장소에 환경 변수를 사용하세요:
{
"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는 선택 사항입니다. 기본값은 레거시 Librus 모바일 흐름의 공개 클라이언트 ID입니다. 이 값은 비밀로 취급되지 않습니다.
librus_profiles: Portal 계정에 연결된 Synergia 계정을 나열합니다.
librus_get: 성적, 출석, 시간표, 숙제, 공지사항, 학교 정보 및 기타 지원되는 API 리소스를 읽습니다. librus_profiles의 account_login을 전달하세요.
librus_logout: 메모리에 있는 모든 인증 자료를 삭제합니다.
Portal은 reCAPTCHA 또는 계정 조치를 요구할 수 있습니다. 이 경우 서버는 명확한 오류와 함께 중지됩니다. https://portal.librus.pl 또는 공식 앱에서 필요한 조치를 완료한 후 다시 시도하세요.
이 도구는 레거시 Szkolny Android 소스에서 발견된 문서화되지 않은 Portal/API 흐름에 의존합니다. Librus는 사전 통지 없이 이를 변경하거나 제한할 수 있습니다. 이 도구는 오직 계정 소유자만을 위한 것이며, Librus 이용약관 및 학교 정책에 따라 사용해야 합니다.
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.
