How do I use SJTU MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SJTU MCP Use sjtu_vision to analyze the image at ./photo.jpg" 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.

de en es ja ko ru zh

SJTU MCP

by EternalWavee

Overview Schema Related Servers Score Discussions

Python

Local

SJTU MCP

English | 中文

Claude Code Codex SJTU API Version License

Turn your SJTU Zhiyuan No.1 API key into something you can actually use in Claude Code and Codex.

SJTU MCP wraps the SJTU-hosted model API as a local MCP server, so you can call these models directly from your normal agent workflow instead of hand-writing integration scripts over and over again.

Why This Exists

Have you already applied for an SJTU Zhiyuan No.1 API key, but still found it hard to actually use in practice?

This project exists to solve exactly that problem:

you already have API access
you want to use it from Claude Code or Codex
but the SJTU endpoint itself does not plug directly into these agent tools out of the box
you do not want to rewrite the integration layer every time

Related MCP server: Claude-LMStudio-Bridge

Highlights

Supports Claude Code
Supports Codex
Supports both text and vision tasks
Uses the SJTU OpenAI-compatible endpoint
Fits naturally into existing MCP workflows

Quick Start

For most users, the simplest path is:

git clone this repo
cd into the project directory
install it once
add it as a global MCP server in Claude Code or Codex

git clone https://github.com/EternalWavee/sjtu-mcp.git
cd sjtu-mcp
pip install -e .

After installation, your MCP client can start the server automatically when needed. In normal use, you do not need to manually run the server command every time.

Environment Variables

Required:

SJTU_API_KEY

Optional:

SJTU_API_BASE_URL
SJTU_DEFAULT_TEXT_MODEL
SJTU_DEFAULT_REASONING_MODEL
SJTU_DEFAULT_VISION_MODEL
SJTU_REQUEST_TIMEOUT

How to use them:

.env.example is only a template showing which variables you need
in actual use, put these values into the env block of your MCP configuration

Claude Code

Recommended: User Scope

Use this if you want sjtu available in all your Claude Code projects on this machine.

claude mcp add sjtu --scope user -- python -m sjtu_mcp.server

Then:

open ~/.claude.json
find the sjtu entry
copy the env section from examples/claude-project.mcp.json
replace your-api-key with your real key

Verify:

claude mcp list

Project Scope

Use this if you want to commit a shared config into the repo for teammates.

How to use it:

copy examples/claude-project.mcp.json into your project root as .mcp.json
replace your-api-key with your real key
adjust default models and timeout if needed

Windows / macOS example:

{
  "mcpServers": {
    "sjtu": {
      "command": "python",
      "args": ["-m", "sjtu_mcp.server"],
      "env": {
        "SJTU_API_BASE_URL": "https://models.sjtu.edu.cn/api/v1",
        "SJTU_API_KEY": "your-api-key",
        "SJTU_DEFAULT_TEXT_MODEL": "deepseek-chat",
        "SJTU_DEFAULT_REASONING_MODEL": "deepseek-reasoner",
        "SJTU_DEFAULT_VISION_MODEL": "qwen3vl",
        "SJTU_REQUEST_TIMEOUT": "180"
      }
    }
  }
}

Local Scope

Use this if you only want the server for the current project and do not want to commit the config.

claude mcp add sjtu --scope local -- python -m sjtu_mcp.server

Then add the same env values to the corresponding MCP config entry.

Codex

Recommended: Global Setup

Use this if you want sjtu available in all your Codex projects on this machine.

codex mcp add sjtu -- python -m sjtu_mcp.server

Then:

open your own ~/.codex/config.toml
copy the content from examples/codex-config.toml
replace your-api-key with your real key
save and reload Codex or reload MCP

Verify:

codex mcp list

Config File Setup

If you already manage ~/.codex/config.toml directly, you can use this template:

[mcp_servers.sjtu]
command = "python"
args = ["-m", "sjtu_mcp.server"]

[mcp_servers.sjtu.env]
SJTU_API_BASE_URL = "https://models.sjtu.edu.cn/api/v1"
SJTU_API_KEY = "your-api-key"
SJTU_DEFAULT_TEXT_MODEL = "deepseek-chat"
SJTU_DEFAULT_REASONING_MODEL = "deepseek-reasoner"
SJTU_DEFAULT_VISION_MODEL = "qwen3vl"
SJTU_REQUEST_TIMEOUT = "180"

Tools

sjtu_models
sjtu_text
sjtu_vision
sjtu_cheap_task

Example

Input

请调用 sjtu_vision 分析图片里面的内容 .assets/test.png

test

Output

answer

Suggested Model Usage

deepseek-chat
- default for summaries, rewrites, cleanup, and low-risk text tasks
minimax or glm-5
- useful for lightweight rewriting, classification, or extraction
deepseek-reasoner
- better for tasks that truly need multi-step reasoning
qwen3vl
- a strong starting point for screenshots, OCR-style extraction, and image understanding
qwen3coder
- useful for code-adjacent utility tasks

Notes

This server currently assumes the SJTU endpoint supports OpenAI-compatible /models and /chat/completions.
Local images are encoded as data URLs before sending.
If your campus endpoint has model-specific quirks, extend the routing in src/sjtu_mcp/server.py.

Available Tools

4 tools

sjtu_cheap_taskC

Route common low-risk jobs like summarize, rewrite, classify, and extract.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes
`content`	Yes
`image_path`	No
`image_url`	No
`model`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, and the description only says 'low-risk jobs,' which hints at safety but does not disclose actual behavioral traits like idempotency, side effects, or permission requirements.

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

Conciseness3/5

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

The description is a single sentence, concise but lacking structure. It is front-loaded with the main purpose, but does not expand on important details, making it minimally adequate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters with no descriptions and no annotations, the description is incomplete. It does not specify valid task types, content format, or how image path/url are used, which is insufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning to any of the 5 parameters (task, content, image_path, etc.). It fails to explain valid values or parameter purposes beyond what the schema already shows.

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

Purpose4/5

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

The description clearly states the tool routes common low-risk jobs like summarize, rewrite, classify, and extract, giving a specific verb and resource. It distinguishes from sibling tools by implying a generic task router, though it could be more precise.

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

Usage Guidelines2/5

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. The description only lists example jobs, lacking when-not-to-use or comparisons with siblings like sjtu_text or sjtu_vision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sjtu_modelsA

List available models from the SJTU endpoint.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only states the action (list) but does not explain that it is a read-only operation, any potential side effects, or required permissions. The agent has no additional context beyond the basic purpose.

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 a single, front-loaded sentence with no unnecessary words. It conveys the core functionality efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, the description is somewhat adequate but lacks usage context. It does not explain how the output schema relates to usage or provide hints for integration with sibling tools. The presence of an output schema mitigates the need for return value details, but the description could be more helpful by mentioning use cases.

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?

There are no parameters, so schema coverage is trivially 100%. The description adds no parameter info, which is acceptable as there is nothing to describe. Baseline 4 for zero parameters is appropriate.

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 clearly states the verb (List), resource (available models), and source (SJTU endpoint). It effectively differentiates from sibling tools like sjtu_cheap_task, sjtu_text, and sjtu_vision, which target different operations.

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

Usage Guidelines2/5

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

No guidance provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions for using sjtu_models.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sjtu_textC

Run a plain text task against the SJTU OpenAI-compatible API.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes
`model`	No
`system_prompt`	No
`temperature`	No
`max_tokens`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.3/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as idempotency, side effects, rate limits, or cost. The tool's safety profile (read vs. write) 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.

Conciseness2/5

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

The description is a single sentence but lacks necessary detail. It is under-specified rather than appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, no annotations, and an output schema not described, the description fails to provide a complete picture. The tool's return value and parameter usage are left unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning beyond the parameter names. It does not explain the role of model, system_prompt, temperature, or max_tokens.

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

Purpose4/5

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

The description states the verb 'run' and resource 'plain text task' against a specific API. It distinguishes from vision tasks but does not clarify what 'plain text task' entails compared to the sibling sjtu_cheap_task.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like sjtu_cheap_task or sjtu_vision. No context on cost, speed, or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sjtu_visionC

Run an image understanding task against the default vision model.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes
`image_path`	No
`image_url`	No
`model`	No
`system_prompt`	No
`temperature`	No
`max_tokens`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only states that the tool runs an image understanding task, but does not explain side effects, authentication needs, return type, or limitations. The minimal description is insufficient for safe usage.

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

Conciseness4/5

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

The description is a single short sentence with no extraneous content. However, it sacrifices clarity for brevity; it could be more informative without adding much length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no annotations, and an existing but undescribed output schema, the description is too minimal. It does not explain parameter interplay (e.g., image_path vs image_url) or output format, leaving significant gaps for effective invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds no explanation for parameters such as prompt, image_path, image_url, model, system_prompt, temperature, or max_tokens, leaving their semantics entirely to interpretation from names.

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

Purpose3/5

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

The description states 'Run an image understanding task against the default vision model', which clearly indicates a verb and resource. However, 'image understanding task' is vague and does not specify the exact capability (e.g., captioning, VQA), and it fails to distinguish from sibling tools like sjtu_cheap_task or sjtu_text.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool over alternatives like sjtu_cheap_task or sjtu_text. No prerequisites or exclusions are mentioned, leaving the agent to guess appropriate contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation3/5

sjtu_cheap_task and sjtu_text both handle text tasks, creating potential confusion. sjtu_cheap_task specifies common low-risk jobs, but the boundary with sjtu_text is unclear. sjtu_models and sjtu_vision are distinct.

Naming Consistency4/5

All tools share the consistent 'sjtu_' prefix and snake_case naming, but the pattern varies between adjective_noun (sjtu_cheap_task) and noun-only (sjtu_models, sjtu_text, sjtu_vision), which is mostly consistent with minor deviations.

Tool Count5/5

Four tools is well-scoped for the SJTU endpoint, covering essential capabilities (listing models, text, vision, and a cheap task option) without unnecessary bloat.

Completeness4/5

The set covers core functionalities, but the overlap between sjtu_cheap_task and sjtu_text suggests redundancy; missing streaming or embeddings are minor gaps for basic use.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-glm
io.github.AceDataCloud
MCP server for GLM chat completions using Zhipu AI models via AceDataCloud
AI & Machine Learning Developer Tools
2
mcp-aichat
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
Remote Desktop Commander
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
mcp-qwen-image
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1

Related MCP Servers

claudecode-mcp
Code Execution Developer Tools AI & Machine Learning
trevoraspencer
A
license
A
quality
B
maintenance
Local MCP server that wraps the headless Claude Code CLI as MCP tools, providing stateless access to Claude's coding capabilities through prompt-based interactions. It enables users to execute Claude Code commands with various prompt formats and structured outputs directly from MCP clients.
Updated a month ago (2026-07-28 11:02 UTC)
3
MIT
Claude-LMStudio-Bridge
AI & Machine Learning Developer Tools
infinitimeless
A
license
Not graded
quality
F
maintenance
A simple MCP server that enables Claude to communicate with locally running LLM models via LM Studio.
Updated a year ago (2025-03-21 17:22 UTC)
9
MIT
mcp-local-llm
AI & Machine Learning Text Summarization
aplaceforallmystuff
A
license
Not graded
quality
C
maintenance
MCP server that lets Claude Code delegate mechanical tasks to a local LLM for summarization, classification, extraction, and drafting.
Updated 22 days ago (2026-08-12 18:56 UTC)
12
10
MIT
GPT Proxy MCP Server
AI & Machine Learning Developer Tools
Roxanne299
F
license
B
quality
D
maintenance
MCP server that proxies GPT API calls for Claude Code, supporting multiple GPT models with both standard and streaming responses.
Updated a year ago (2025-08-20 01:55 UTC)
2

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EternalWavee/sjtu-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SJTU MCP

Why This Exists

Highlights

Contents

Quick Start

Environment Variables

Claude Code

Recommended: User Scope

Project Scope

Local Scope

Codex

Recommended: Global Setup

Config File Setup

Tools

Example

Input

Output

Suggested Model Usage

Notes

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API