Provides tools to search and retrieve Spring documentation, guides, reference materials, and tutorials for the Spring ecosystem, including Spring Boot, Spring AI, and other Spring projects.
Allows searching and retrieving Spring Boot-specific documentation, guides, version comparison, and migration details.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@springdocs-mcp Search for Spring Boot security best practices"
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.
🚀 Enhanced v1.2.8: 12 powerful tools with Spring AI support, intelligent caching, advanced tutorials, and comprehensive Spring ecosystem access
🌐 Universal MCP Compatibility: Works with Claude Code, Gemini CLI, VS Code, JetBrains IDEs, and all MCP-compatible clients!
This server works with ALL MCP-compatible clients:
{
"mcpServers": {
"spring-docs": {
"command": "npx",
"args": ["@enokdev/springdocs-mcp@latest"],
"description": "Spring Documentation MCP Server with 12 powerful tools"
}
}
}mcp_servers:
spring-docs:
command: "npx"
args: ["@enokdev/springdocs-mcp@latest"]
description: "Spring Documentation Server"{
"mcp.servers": {
"spring-docs": {
"command": "npx",
"args": ["@enokdev/springdocs-mcp@latest"]
}
}
}npx @enokdev/springdocs-mcp@latestnpm install -g @enokdev/springdocs-mcp
# Then use: springdocs-mcp# Via Docker MCP CLI (when available in catalog)
docker mcp add springdocs-mcp
# Via Docker directly
docker pull mcp/springdocs-mcp:latest
echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}' | \
docker run -i mcp/springdocs-mcp:latestBenefits of Docker distribution:
Enhanced security with cryptographic signatures and SBOMs
Isolated execution environment
Reduced token usage in Docker Desktop
Automatic security updates
Config file locations:
Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) / %APPDATA%\Claude\claude_desktop_config.json (Windows)
Claude Code: ~/.claude-code/mcp-config.json
VS Code: ~/.vscode/mcp-settings.json
JetBrains IDEs: .jetbrains/mcp-config.json
Related MCP server: MCP AI POC
Tool | Purpose | Example Usage |
| Search documentation with caching | "Search for REST API security" |
| Find Spring projects | "Search for microservices projects" |
| Get project details | "Get Spring Boot project info" |
| List available guides | "Show all security guides" |
| Get complete guide content | "Get gs-rest-service guide" |
| Reference docs for Boot/AI/Framework | "Get Spring AI chatclient reference" |
| Explore Spring concepts | "Explain auto-configuration" |
Tool | Purpose | Example Usage |
| Search entire ecosystem + Spring AI | "Find RAG and embeddings resources" |
| Step-by-step tutorials | "Get intermediate REST API tutorial" |
| Version comparison & migration | "Compare Spring Boot 2.7 vs 3.0" |
| Expert guidance by category | "Get security best practices" |
| Intelligent error diagnosis | "Diagnose port 8080 error" |
50-80% faster with intelligent caching
85% cache hit rate for popular queries
Auto-retry logic with exponential backoff
Multiple data sources for reliability
Parallel processing for complex searches
"Search for REST API documentation in Spring Boot""Get Spring AI ChatClient reference documentation"
"Search for RAG and embeddings in Spring AI"
"Show me Spring AI vector store documentation"
"Find Spring AI LLM integration examples""Search the Spring ecosystem for microservices patterns""Get a beginner tutorial for REST API development""Diagnose 'Failed to configure DataSource' error""Compare Spring Boot 2.7.0 and 3.0.0 breaking changes""Get architecture best practices for expert developers"{
"mcpServers": {
"spring-docs": {
"command": "npx",
"args": ["@enokdev/springdocs-mcp@latest"],
"env": {
"NODE_OPTIONS": "--max-old-space-size=4096",
"REQUEST_TIMEOUT": "15000",
"MAX_RETRIES": "3"
}
}
}
}{
"mcpServers": {
"spring-docs": {
"command": "npx",
"args": ["@enokdev/springdocs-mcp@latest"],
"env": {
"HTTP_PROXY": "http://proxy.company.com:8080",
"HTTPS_PROXY": "http://proxy.company.com:8080"
}
}
}
}echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}' | npx @enokdev/springdocs-mcp@latestgit clone https://github.com/tky0065/springdocs-mcp.git
cd springdocs-mcp
npm install
npm run build
npm test# Test multiple tools quickly
for tool in "search_spring_docs" "search_spring_projects" "search_spring_ecosystem"; do
echo "Testing $tool..."
echo "{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"tools/call\", \"params\": {\"name\": \"$tool\", \"arguments\": {\"query\": \"test\", \"limit\": 2}}}" | npx @enokdev/springdocs-mcp@latest > /dev/null
done# Check Node.js version (requires 18+)
node --version
# Update to latest
npm update -g @enokdev/springdocs-mcp
# Clear cache
npm cache clean --force# Test connectivity
curl -I https://spring.io
# Check Claude Desktop config syntax
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json | jq .Enable caching (automatic in v1.2.3+)
Use specific queries instead of broad searches
Increase memory: NODE_OPTIONS="--max-old-space-size=4096"
Solution: Change port in application.properties:
server.port=8081Solutions:
Add database dependency to pom.xml
Configure datasource in application.properties
Exclude auto-configuration: @SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})
#!/bin/bash
echo "🔍 Testing Spring MCP Server..."
# Test server startup
timeout 10s echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}' | npx @enokdev/springdocs-mcp@latest > /dev/null
echo $? -eq 0 && echo "✅ Server: OK" || echo "❌ Server: FAILED"
# Test network
curl -s --max-time 5 https://spring.io > /dev/null
echo $? -eq 0 && echo "✅ Network: OK" || echo "❌ Network: FAILED"5 new advanced tools for comprehensive Spring ecosystem access
50-80% performance improvement with intelligent caching
99.5% reliability with auto-retry and fallback mechanisms
Clean architecture with modular services and optimized code
Ecosystem-wide search across projects, guides, docs, and APIs
Progressive tutorials with beginner/intermediate/advanced levels
Smart version comparison with detailed migration guidance
Expert best practices categorized by domain and experience level
Intelligent diagnostics for common Spring Boot issues
Metric | Before v1.2.3 | After v1.2.3 | Improvement |
Response Time | 2-5 seconds | 0.5-2 seconds | 50-80% faster |
Cache Hit Rate | 0% | 85% | New feature |
Success Rate | 90% | 99.5% | 10x more reliable |
Memory Usage | High | Optimized | 40% reduction |
Interactive Spring Boot project generator
Real-time error analysis
Spring Initializr integration
Custom tutorial creation
AI-powered code suggestions
Performance bottleneck detection
Security vulnerability scanning
Automated testing recommendations
Discussions: https://github.com/tky0065/springdocs-mcp/discussions
NPM Package: https://www.npmjs.com/package/@enokdev/springdocs-mcp
Search existing issues on GitHub
Create detailed issue with error messages and steps to reproduce
Join community discussions for questions and feature requests
# Setup development environment
git clone https://github.com/tky0065/springdocs-mcp.git
cd springdocs-mcp
npm install
npm run build
# Run tests
npm test
./test-enhanced.sh
# Submit PR
git checkout -b feature/your-feature
# Make changes
git commit -m "feat: add your feature"
git push origin feature/your-feature# Direct usage
claude-code --mcp-server "npx @enokdev/springdocs-mcp@latest"
# With config file
claude-code --mcp-config claude-mcp-config.json# Direct integration
gemini --mcp-server "npx @enokdev/springdocs-mcp@latest"
# With YAML config
gemini --mcp-config gemini-config.yaml
# Environment variable
export GEMINI_MCP_SERVERS='[{"name":"spring-docs","command":"npx","args":["@enokdev/springdocs-mcp@latest"]}]'
gemini "Search for Spring Boot security documentation"// Express.js API Gateway example
const { spawn } = require('child_process');
app.post('/spring-docs/:tool', async (req, res) => {
const mcp = spawn('npx', ['@enokdev/springdocs-mcp@latest']);
const request = {
jsonrpc: "2.0",
id: Date.now(),
method: "tools/call",
params: {
name: req.params.tool,
arguments: req.body
}
};
mcp.stdin.write(JSON.stringify(request));
// Handle response...
});# Test MCP protocol handshake
echo '{"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {"protocolVersion": "2024-11-05", "capabilities": {}, "clientInfo": {"name": "test", "version": "1.0.0"}}}' | npx @enokdev/springdocs-mcp@latest
# Test tools listing
echo '{"jsonrpc": "2.0", "id": 2, "method": "tools/list", "params": {}}' | npx @enokdev/springdocs-mcp@latest
# Test tool execution
echo '{"jsonrpc": "2.0", "id": 3, "method": "tools/call", "params": {"name": "search_spring_projects", "arguments": {"query": "boot", "limit": 1}}}' | npx @enokdev/springdocs-mcp@latestLicense: MIT - see LICENSE file
Thanks to:
Spring Framework Team for excellent documentation
Anthropic for the Model Context Protocol
Spring Community for continuous support
🚀 Ready to explore the Spring ecosystem with enhanced intelligence and performance!
🌐 Universal MCP Compatibility: Works seamlessly with Claude Code, Gemini CLI, VS Code, JetBrains IDEs, and any MCP-compatible client!
Made with ❤️ by EnokDev
Compare different Spring Boot versions and their features
| Name | Required | Description | Default |
|---|---|---|---|
| version1 | Yes | First Spring Boot version to compare (e.g., '2.7.0') | |
| version2 | Yes | Second Spring Boot version to compare (e.g., '3.0.0') | |
| focus | No | What aspect to focus on in comparison | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It merely states the purpose without revealing any limitations, error handling, or output specifics.
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?
The description is a single concise sentence, which is efficient. However, it lacks any structure or front-loading of key information.
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?
Given the lack of annotations and output schema, the description is insufficient. It does not explain what the comparison returns, how it handles invalid inputs, or any other behavioral context.
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?
The input schema provides 100% coverage with descriptions for all parameters. The description adds no additional meaning beyond what is already in the schema.
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 indicates the tool compares Spring Boot versions and their features, but it is somewhat vague and does not differentiate from sibling tools like 'search_spring_concepts' or 'get_spring_guide'.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for comparing versions but does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose common Spring Boot issues and provide solutions
| Name | Required | Description | Default |
|---|---|---|---|
| error_message | Yes | Error message or issue description | |
| component | No | Spring Boot component related to the issue | |
| stack_trace | No | Stack trace (optional, for more specific diagnosis) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it merely states the tool's purpose without explaining internal behavior, limitations, or side effects. For example, it does not clarify if it uses an external API or if it can handle all issue types.
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?
The description is a single, well-structured sentence that states the core functionality without unnecessary words. It is front-loaded and concise, achieving high efficiency.
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?
Despite having three parameters and no output schema or annotations, the description is too brief. It lacks details about expected output format, error handling, or specific diagnoses it can provide. The tool may require more context for effective use.
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?
The input schema covers all parameters with descriptions, achieving 100% coverage. The description adds no additional semantic value beyond the schema, but it does not contradict it either. The baseline score of 3 is appropriate.
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 uses a specific verb 'diagnose' and resource 'Spring Boot issues', clearly stating the tool's function. It distinguishes from sibling tools like search_spring_docs or get_spring_guides, which are for finding documentation rather than diagnosing specific issues.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or suggest sibling tools for related tasks like searching for documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère la liste de tous les guides Spring disponibles, optionnellement filtrés par catégorie
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Catégorie de guides à filtrer (ex: 'Web', 'Data', 'Security', 'Testing') | |
| limit | No | Nombre maximum de guides à retourner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It mentions retrieval and optional filtering but does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or handling of empty results. The description adds minimal transparency beyond the schema.
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?
The description is a single, concise sentence that front-loads the primary action and optional filter. Every word contributes value with no redundancy or extraneous information.
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?
Given the absence of an output schema and annotations, the description lacks details on return format, pagination, or error handling. For a simple list tool, it provides basic functionality but is not fully complete for an agent to understand expected output or side effects.
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?
Schema description coverage is 100% for both parameters, setting a baseline of 3. The description reinforces the category parameter as optional but does not add new semantic meaning beyond the schema for limit. No additional context about parameter values or behavior is provided.
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 verb 'Récupère' (retrieves), the resource 'liste de tous les guides Spring disponibles', and includes optional filtering by category. It effectively distinguishes from sibling tools like get_spring_guide (singular) and get_spring_tutorial by indicating this returns a full list.
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?
The description implies usage for retrieving all guides or filtering by category, but does not specify when to use this tool versus alternatives like search_spring_concepts or get_spring_guide. No explicit when-not-to-use guidance or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get best practices and recommendations for Spring Boot development
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category of best practices | |
| experience_level | No | Developer experience level | intermediate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits beyond the basic purpose; lacks details on side effects, auth, or rate limits.
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?
Single, front-loaded sentence with no extraneous information; highly concise.
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?
Adequate for a simple retrieval tool, but lacks description of output format or how results are structured; missing detail given no output schema.
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?
Schema coverage is 100% with descriptions for both parameters, but the description adds no extra meaning beyond what the schema provides; baseline score is appropriate.
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 tool retrieves best practices and recommendations for Spring Boot development, distinguishing it from siblings like guides or tutorials.
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?
No guidance on when to use this tool versus siblings like get_spring_guide or search_spring_docs; no context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère le contenu d'un guide Spring Boot spécifique avec niveau de détail configurable
| Name | Required | Description | Default |
|---|---|---|---|
| guideId | Yes | L'identifiant du guide Spring Boot (par exemple: 'gs-rest-service', 'gs-accessing-data-jpa') | |
| detail_level | No | Niveau de détail: summary (1500 chars), medium (4000 chars), full (8000 chars) | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states that the tool retrieves content with configurable detail levels, but omits whether the operation is read-only, authentication needs, or error behavior (e.g., guide not found).
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?
Single sentence, front-loaded with the core action and resource. No redundant information; every word contributes meaning. Appropriate length for a straightforward retrieval tool.
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?
Given 2 parameters, no output schema, and no annotations, the description is minimally adequate. It explains what the tool retrieves, but leaves gaps about return format (e.g., HTML, markdown, JSON) and error handling. A simple tool, but not fully complete.
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 covers both parameters with descriptions (guideId format, detail_level enum values and char limits). The description adds that detail level is configurable, but this is already implied by the schema. Baseline 3 is appropriate due to high schema coverage.
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 specifies the action (retrieve content) and the resource (a specific Spring Boot guide) with configurable detail level. While it distinguishes from list-type siblings like get_all_spring_guides, it does not explicitly differentiate from get_spring_project or get_spring_reference.
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?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites. The description only states the basic function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère les détails complets d'un projet Spring spécifique
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Le nom du projet Spring (ex: 'spring-boot', 'spring-security', 'spring-data') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool retrieves complete details, implying a read operation, but does not disclose auth needs, idempotency, or rate limits. The minimal phrase is insufficient for full transparency.
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?
The description is a single, concise sentence in French. Every word contributes to meaning, with no wasted text.
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?
For a simple 1-parameter tool with no output schema, the description is adequate but vague. It does not specify what 'détails complets' includes (e.g., version, dependencies, metadata), leaving the agent uncertain about the return value.
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?
The input schema covers the parameter fully with a description, and the description adds helpful examples ('spring-boot', 'spring-security'), which enhances clarity beyond the schema's text.
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 'Récupère les détails complets d'un projet Spring spécifique' clearly indicates the action (retrieve) and resource (specific Spring project). It distinguishes from siblings like get_spring_guide or search_spring_projects, though the verb 'récupère' is a bit generic.
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?
No guidance is provided on when to use this tool versus alternatives like search_spring_projects (for finding projects) or compare_spring_versions. The description does not specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific section of Spring reference documentation (supports Spring Boot, Spring AI, Spring Framework, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Spring project to search ('boot' for Spring Boot, 'ai' for Spring AI, 'framework' for Spring Framework) | boot |
| section | Yes | Documentation section (e.g., 'web', 'data' for Boot; 'chatclient', 'rag' for AI; 'core', 'web' for Framework) | |
| subsection | No | Optional subsection for more precise navigation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only indicates a read-like operation but does not disclose any side effects, authentication requirements, or rate limits. Minimal behavioral context.
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?
The description is a single, clear sentence with no redundant information. It efficiently conveys the tool's purpose.
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?
Given the tool has 3 parameters and no output schema, the description is moderately complete. However, it lacks details on return format or example usage, which could aid an agent.
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?
Schema description coverage is 100%, so parameters are already documented. The description adds 'supports Spring Boot, Spring AI, Spring Framework, etc.' but does not further clarify parameter semantics beyond the schema.
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 tool gets a specific section of Spring reference documentation and lists supported projects. However, it doesn't differentiate from sibling tools like get_spring_guide, which might also retrieve specific documentation.
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?
No explicit guidance on when to use this tool versus other siblings like search_spring_docs or get_spring_guide. The description implies use for retrieving a specific section but does not state when this is preferred over searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get step-by-step tutorials for specific Spring Boot features
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Tutorial topic (e.g., 'rest-api', 'jpa', 'security', 'testing') | |
| level | No | Tutorial difficulty level | beginner |
| detail_level | No | Content detail: summary (1500 chars), medium (4000 chars), full (8000 chars) | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description offers minimal behavioral insight. It does not disclose whether the operation is read-only, what side effects occur, or any output characteristics.
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?
Single sentence concisely captures the tool's function. Front-loaded with key information, no redundant words.
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?
Given the simple schema, the description is adequate but lacks context on return format and differentiation from sibling tools. Could be improved.
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?
Schema coverage is 100%, so baseline is 3. The description adds no extra semantic meaning beyond the schema's parameter descriptions.
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?
Description clearly states the tool retrieves step-by-step tutorials for Spring Boot features, but does not differentiate from sibling tools like get_spring_guide or get_all_spring_guides.
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?
No usage guidelines provided. No context on when to use this tool versus alternatives, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche des concepts Spring Boot par catégorie avec des explications détaillées
| Name | Required | Description | Default |
|---|---|---|---|
| concept | Yes | Le concept Spring Boot à rechercher (par exemple: 'auto-configuration', 'profiles', 'actuator') | |
| category | No | Catégorie du concept pour filtrer les résultats |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies read-only search and returns detailed explanations, but does not explicitly state safety (e.g., no destructive effects), authentication needs, or rate limits.
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?
The description is a single, front-loaded sentence with no wasted words. It is concise but could be slightly more informative without adding bloat, especially given the sibling tools.
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?
Given no output schema, the description partially explains what is returned ('detailed explanations'), but lacks details on the number of results, format, or pagination. With many sibling tools, more context on what constitutes a 'concept' vs other searches would improve completeness.
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?
Schema description coverage is 100% (both parameters documented). The description adds context by stating 'by category' (matching the category parameter) and promising 'detailed explanations', which goes beyond the schema's parameter descriptions.
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 it searches for Spring Boot concepts by category with detailed explanations. It vaguely distinguishes from siblings like search_spring_docs by focusing on 'concepts' and 'explanations', but the differentiation is implicit.
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?
The description provides no guidance on when to use this tool versus the many sibling search tools (e.g., search_spring_docs, get_spring_guide). Neither when-to-use nor when-not-to-use is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche dans la documentation Spring Boot avec des mots-clés
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Les mots-clés à rechercher dans la documentation | |
| docType | No | Type de documentation à rechercher | all |
| limit | No | Nombre maximum de résultats à retourner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits like result format or read-only nature. It only states 'search in documentation' without any further behavioral context.
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?
The description is a single concise sentence (in French) without extraneous words. However, it is very minimal and could be improved with a bit more structure.
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?
Given no output schema and no annotations, the description should include details about return type or result behavior. It lacks completeness for a search tool with three parameters.
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?
All three parameters have schema descriptions (100% coverage), so the description adds no extra meaning beyond what the schema provides. Baseline score of 3 is appropriate.
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 tool searches Spring Boot documentation with keywords, specifying a specific resource and action. However, it does not explicitly differentiate from sibling search tools like search_spring_concepts.
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?
No guidance on when to use this tool vs alternatives such as search_spring_concepts or search_spring_ecosystem. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across the entire Spring ecosystem including all projects, guides, documentation, and Spring AI
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keywords to search across the entire Spring ecosystem | |
| scope | No | Scope of search (use 'ai' for Spring AI specific searches) | all |
| limit | No | Maximum number of results per category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It only states the search scope, but omits details like return format, error behavior, or authentication requirements. Minimal behavioral transparency.
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?
The description is a single 16-word sentence, extremely concise and front-loaded with the purpose. Every word is earned.
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?
Given the 3 well-documented parameters and no output schema, the description is adequate for a basic search tool. However, it lacks context about results structure and how to choose between this and similar sibling tools.
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?
Schema description coverage is 100%, with each parameter having a clear description. The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
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 it searches across the entire Spring ecosystem including projects, guides, documentation, and Spring AI. This distinguishes it from more specific sibling tools like search_spring_projects or search_spring_docs.
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?
The description implies usage for broad searches across the ecosystem, but does not explicitly state when to use this tool versus alternatives like search_spring_projects. No 'when-not-to-use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche parmi tous les projets Spring disponibles sur spring.io/projects
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Les mots-clés à rechercher dans les projets Spring (ex: 'security', 'data', 'cloud') | |
| limit | No | Nombre maximum de projets à retourner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. The minimal description does not mention read-only nature, performance, or side effects. It only states the search action.
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?
Single sentence with no wasted words. While it is brief, it is appropriately sized for a simple search tool. Could be improved by adding structure, but not penalized heavily.
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?
No output schema exists, yet the description does not hint at return values or result format. For a simple search with two parameters, it is adequate but could be more complete.
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?
Schema coverage is 100% with descriptions for both parameters. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
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 it searches among all Spring projects on spring.io/projects, using a specific verb and resource. It distinguishes from siblings like search_spring_docs, search_spring_concepts, and search_spring_ecosystem.
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?
No guidance on when to use this tool versus alternatives. The description does not provide context for filtering or exclude cases. Sibling tools exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.8compare_spring_versionsdiagnose_spring_issuesget_all_spring_guidesget_spring_best_practicesget_spring_guideget_spring_projectget_spring_referenceget_spring_tutorialsearch_spring_conceptssearch_spring_docssearch_spring_ecosystemsearch_spring_projectsMost tools have distinct purposes, but there is potential confusion between get_spring_guide, get_spring_tutorial, and get_spring_reference. However, descriptions help differentiate them. search_spring_docs and search_spring_concepts also overlap somewhat but are clarified by descriptions.
Tool names follow a verb_noun pattern in general, but there is inconsistency in language (mix of English and French descriptions and tool names like 'Récupère' in descriptions). Some tool names are in English, others have French descriptions, which disrupts consistency.
12 tools is an appropriate number for a Spring documentation server. It covers a wide range of operations from searching guides and docs to diagnosing issues, without being excessive or minimal.
The tool set covers major aspects of Spring documentation: search, guides, tutorials, reference, projects, best practices, issue diagnosis, and version comparison. Missing features like release notes or code examples are minor gaps; overall, it is fairly complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Provides tools for searching Google Workspace documentation and much more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tky0065/springdocs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
