Skip to main content
Glama

simulate_gpa

Read-onlyIdempotent

인증된 학생의 u-SAINT academicRecord를 기반으로 누적 GPA를 시뮬레이션합니다. plannedCredits와 함께 plannedGradePointAverage를 넣어 예상 GPA를 계산하거나, targetGpa를 넣어 필요한 평균 평점을 계산하거나, 둘 다 사용할 수 있습니다. 숭실대학교의 4.5 만점 평점 척도를 사용하며 P/F 학점은 GPA 분모에서 제외합니다. mcp_session_id 필요(SAINT 로그인).

Input Schema

NameRequiredDescriptionDefault
targetGpaNo목표 누적 GPA(0.0~4.5).
mcp_session_idNo선택 MCP session ID. 생략하면 현재 MCP transport에 안전하게 바인딩된 세션을 사용합니다.
plannedCreditsYes추가할 성적 산입 학점(P/F 학점 제외).
plannedGradePointAverageNoplannedCredits의 예상 평균 평점(0.0~4.5).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / mcp_session_id / description
      Previous value: -"start_auth(SAINT)로 발급받은 MCP session ID. 없거나 SAINT 미연동이면 loginUrl과 함께 AUTH_REQUIRED를 반환."New value: +"선택 MCP session ID. 생략하면 현재 MCP transport에 안전하게 바인딩된 세션을 사용합니다."
    • changedInput schema / required
      Previous value: -[
      -  "plannedCredits",
      -  "mcp_session_id"
      -]New value: +[
      +  "plannedCredits"
      +]
  2. Changed4 schema fields changed
    • changedInput schema / properties / mcp_session_id / description
      Previous 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를 반환."
    • changedInput schema / properties / plannedCredits / description
      Previous value: -"GPA-bearing credits to add, excluding P/F credits."New value: +"추가할 성적 산입 학점(P/F 학점 제외)."
    • changedInput schema / properties / plannedGradePointAverage / description
      Previous value: -"Expected average grade point for plannedCredits, 0.0 to 4.5."New value: +"plannedCredits의 예상 평균 평점(0.0~4.5)."
    • changedInput schema / properties / targetGpa / description
      Previous value: -"Target cumulative GPA, 0.0 to 4.5."New value: +"목표 누적 GPA(0.0~4.5)."
  3. Added

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the readOnly/idempotent annotations, the description adds meaningful behavior: it restricts input to authenticated records, specifies Soongsil University's 4.5 scale, and states P/F credits are excluded from the denominator. It also flags the SAINT login/session requirement. The 'mcp_session_id 필요' phrase is slightly ambiguous against the schema's optional mcp_session_id, but it does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and information-dense, covering purpose, modes, grading scale, exclusions, and authentication in a few short sentences. The primary action is front-loaded, and every sentence earns its place without filler.

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?

The description is nearly complete for a read-only, idempotent simulation: it names the source record, all parameter modes, scale, exclusions, and auth context. It stops short of describing the returned shape or the meaning of using both modes simultaneously, which is a small real gap given there is no output schema.

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 coverage is 100%, so the baseline is 3. The description adds value above the schema by explaining how plannedCredits combines with plannedGradePointAverage or targetGpa and by defining credit semantics (P/F excluded). This gives the agent the calculation logic rather than just field ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and object: simulating cumulative GPA from an authenticated student's u-SAINT academicRecord. It also names the two computation modes (plannedGradePointAverage vs targetGpa), which clearly separates this planning tool from read-only grade retrieval siblings like get_my_grades. This goes well beyond the tool name, so an agent knows exactly what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly maps use cases to parameters: plannedGradePointAverage with plannedCredits for expected GPA, targetGpa for required average, and both as a valid combination. This is clear within-tool usage guidance, though it does not invoke any sibling tool or 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources