Loading ToolBench
A Spring Boot-based MCP (Model Context Protocol) server that exposes user management tools for CRUD operations on a user database
This Spring MCP server exposes 10 user management tools with reasonable descriptions and basic parameter schemas. Naming is generally clear and verb-driven (get*, create*, remove*, change*). However, there are critical gaps: several tools include example values in descriptions (against pattern guidance), parameter schemas are inconsistent in completeness, output schemas are not documented, and error handling is not visible. The tool definitions appear to be inferred from a service class via MethodToolCallbackProvider, which limits visibility into actual registration details. Tools follow a sensible composition pattern but lack the rigor expected of production-grade agent tooling.
사용자의 역할을 변경합니다. 일반 사용자를 관리자로 승격하거나 관리자 권한을 취소해야 할 때 사용하세요. 권한 변경은 시스템의 보안과 관련된 중요한 작업입니다. 예: '홍길동 사용자를 관리자로 변경해줘', '이 계정의 권한을 일반 사용자로 바꿔줘', '특정 사용자의 역할을 업데이트해줘'
특정 사용자 이름이 시스템에 이미 존재하는지 확인합니다. 새 사용자를 등록하기 전에 이름 중복 여부를 검사하거나, 특정 사용자의 존재 여부를 확인할 때 사용하세요. 결과는 true(존재함) 또는 false(존재하지 않음)입니다. 예: '홍길동이라는 사용자가 있는지 확인해줘', '이 사용자 이름이 이미 사용 중인지 알려줘', '계정 생성 전에 이름 중복 확인해줘'
새로운 사용자를 시스템에 등록하는 도구로 새 계정을 생성하거나 신규 사용자를 추가할 때 사용하세요. 등록 전에 checkUserExists 도구로 사용자 이름 중복 여부를 확인하는 것이 좋습니다. 예: '새 사용자 계정 만들어줘', '관리자 권한을 가진 새 계정 생성해줘', '카카오 플랫폼으로 새 사용자 등록해줘'
모든 사용자 정보를 조회합니다. 사용자 목록이 필요할 때 이 도구를 사용하세요. 예: '모든 사용자 목록 보여줘', '시스템에 등록된 사용자가 몇 명인지 알려줘', '전체 사용자 정보를 조회해줘'. 페이지네이션이 필요한 경우 getPaginatedUsers 도구를 대신 사용하세요.
페이지네이션과 정렬 옵션을 적용하여 사용자 목록을 조회합니다. 많은 수의 사용자가 있을 때 일부만 가져오거나 특정 순서로 정렬하고 싶을 때 사용하세요. 예: '사용자 목록을 페이지별로 보여줘', '사용자를 이름 순으로 정렬해서 보여줘', '첫 10명의 사용자만 조회해줘', '사용자 목록 두 번째 페이지 보여줘'
사용자 ID로 특정 사용자 정보를 조회합니다. 고유 식별자(ID)를 알고 있을 때 특정 사용자의 상세 정보가 필요한 경우 사용하세요. 예: '고유 ID가 abc123인 사용자 정보 보여줘', '특정 ID로 사용자 찾아줘', '이 ID를 가진 사용자의 상세 정보 알려줘'
Example values embedded in descriptions violate LLM prompt-engineering best practices. Descriptions for getUserById, getUserByUsername, removeUserById, removeUserByUsername, createUser all include UUIDs, usernames ('hong123', 'admin_user'), and enum examples ('KAKAO', 'NAVER', 'GOOGLE'). LLMs tend to reuse example values literally rather than contextually, causing malformed requests.
Output schemas are not documented. The rubric requires documented return types for all tools (100% of A+ tools have documented return types). No tool in this server declares what fields it returns, their types, or structure. LLMs cannot plan downstream tool chains or extract required data without this information.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 63 | - | v1 |
사용자 이름으로 특정 사용자 정보를 조회합니다. 사용자 이름을 알고 있을 때 해당 사용자의 모든 정보를 가져올 때 사용하세요. 사용자 ID보다 이름으로 찾는 것이 더 직관적인 경우에 유용합니다. 예: '홍길동 사용자 정보 보여줘', '사용자 이름으로 계정 정보 검색해줘', '특정 사용자의 상세 정보 알려줘'
특정 플랫폼에 속한 모든 사용자를 조회합니다. 소셜 로그인 플랫폼별로 사용자를 분류하여 볼 때 사용하세요. 예: '카카오로 가입한 사용자 목록 보여줘', '네이버 계정으로 로그인한 사용자들이 몇 명인지 알려줘', '구글 플랫폼 사용자만 조회해줘'
사용자 ID를 기준으로 사용자를 삭제합니다. 특정 ID의 사용자를 시스템에서 완전히 제거해야 할 때 사용하세요. 이 작업은 되돌릴 수 없으니 신중하게 사용해야 합니다. 예: '아이디가 abc123인 사용자 삭제해줘', '특정 ID를 가진 계정을 제거해줘', '시스템에서 이 사용자를 완전히 제거해줘'
사용자 이름을 기준으로 사용자를 삭제합니다. 사용자 ID를 모르지만 이름은 알고 있을 때 계정을 제거하려는 경우 사용하세요. 이 작업은 되돌릴 수 없으니 신중하게 사용해야 합니다. 예: '홍길동 사용자 계정 삭제해줘', '특정 사용자 이름으로 등록된 계정 제거해줘', '이 사용자 이름을 가진 계정을 시스템에서 지워줘'
getAllUsers lacks pagination support. The rubric baseline states tools returning lists should accept page/offset and limit parameters. Without pagination, large user bases blow the context window. getPaginatedUsers exists as a workaround, but getAllUsers should also support pagination or document its max result limit.
No error handling or recovery guidance visible in tool definitions. Descriptions do not explain what happens on error (e.g., user not found, duplicate username on create, permission denied). LLMs need to know: is this retryable? Should I ask the user? Or is it unrecoverable?
Destructive operations (removeUserById, removeUserByUsername) lack confirmation or dry-run support. The rubric pattern 'confirmation-request' states irreversible operations should support a dry-run or confirmation step to prevent catastrophic errors from agent mistakes.
Tool definitions are inferred from MethodToolCallbackProvider wrapping UserService. The actual Spring MCP tool registration is implicit via annotation introspection, not explicit. No @Tool/@ToolParam annotations visible. This affects visibility of explicit schemas and metadata.
createUser and changeUserRole parameters reference 'UserRequestDTO' as a nested object type. Descriptions explain the structure ('username, role, platform'), but the schema shows platform as enum with description mentioning it is unused in changeUserRole. This undocumented parameter dependency (platform required for createUser but ignored in changeUserRole) could confuse LLMs into passing unnecessary data.
No composition metadata. Tool chain documentation is missing. When create_user succeeds, what ID does the response include? Can that be passed to getUserById? changeUserRole references username but getUserById returns by ID, what fields bridge these calls? LLMs need to know which tool outputs feed into which tool inputs.