Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This server has severe definition quality issues across nearly all tools. Most tools (6/12) have empty input schemas with no parameters, which is a critical failure. Descriptions exist but are minimal (10-60 chars, well below the 50-200 char LLM-optimized baseline of A-grade tools). No parameter descriptions are present for any tool. No output schemas are documented. Error handling is minimal. The server reads like a prototype or internal script rather than a production-grade MCP tool. Only 2 tools (get_stu_email_recent, get_hf_paper_list) have properly typed parameters; the rest lack parameter validation. The FastMCP framework is used correctly for registration, but the tool definitions themselves are underspecified.
All tool descriptions are between 10-60 characters, far below the LLM-optimized baseline of 50-200 characters. Descriptions like '获取学生基本信息' (11 chars) provide no context for WHEN or WHY to use the tool. LLMs cannot determine tool selection intent from such minimal descriptions.
Add 50-200 character descriptions to all 12 tools explaining WHAT they do, WHEN to use them, and WHAT they return. Example: 'Retrieve the current semester courses for the logged-in student, including course code, name, instructor, credits, and enrollment status. Use this to answer questions about course load or schedule conflicts.'
Add descriptions to all input parameters. For topk, write 'Number of recent emails to retrieve (1-100, default 20)'. For mode in get_hf_paper_list, write 'Time period filter: "date" (today), "week" (this week), or "month" (this month)'. For keyword, write 'Search term to filter papers (alphanumeric and spaces only, max 200 chars)'.
Replace empty {} schemas with proper JSON Schema. For get_stu_profile, get_stu_courses, etc., if they truly take no parameters, declare this explicitly with {'type': 'object', 'properties': {}, 'required': []}. Better yet, add context parameters like 'semester' or 'academic_year' if the underlying API supports them.
Convert free-form string parameters to enums where valid values are known. For get_hf_paper_list mode, use {'type': 'string', 'enum': ['date', 'week', 'month']}. For sort_by, use {'type': 'string', 'enum': ['upvotes', 'date']}.
Add bounds to numeric parameters. For get_stu_email_recent topk, use {'type': 'integer', 'minimum': 1, 'maximum': 100, 'default': 20}. Document these in parameter descriptions as well.
Document output schemas. For get_stu_profile, describe: 'Returns a dict with keys: student_id, name, major, admission_year, gpa, class_code'. For get_stu_email_recent, describe: 'Returns a list of email objects with: message_id, from, subject, date'. Ensure downstream tools can use these IDs and fields.
No parameter descriptions exist for any tool. Even get_hf_paper_list and get_gs_paper_list, which have proper type schemas, lack meaningful parameter descriptions beyond the raw parameter name.
No output schemas are documented for any tool. All tools return string representations of Python objects (str(profile), str(courses), etc.), which is unstructured and requires LLM parsing. No field-level documentation exists.
Minimal error handling. Most tools return simple None-coalesce or silent failures (e.g., 'homework = cp.get_stu_current_homework() or []'). No error messages guide the LLM on what went wrong or what to do next. get_rag_search has no implementation (just 'pass').
No input validation or constraint documentation. For example, get_hf_paper_list accepts 'mode' as a string with no enum constraint, leaving LLMs to guess valid values ('date', 'week', 'month'). Similarly, get_stu_email_recent accepts 'topk' with no bounds (1-100? 1-1000?).
Credentials and secrets are hardcoded via environment variables (BJTU_ID, AA_PW) without explicit server-side injection pattern documented. While env vars are better than parameters, there is no evidence of vault or credential rotation strategy.
No permission gates or scope declarations. Tools like get_stu_profile and get_stu_email_* expose sensitive personal data (student profile, email, grades) with no RBAC or audit trail mentioned.
Tool names are generic and context-specific to BJTU (Chinese university). Names like 'get_stu_*' are ambiguous without domain knowledge. 'stu' is not a standard abbreviation for LLMs to parse. Suggest 'get_bjtu_student_profile', 'get_student_grades', etc.
get_rag_search has no implementation (body is 'pass'). This tool is non-functional and will always return None. Either implement it or remove it.
get_rag_search
Implement structured output instead of str(object). Parse the Python objects into JSON-serializable dicts with clear fields. This lets LLMs extract data without manual parsing.
Add error handling with recovery guidance. Example: Instead of silent failure in get_stu_grade, return structured errors: {'error': 'Service unavailable', 'retry_after': 60, 'recovery': 'Login may have expired. Try again in 1 minute.'}
Implement pagination for tools returning lists. Add 'limit' and 'offset' parameters to get_stu_courses, get_stu_current_exam, get_stu_email_recent, and return a 'total_count' and 'has_more' field.
Implement get_rag_search. Currently it is a stub that returns None. Either provide a real implementation or remove the tool.
Add enum constraints to free-form string parameters. For get_gs_paper_list keyword, consider adding validation regex or length limits in the description (e.g., 'Alphanumeric and spaces, max 200 characters').
Rename tools to be less ambiguous. 'get_stu_*' relies on domain knowledge. Consider 'get_student_profile', 'list_student_courses', 'get_student_grades', etc., or prefix with domain context like 'get_bjtu_*' if BJTU-specific.
Add tool annotations (readOnlyHint, destructiveHint) to clarify intent. All 12 tools are read-only, so adding @readOnly helps LLMs understand they are safe to call.
Document prerequisite conditions. Many tools require login (e.g., 'Call after login via the AAService'). Add this to descriptions so agents understand sequencing.
Audit email tools for security. get_stu_email_* expose personal email data. Add scope declarations (e.g., 'read:email') and audit logging to ensure only authorized agents access this data.