SSU Campus(숭실대학교 캠퍼스)에서 인증된 학생의 u-SAINT 누적 성적을 학기별 GPA 이력과 함께 조회합니다. mcp_session_id 필요(SAINT 로그인). 미인증 시 loginUrl이 포함된 AUTH_REQUIRED를 반환하므로, loginUrl을 사용자에게 보여주고 브라우저에서 로그인하도록 안내한 뒤 발급된 mcp_session_id로 다시 호출하세요.
| Name | Required | Description | Default |
|---|---|---|---|
| mcp_session_id | No | 선택 MCP session ID. 생략하면 현재 MCP transport에 안전하게 바인딩된 세션을 사용합니다. |
Changes observed during successful MCP inspections.
Input schema / properties / mcp_session_id / descriptionPrevious value: -"start_auth(SAINT)로 발급받은 MCP session ID. 없거나 SAINT 미연동이면 loginUrl과 함께 AUTH_REQUIRED를 반환."New value: +"선택 MCP session ID. 생략하면 현재 MCP transport에 안전하게 바인딩된 세션을 사용합니다."Input schema / requiredPrevious value: -[
- "mcp_session_id"
-]New value: +[]Input schema / properties / mcp_session_id / descriptionPrevious value: -"MCP session ID issued by start_auth(SAINT). If absent or SAINT not linked, returns AUTH_REQUIRED with a loginUrl."New value: +"start_auth(SAINT)로 발급받은 MCP session ID. 없거나 SAINT 미연동이면 loginUrl과 함께 AUTH_REQUIRED를 반환."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by disclosing the unauthenticated behavior (returns AUTH_REQUIRED with loginUrl) and instructing the agent to guide the user through login and re-invoke. Annotations already cover read-only and idempotent hints, and the description complements them without contradiction.
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?
Four concise, purposeful sentences. The primary function is front-loaded, followed by the session requirement and authentication failure handling. Every sentence earns its place with no 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?
With no output schema, the description adequately conveys the return content (cumulative grades and semester GPA history) and the main failure mode (AUTH_REQUIRED with loginUrl). It stops short of describing the exact result structure, but it is sufficient for correct invocation and basic error recovery.
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%, and the mcp_session_id parameter is already well-described in the schema with its fallback behavior. The description reinforces the parameter's necessity and auth flow but adds no new semantic meaning beyond the schema baseline.
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 specific action ('조회합니다' / retrieves) and resource ('u-SAINT 누적 성적' / cumulative grades with semester GPA history). It distinguishes itself from siblings like get_my_scholarships and simulate_gpa by focusing on actual stored grades plus GPA history.
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 usage context: requires mcp_session_id and explains the exact re-auth workflow with AUTH_REQUIRED and loginUrl. It does not explicitly mention alternatives or when not to use the tool, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.