This server provides an MCP interface to the University of Tokyo's Learning Management System (UTOL/UTokyo LMS), enabling natural language access to course information, assignments, materials, and limited write operations.
Authentication & Session
Check login status — verify if you're authenticated; prompts manual login if not
Refresh cache — re-fetch cached course and assignment data
Course Information
List registered courses — view enrolled courses and timetable
Get course details — retrieve announcements, materials, and assignments for an enrolled course
Search courses — search the public catalog by keyword, teacher, or year (including non-enrolled courses)
Get syllabus — fetch UTAS syllabus info, even for non-enrolled courses
Assignments & Tasks
List all assignments — view assignments/tests with deadlines across all enrolled courses
Get assignment details — view description, deadline, attachments, and submission status (read-only)
Toggle "no submission" flag — mark an assignment as not requiring submission or revert it (write operation, requires confirmation, reversible)
Announcements & Updates
List announcements — view system/course announcements
List updates — view recent activity notifications
List messages — view message/inquiry metadata (no message body content)
Materials
Download material — download a single course material file to a local path (enrolled courses only; bulk downloading not permitted)
Course Registration (Write Operations — require explicit confirmation)
Register for a course — enroll in a course (reversible, audit-logged)
Unregister from a course — drop a course (caution: may cause irreversible data loss, audit-logged)
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@utol-mcp show my assignment deadlines for this week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
東京大学の学習管理システム UTOL (UTokyo LMS) を、MCP クライアント（Claude Desktop など）から 扱えるようにする個人用の MCP サーバーです。受講登録済みの講義・締切・お知らせ・教材・課題などを 自然言語で参照できます。
ローカル実行を前提とし、機能は読み取りが中心です。認証はユーザー本人が公式の UTokyo Account ログイン画面で行い、ツールはパスワードや MFA コードを扱いません。
受講登録済みの講義（時間割）・お知らせ・教材リンクの一覧
全科目を横断した課題・テストの締切一覧、課題詳細の参照
シラバス（UTAS）の参照、受講登録外コースの検索（公開カタログ情報のみ）
教材ファイルの個別ダウンロード
課題の「提出不要」切替、コースの受講登録・解除（確認付きの書き込み操作）
Related MCP server: Canvas MCP Server
配布状態について 本パッケージは調査時点で npm に未公開です。以下の
npx -y utol-mcp ...は npm 公開を想定した手順であり、 公開までは後述の「開発」節のローカルビルド手順（node dist/index.js ...）を利用してください。 なお npm 公開時は、AGPL-3.0 依存（mupdf）に関する後述の注意（ライセンス）を満たす必要があります。
npx で実行する場合は次のとおりです。
npx -y utol-mcp loginブラウザが開くので、UTokyo Account でログインしてください。ログインが確認されると、以降の実行で
再認証が不要になります（セッションは ~/.utol-mcp/ に保存されます）。
状態確認・ログアウト
npx -y utol-mcp auth-status # ログイン済みか確認 npx -y utol-mcp logout # セッションとキャッシュを削除
Claude Desktop などの設定ファイルに次を追加します。
{
"mcpServers": {
"utol": { "command": "npx", "args": ["-y", "utol-mcp", "serve"] }
}
}登録後、クライアントから「今週の課題の締切は？」「〇〇の講義のお知らせを見せて」のように 自然言語で問い合わせできます。
読み取り中心のツールです。
ツール | 説明 | 主な引数 |
| ログイン状態の確認 | — |
| 受講登録している講義（時間割）一覧 |
|
| 講義詳細（お知らせ・教材・課題） |
|
| 全科目横断の課題・テスト一覧と締切 |
|
| 課題詳細（読み取りのみ） |
|
| シラバス（UTAS 参照） |
|
| コース検索（受講登録外可・公開カタログ情報のみ） |
|
| 教材内容を読む（LLM コンテキストへ取り込む） |
|
| 教材ファイルをローカルへダウンロード |
|
| メッセージ一覧（メタのみ・本文なし） |
|
| 主要一覧の再取得 | — |
get_course / get_assignment / get_material / download_material は、受講登録中のコースのみ対象です。
get_material / download_material の対象は get_course が返す materials[].resourceId で指定します。
get_material は内容を読む用途（mode は text＝テキスト抽出／image＝ページ画像化）。抽出非対応形式は download_material を使ってください。
download_material はファイルとして残す用途です。stdio 接続ではサーバーローカルのディスクへ保存（destPath 省略時は ~/.utol-mcp/downloads/）、HTTP 接続では取得用の一時 URL（短TTL・単回使用）を返し、curl で保存します。
受講登録外コースは search_courses が返す公開カタログ情報とシラバスのみを参照できます。
状態を変更する操作です。confirm:true が無い場合は実行せずプレビューのみを返し、実行時は
~/.utol-mcp/audit.log に記録が残ります。特に unregister_course は受講登録・提出物に影響します。
ツール | 説明 | 可逆性 |
| 課題を「提出不要」⇔「未提出」に切替 | 可逆 |
| コースを受講登録 | 解除可能 |
| 受講登録を解除 | 要注意（データ喪失の可能性） |
個人の学習支援を目的とし、大量アクセスや教材収集には用いません。
UTokyo SSO・MFA・CAPTCHA・アクセス制御・レート制限を回避しません。
認証はユーザー本人が正規ログイン画面で行い、ツールは資格情報を収集・保存・入力しません。
受講登録外コースは公開カタログ情報とシラバスのみを取得し、保護された内部コンテンツは取得しません。
セッション情報は機密情報として ~/.utol-mcp/（ディレクトリ権限 700）に保存します。Git・ログ・クラウドには含めないでください。
利用者は大学の規則、UTOL の利用規程、関連法令を守る必要があります。UTOL・大学の利用規程が自動アクセス（スクレイピング）・認証セッションの保存・教材の外部サービス送信・受講登録操作の自動化を許容するかは、利用者自身が原文で確認してください。 禁止されている場合、本ツールの利用は学内処分・契約上の責任の対象となり得ます。
本ツールは無保証で提供されます。利用に伴う損害や不利益について、開発者は一切の責任を負いません。利用者自身の責任で使用してください。
HTTP モードのパスフレーズ・OAuth トークン、およびローカルの UTOL セッションは、いずれも第三者に共有・エクスポートしないでください。これらが漏えいすると、保存済みの UTOL セッションを介してあなたのアカウントでの代理アクセスが可能になります。
UTokyo Account の共有は大学の利用規則に抵触し得ます。本ツールは単一利用者（本人）による利用を前提とし、他人にアクセスさせる第三者向けサービス提供は想定していません。
get_material は教材内容を MCP クライアント（クラウド LLM を含み得る）のコンテキストへ取り込みます。この送信が著作権法上の私的使用（30 条）や非享受利用（30 条の 4）で正当化されるかは不確実です。
教材に複製・アップロード禁止等の個別指示がある場合や、送信先 LLM 事業者の規約・学習利用設定によっては問題が生じ得ます。授業ごとの指示・教材の利用条件・送信先の保存/学習利用設定を確認し、送信は必要最小限にとどめてください。機微な教材については、ローカルモデルまたは学内で承認されたサービスの利用を優先してください。
詳細は docs/AUTHENTICATION_POLICY.md を参照してください。
UTOL のアプリセッションはブラウザ終了時に失われますが、utol-mcp login で確立した UTokyo Account
（Microsoft SSO）の永続セッションが端末に残るため、以降のツール実行時は資格情報・MFA なしの
リダイレクトのみでセッションが再確立されます。再認証の途中で資格情報・MFA・アカウント選択が
要求された場合は直ちに中止し、手動ログインを促します。詳細は
docs/AUTHENTICATION_POLICY.md を参照してください。
TypeScript 製です。npm install 時の prepare スクリプトで dist/ へ自動ビルドされるため、
npx でも動作します。ローカルで開発する場合は次のとおりです。
npm install # 依存 + Chromium 取得 + 自動ビルド
npm run build # 変更を反映する際に再ビルド
npm test # パーサ・日時正規化の単体テスト
npm run typecheck
node dist/index.js login # ローカルビルドでの実行例MCP クライアントにローカルビルドを登録する場合は、serve を次のように指定します。
{ "command": "node", "args": ["/absolute/path/to/utol-mcp/dist/index.js", "serve"] }実 UTOL に対する主要フロー（ログイン・認証再確立・時間割/課題/講義/シラバス/検索/教材DL）は
実機で検証済みです。test/fixtures/raw/（.gitignore 済み）に実 HTML を保存してパーサの
セレクタを確定しています。UTOL 側の画面改修時は、同ディレクトリの HTML を更新して
パーサを再確認してください。
本プロジェクトの自作ソースコードは MIT です。
ただし、依存パッケージのうち mupdf（MuPDF, Artifex Software）は AGPL-3.0-or-later です。本プロジェクトは PDF 処理のため mupdf を直接 import しているため、mupdf と結合した状態で配布・ネットワーク提供する場合、結合著作物全体に AGPL の条件（ソース提供義務、ネットワーク利用条項＝AGPL 第 13 条を含む）が及ぶと評価される可能性があります。MIT の許諾は自作コードにのみ及び、AGPL 依存の義務を打ち消すものではありません。
npm 等への実行可能パッケージの配布、または 第三者へのネットワーク提供を行う場合は、結合著作物としての AGPL 適合（通知・対応ソースの提供・第 13 条への対応）を個別に確認するか、mupdf を互換ライセンスのライブラリ（例: pdfjs-dist, Apache-2.0）へ置換するか、Artifex から別途商用ライセンスを取得してください。
AGPL の条件は、個人利用・非商用利用であっても免除されません。
詳細は LICENSE の「Third-party licenses」節を参照してください。
UTOL にログイン済みかを確認する。未ログインなら手動ログインを案内する（自動ログインはしない）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently states the tool only checks login status and does not perform auto-login, accurately describing its behavioral limits. However, it does not specify the return format or potential side effects, which are minimal given the tool's simplicity.
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 extremely concise at two sentences, with the first sentence front-loading the main purpose. Every sentence earns its place, providing essential behavioral context without waste.
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?
Given the tool's simplicity, the description covers the core functionality well. It lacks explicit mention of output or return values, but for a no-parameter, check-status tool, this is a minor gap. The description is mostly complete.
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 no parameters, and the schema covers 100% of them trivially. The description adds no parameter-level details, which is acceptable because there are none to describe. Baseline score of 4 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 clearly states the tool checks authentication status for UTOL ('UTOL にログイン済みかを確認する'), using a specific verb and resource. It distinguishes from all sibling tools, which focus on course materials and updates, making it the only auth-related tool.
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 provides guidance on what to do based on login status and explicitly states the tool does not auto-login. While it doesn't explicitly mention when to use it versus siblings, the context suggests it should be called before other tools to check authentication, making the guidance clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
教材ファイルを単一・オンデマンドでローカルへ保存する。大量DL不可。受講登録済みコースのみ。get_course の materials[].resourceId で対象教材を指定する。
| Name | Required | Description | Default |
|---|---|---|---|
| destPath | Yes | 保存先の絶対パス | |
| idnumber | Yes | コースの idnumber | |
| resourceId | Yes | 教材の resourceId（get_course の materials[].resourceId） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions single file and no bulk, but does not explicitly state whether the operation is read-only or safe, nor does it discuss authorization details beyond 'registered courses only'.
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 concise: two sentences that cover purpose, constraints, and usage. There is no redundant information, and key points are front-loaded.
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?
Given the simple tool (3 params, no output schema, no annotations), the description covers essential aspects: purpose, constraints, and prerequisite. It does not mention failure behavior or overwriting, but is sufficiently complete for a straightforward download tool.
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 coverage is 100%, so baseline is 3. The description adds minimal value by reiterating the source of resourceId and the absolute path requirement, but does not significantly expand on the schema descriptions.
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 clearly states the tool downloads teaching material files to local storage on-demand, specifying single file, no bulk, and only for registered courses. It distinguishes from siblings by focusing on download operation, which no other tool does.
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 explicitly states when to use: for registered courses only, single file on-demand, and that bulk download is not allowed. It also tells how to specify the target material using resourceId from get_course, providing clear prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
課題の詳細（説明・締切・添付・提出状況）を取得する。読み取りのみ・受講登録済みコースのみ。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 課題詳細ページの URL（list_assignments/get_course の url） | |
| idnumber | Yes | コースの idnumber |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It explicitly states read-only behavior and scope (registered courses). It also discloses the types of information returned (description, deadline, attachments, submission status). It does not mention error handling or idempotency, but for a simple read operation, this is adequate.
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 extremely concise at two short sentences. It front-loads the purpose and then adds constraints. No unnecessary words or repetition.
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?
Given no output schema, the description lists the main return fields (description, deadline, attachments, submission status), which is sufficient for a getter tool. However, it does not specify the output format or structure, which might leave some ambiguity. Overall, it provides enough context for an agent to understand what the tool does.
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%, with clear descriptions for both parameters (url and idnumber). The description adds no additional information about the parameters beyond the schema, so a baseline of 3 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?
Description clearly states the specific verb 'get' and resource 'assignment details', listing included fields (説明, 締切, 添付, 提出状況). It distinguishes itself from siblings like list_assignments by indicating it retrieves details of a single assignment, not a list. The constraint 'read-only, only for registered courses' further clarifies scope.
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?
Description provides context for when to use (when needing assignment details, read-only, registered courses). It does not explicitly mention when not to use or suggest alternatives like list_assignments for listing, but the sibling context and the phrase 'only for registered courses' offer implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
講義の詳細（お知らせ・教材一覧・課題一覧）を取得する。受講登録中コースのみ。
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | ||
| idnumber | Yes | コースの idnumber（例: 2025_0340_FEN-EE3902E1_01） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adds context by listing returned components (announcements, materials, assignments), but does not disclose read-only nature, authentication needs, or potential side effects. Partial but not comprehensive.
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 sentences, each essential. No redundancy, clearly front-loaded with purpose and constraint.
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?
Given no output schema and only 2 params, the description specifies what is returned (but not format) and the registration constraint. Adequate for a simple retrieval tool but could be more complete regarding output structure and prerequisites.
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 schema covers 50% (idnumber has example). The description does not add any parameter meaning beyond the schema, and the refresh parameter lacks description in both. The description fails to compensate for the low 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 clearly states the tool retrieves course details including announcements, materials, and assignments, and specifies it only works for registered courses. This verb+resource combination distinguishes it from siblings like list_courses or get_syllabus.
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 use when needing detailed course info, but does not explicitly state when to use versus alternatives or mention exclusion cases. The restriction to registered courses is helpful but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
シラバスを取得する（UTAS のシラバス参照ページ）。公開情報のため受講登録外コースも取得可。受講登録済みコースは idnumber のみで可。受講登録外コースは search_courses が返す syllabusUrl を渡す。
| Name | Required | Description | Default |
|---|---|---|---|
| idnumber | Yes | コースの idnumber | |
| syllabusUrl | No | UTAS シラバス URL（search_courses の syllabusUrl）。受講登録外コースはこちらを渡す。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the tool accesses public information and can retrieve non-registered courses, implying read-only behavior and no special authentication. However, it does not explicitly state that it does not modify data, lacks side effects, or require permissions. More explicit disclosure would improve transparency.
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 concise and well-structured. It starts with the main purpose, then explains the two distinct scenarios with separate parameters. Every sentence provides essential information 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?
Given the tool's simplicity (2 parameters, no output schema), the description adequately covers the two use cases and prerequisite information (search_courses for non-registered). It could briefly mention the output format but is complete enough for an agent to select and invoke the tool correctly.
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?
Input schema coverage is 100% with descriptions for both parameters. The description adds contextual meaning by specifying the use cases for each parameter (idnumber for registered courses, syllabusUrl for non-registered courses). This goes beyond the schema descriptions and helps the agent select the correct parameter.
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?
Description clearly states the tool retrieves a syllabus from UTAS, specifies public info accessible for non-registered courses, and distinguishes between registered (idnumber only) and non-registered (syllabusUrl) cases. It also references sibling tool search_courses, differentiating its usage.
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 provides clear context on when to use idnumber vs. syllabusUrl based on registration status. It does not explicitly state when not to use the tool or list alternatives beyond referencing search_courses, but the guidance is sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
お知らせ一覧を取得する（時間割ヘッダー左上の吹き出しアイコン）。
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states the tool gets a list, without disclosing any side effects, authentication needs, rate limits, or data scope (e.g., time range, read-only nature). The 'refresh' parameter is not addressed.
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 very short (one sentence), which is concise, but it lacks structure and does not use formatting to enhance readability. Every word is earned, but the content is minimal.
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?
Given no annotations, no output schema, and minimal description, the tool definition is highly incomplete. It fails to convey any behavioral context, parameter semantics, or usage guidance, leaving the agent with insufficient information to invoke the tool correctly.
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 only parameter, 'refresh', is a boolean with no description in the schema (0% coverage). The description does not mention parameters at all, so the agent has no information about what 'refresh' does or how to use it.
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 explicitly states the tool retrieves a list of announcements ('お知らせ一覧を取得する'), and the UI reference further clarifies its context. The name and title are also clear, making the purpose unambiguous. However, the Japanese language may limit understanding for non-Japanese agents.
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?
No guidance is provided on when to use this tool versus alternatives like 'list_messages' or 'list_updates'. The description does not mention any conditions or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
全科目横断の課題・テスト一覧と締切を取得する。
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'get' but does not disclose read-only nature, auth requirements, or other behavioral traits. The description is insufficient for an agent to understand side effects or constraints.
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 a single sentence, concise and front-loaded. However, it sacrifices substance for brevity. Almost efficient but lacks critical details.
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 simple tool with one parameter and no output schema, the minimal description falls short. It does not explain the return format or the effect of the 'refresh' parameter, making the tool under-specified.
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 schema has one boolean parameter 'refresh' with 0% coverage (no description). The tool description does not mention or explain this parameter, adding no value beyond the schema. With low coverage, description must compensate but fails completely.
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 clearly states the verb (取得する - get/retrieve) and the resource (全科目横断の課題・テスト一覧と締切 - list of assignments/tests and deadlines across all subjects). It effectively distinguishes from sibling tools like get_assignment (singular) and list_courses.
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?
No guidance on when to use this tool vs alternatives such as get_assignment for a specific assignment. The description does not mention prerequisites or expected context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
受講登録している講義（時間割）の一覧を取得する。
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | true でキャッシュを無視して再取得 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, and the description does not disclose behavioral traits such as caching behavior (despite the 'refresh' parameter hinting at it), side effects, or authentication needs. The description adds little beyond the parameter schema.
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 a single, concise sentence that is front-loaded with the core purpose. No unnecessary words or repetition. It is optimally sized for its content.
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 simple list tool with one optional parameter and no output schema, the description is minimally adequate. However, it lacks details about the list's scope (e.g., all registered courses? current term?), caching behavior, and return format, which would be helpful for an agent.
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 input schema has 100% coverage (one parameter 'refresh' with a description). The tool description does not add any additional meaning beyond what the schema provides, so the baseline score of 3 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 clearly states the tool returns a list of registered lectures (timetable), using a specific verb and resource that distinguishes it from sibling tools like 'get_course' (single course) or 'search_courses' (search).
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
メッセージ一覧（UTOL のメッセージ＝inquiry）を取得する。一覧のメタ情報のみで本文は含まない。
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: it returns only meta information and not the body text. However, with no annotations, it lacks disclosure of authentication requirements, rate limits, side effects, or pagination behavior. It partially informs but is incomplete.
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 consists of two concise sentences that are front-loaded with the core purpose. Every sentence adds value, and there is no extraneous information.
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?
Given no output schema and only one parameter, the description is too sparse. It does not specify the structure of the returned list, pagination, ordering, or any error conditions. An agent would lack sufficient context to expect the exact response format.
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 parameter 'refresh' has no description in the schema, and the description does not mention it at all. With 0% schema description coverage, the description fails to add any meaning to the parameter.
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 clearly states it retrieves a list of messages (UTOL messages = inquiry) and specifies that it includes only meta information, not the body text. This gives a specific verb+resource+scope, but could be more explicit about distinguishing from similar sibling tools like list_announcements.
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?
No guidance is provided on when to use this tool versus alternative sibling tools such as list_announcements. There is no mention of prerequisites or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
更新情報（最近の活動）を取得する（時間割ヘッダー左上のベルアイコン）。教材追加・課題追加・提出・お知らせ等の通知。
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states what the tool retrieves, not any side effects, authentication requirements, or limits (e.g., number of updates, refresh behavior). This leaves the agent underinformed.
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 concise, front-loads the purpose with a clear verb and resource, and provides examples of content types. It wastes no words, though it could benefit from parameter documentation.
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?
With one undocumented parameter and no output schema or annotations, the description is incomplete. It explains the purpose adequately but omits parameter behavior and result details. For a simple tool, more is expected.
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 single parameter `refresh` (boolean) has 0% schema description coverage, and the tool description does not mention it at all. The description adds no value beyond the schema, which itself provides no meaning.
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 clearly states the tool retrieves update information (recent activities) from the bell icon, listing types like material addition, assignment addition, submission, announcements. It effectively communicates the purpose and scope, though it does not explicitly distinguish from siblings like list_announcements or list_assignments.
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 provides no guidance on when to use this tool versus sibling tools (e.g., list_announcements, list_assignments). Usage context is implied (for recent updates) but no explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
主要な一覧（受講登録コース・課題一覧）を再取得してキャッシュを更新する。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It states 'reacquire' and 'update cache' but does not disclose whether the operation is destructive, requires permissions, makes network calls, or if it returns any data. The behavioral impact is unclear.
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 a single concise sentence that front-loads the core action. No unnecessary words; each part is essential.
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 tool with no annotations, no output schema, and no parameters, the description is minimal. It does not explain the effect on the system, whether it returns data, or how it interacts with sibling tools (e.g., does it invalidate cache before listing?). This leaves the agent without sufficient context for reliable invocation.
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?
There are no parameters (schema coverage 100% via empty schema). According to baseline rule, score is 4 since the description does not need to add parameter meaning.
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 clearly states the verb 'reacquire' and the resource 'main lists (enrolled courses, assignment list)' to update the cache. It distinguishes from siblings like list_courses and list_assignments by focusing on cache refreshing rather than just retrieval.
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?
No guidance is provided on when to use this tool vs. alternatives (e.g., whether it should be called before list_courses to ensure fresh data). The description implies usage when cache is stale but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
コースを受講登録する。【書き込み操作・受講登録（UTOL上のデータ）に影響】confirm:true が無い場合はプレビューのみ。実行は監査ログに記録。可逆（unregister_course で解除可能）。
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | true で実際に登録を実行。省略時はプレビューのみ。 | |
| idnumber | Yes | 登録するコースの idnumber（search_courses で取得） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full burden. It discloses that this is a write operation affecting data, notes audit logging, and states reversibility. The preview behavior is also explained.
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 concise (a few sentences in Japanese) and includes essential behavioral details. It is slightly dense but not verbose.
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?
Given no output schema, the description does not need to explain return values. It covers the main behavioral aspects, but could be more complete by describing what the preview returns. Adequate but not exhaustive.
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 coverage is 100%, and the description adds meaning: it explains that confirm controls preview vs. actual registration and that idnumber comes from search_courses. This provides context beyond the schema.
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 clearly states the tool registers for a course (コースを受講登録する). It distinguishes itself from siblings like unregister_course by explicitly noting reversibility.
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 explains that without confirm:true, only a preview occurs, and execution is logged. It mentions the alternative sibling (unregister_course) for reversal. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UTOL のコース検索。受講登録外コースも対象だが、返却は公開カタログ情報（名称・教員・開講期・開講組織・概要・リンク）のみ。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 開講年度 | |
| limit | No | 最大件数（既定30） | |
| keyword | No | フリーワード（コース名・教員名・概要） | |
| teacher | No | 教員名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that non-enrolled courses are included and only public catalog info is returned. It lists the specific fields returned. However, it does not mention pagination, authentication, or behavior when no results found.
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 a single concise sentence that immediately communicates the tool's purpose and scope, with no extraneous information.
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?
Given no output schema, the description adequately lists the returned fields. It could be more complete by mentioning output format or error behavior, but it covers the essential behavioral context.
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 descriptions already cover all four parameters (year, limit, keyword, teacher). The tool description adds no further parameter-level details, so it does not exceed baseline for 100% 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 clearly states the tool searches courses in UTOL, including non-enrolled courses, and specifies the returned fields (name, instructor, semester, etc.). This distinguishes it from siblings like list_courses.
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 implicitly guides when to use (searching broadly, including non-enrolled) and what is returned (public catalog info). However, it does not explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
課題の「提出不要」フラグを変更する（提出不要⇔未提出、可逆）。【書き込み操作】confirm:true が無い場合は実行せずプレビューを返す。実行は監査ログに記録される。
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | true で実際に変更を実行。省略時はプレビューのみ。 | |
| idnumber | Yes | コースの idnumber | |
| contentsId | Yes | 課題の contentsId（list_assignments の contentsId または id） | |
| contentsType | No | 既定は list_assignments の contentsType（通常 '1'） | |
| noSubmission | Yes | true=提出不要にする / false=未提出に戻す |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: it is a write operation (【書き込み操作】), requires confirm:true to execute (otherwise returns preview), and execution is logged. Since no annotations are provided, the description carries the full burden and succeeds.
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 concise at two sentences, with no unnecessary words. It front-loads the primary purpose and then adds key behavioral details. Slightly more structure (e.g., bullet points) could improve readability, but it is efficient.
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?
Given the tool's moderate complexity (5 parameters, no output schema), the description covers the essential behavior but lacks details on return values or error cases. It explains preview vs. execution and logging, but an agent might benefit from knowing what the response looks like.
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 coverage is 100%, so baseline is 3. The description does not add new parameter information beyond what the schema already provides (e.g., confirm behavior is duplicated from schema). No additional meaning is conveyed for the other parameters.
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 clearly states the verb '変更する' (change) and the resource '提出不要フラグ' (no-submission flag), and explicitly mentions the operation is reversible. It distinguishes from sibling tools, which are mostly read-only or different write operations.
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?
No explicit guidance on when to use this tool versus alternatives is given. However, the sibling tools are mostly unrelated (list, get, auth), so the usage context is implicitly clear. The description does mention the confirm parameter behavior, which is a partial guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
コースの受講登録を解除する。【書き込み操作・受講登録（UTOL上のデータ）に影響／要注意】confirm:true が無い場合はプレビューのみ。実行は監査ログに記録。
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | true で実際に解除を実行。省略時はプレビューのみ。 | |
| idnumber | Yes | 解除するコースの idnumber |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It declares the operation as a write that affects UTOL data, warns caution, explains the preview mode (no confirm), and notes execution is recorded in audit log. This discloses all key behavioral traits.
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 concise sentences that front-load the purpose and then deliver critical behavioral details. Every sentence adds value with no redundancy or fluff.
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 simple tool with two parameters and no output schema, the description covers purpose, preview mode, audit logging, and caution. Could mention the inverse relationship with register_course, but overall it's complete enough for safe use.
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 coverage is 100%, meeting the baseline. The description restates the confirm parameter's behavior from the schema but adds no new meaning beyond that. Since no extra parameter insight is provided, a score of 3 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?
Description clearly states the action: unregister from a course (コースの受講登録を解除する). It distinguishes from the sibling register_course by being its inverse. The verb '解除する' specifies the operation on the resource 'コースの受講登録'.
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?
Provides clear context: it's a write operation affecting course registration, requires caution, and has a preview mode via confirm parameter. Explicitly describes when preview occurs (no confirm:true). Lacks explicit comparison to sibling tools, but the preview hint guides safe usage.
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.0auth_statusdownload_materialget_assignmentget_courseget_syllabuslist_announcementslist_assignmentslist_courseslist_messageslist_updatesrefresh_cacheregister_coursesearch_coursesset_task_no_submissionunregister_courseScored across 15 tools
Each tool has a clearly distinct purpose and target resource (e.g., courses, assignments, messages, updates). Descriptions precisely define scope and usage, leaving no ambiguity between tools that might seem similar (e.g., get_assignment vs list_assignments, list_announcements vs list_updates).
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_course, list_courses, register_course). Verbs like 'get_', 'list_', 'search_', 'download_', 'refresh_', 'register_' are used predictably to indicate action type, enhancing readability and predictability.
With 15 tools, the set is well-scoped for a university LMS MCP server. Each tool addresses a discrete operation without redundancy, covering authentication, course management, assignments, materials, syllabus, announcements, messages, and updates. The count feels complete and manageable.
Core student workflows are covered (view courses, assignments, materials, announcements; register/unregister courses; check syllabus). However, missing tools for assignment submission, grade viewing, and sending messages represent notable gaps that would hinder agents from completing common tasks without workarounds.
Create projects, nodes, and tasks in UluP Spaces by conversation with Claude.
AI-powered corporate learning platform — manage courses, users, and insights via Claude.
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
Search, read, create and edit your Memol notes from Claude. Team note-taking with AI search.
