Uses Git to clone repositories for analysis, enabling quick setup and indexing of codebases.
Allows cloning and analyzing any public GitHub repository to understand its Spring Boot architecture without running the application.
Provides deep understanding of Spring Boot projects, including endpoints, dependencies, class structures, and architectural insights through static analysis.
Enriches endpoint data with live information from Swagger docs or Spring Actuator if the application is running.
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., "@spring-api-intel-mcp Trace the /api/v1/orders endpoint through to the database"
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.
An MCP (Model Context Protocol) server that gives AI assistants deep understanding of Spring Boot codebases — without even running the application.
Point it at any Spring Boot project to understand the architecture and get a quick understanding of the project. Ask questions in plain English:
"What endpoints exist and what do they do?"
"Trace the /api/v1/orders endpoint through to the database"
"What classes depend on ValidationService?"
"What version of Java and Spring Boot is this project using?"
"Summarize what PaymentController does and flag any design observations"
"Generate a visual architecture dashboard for this project"
"Analyse this GitHub repo: gothinkster/spring-boot-realworld-example-app"
User: Set the project to C:\projects\my-spring-app
Claude: Switched to project: C:\projects\my-spring-app
Indexed 34 classes and 13 endpointsUser: Analyse this repo: gothinkster/spring-boot-realworld-example-app
Claude: Cloned: https://github.com/gothinkster/spring-boot-realworld-example-app
Location : C:\Users\pmodi\AppData\Local\Temp\springboot-intel\spring-boot-realworld-example-app
Classes : 116
Endpoints: 17
Ready — ask me anything about this codebase.User: Summarize the CustomerService class
Claude: Overview — A Spring @Service class responsible for all customer-related
business logic. Uses constructor injection for its dependencies.
Dependencies:
CustomerRepository — handles database persistence for Customer entities
GeoCoderService — resolves postal codes to geographic location data
Key Design Points:
Uses DTOs to separate the API layer from the domain model
Custom exceptions thrown for clear error handling
Logging via SLF4J on destructive operations like deletesUser: Trace the /api/v1/customer/get endpoint
Claude: [GET] /api/v1/customer/get
Controller : CustomerController.getAllCustomers()
Service calls:
→ customerService.getAllCustomers()
→ customerRepository.findAll() [repository]
Returns : ResponseEntity.ok(customers)User: Generate a dashboard for this project
Claude: Dashboard generated and opened in your browser.
File: C:\projects\my-spring-app\dashboard.htmlRelated MCP server: CodeFlow MCP Server
Tool | Description | MCP Primitive |
| Switch the active project at runtime — no config changes needed | Tool |
| Clone any public GitHub repo and index it instantly | Tool |
| Lists all REST endpoints grouped by controller with service call detection | Tool |
| Traces the full call chain: controller → service → repository | Tool |
| Finds all classes that reference a given class name | Tool |
| AI-generated plain-English class summary via MCP Sampling | Tool + Sampling |
| Extracts Java version, Spring Boot version, build tool and all dependencies | Tool |
| Generates a self-contained HTML architecture dashboard, auto-opens in browser | Tool + Sampling |
| Re-scans the project to pick up new or changed files | Tool |
| Lists all cached GitHub clones with their disk usage | Tool |
| Deletes a specific cached repo to free disk space | Tool |
| Deletes all cached repos to free disk space | Tool |
| Resets saved project state so the server starts fresh next session | Tool |
generate_dashboard produces a self-contained HTML file and opens it in your
default browser automatically — no server, no internet connection required.
It includes:
Architecture layers — color-coded view of controllers, services, and repositories with clickable class chips
Interactive dependency graph — D3-powered force layout showing which classes depend on which, with draggable nodes
Tech stack summary — Java version, Spring Boot version, build tool, class and endpoint counts
Endpoint breakdown — bar chart of endpoints by HTTP method
Key insights — AI-generated architectural observations via MCP Sampling
Class overview table — every class, its role, method count, and dependencies at a glance
The dashboard is generated from static analysis — no running JVM needed. The project description and key insights are written by Claude via Sampling, so they read like a senior developer wrote them rather than a script.
The file is saved as dashboard.html in the project root and can be committed
to the repository as living documentation.
This server implements all three core MCP primitives:
Tools — thirteen callable tools that Claude invokes based on natural language. No special syntax needed — just describe what you want.
Prompts — pre-built prompt templates accessible via the + button in
Claude Desktop. Includes summarize-class, trace-endpoint,
onboarding-overview, find-usages, architecture-review,
generate-dashboard, and analyse-github-repo.
Select one, fill in the arguments, and Claude fires the optimised prompt
automatically.
Sampling — the most advanced primitive. Used by both summarize_class
and generate_dashboard. The server sends a sampling/createMessage request
back to Claude Desktop, asking it to generate content using the user's
existing Claude session. This means:
No Anthropic API key required
No separate billing — uses the user's existing Claude session
Works on the free tier
The server orchestrates AI generation rather than just returning raw data
Both tools fall back gracefully to raw structured data if the client does not support sampling.
At startup the server loads the last active project from its persisted state
file (.server_state.json) and indexes it automatically — no manual setup
needed after the first run.
The server walks all .java files in the target project and builds an
in-memory index of:
All classes, their annotations, methods, and injected dependencies
All REST endpoints parsed from @RestController / @RequestMapping annotations,
including old-style @RequestMapping(method = RequestMethod.GET), array paths
@GetMapping({"/path1", "/path2"}), and multi-line annotations
The full controller → service → repository call chain per endpoint
The active project can be changed at any time via set_project or
clone_and_set_project — no config edits or client restarts needed. The new
project is persisted automatically so it loads on next startup.
If the Spring Boot app is running, list_endpoints also enriches results with
live data from Swagger (/v3/api-docs) or Spring Actuator (/actuator/mappings).
The parser is regex-based so it works on any Spring Boot project without compilation or a running JVM.
All tool calls and errors are logged to server.log in the project root for
easy debugging.
Python 3.10+
git (required for clone_and_set_project)
Claude Desktop or Cursor (FREE tier works)
pip install spring-api-intel-mcpThat's it. The springboot-intel command is now available on your machine.
uv tool install spring-api-intel-mcpgit clone https://github.com/mparth14/spring-api-intel-mcp
cd spring-api-intel-mcp
uv syncFind your config file:
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows (Store install): %LOCALAPPDATA%\Packages\AnthropicPBC.Claude_*\LocalCache\Roaming\Claude\claude_desktop_config.json
Windows (direct install): %APPDATA%\Claude\claude_desktop_config.json
If installed via pip (Option A or B):
{
"mcpServers": {
"springboot-intel": {
"command": "springboot-intel",
"args": [],
"env": {
"SPRING_PROJECT_ROOT": "",
"SPRING_BOOT_URL": ""
}
}
}
}If using the cloned repo (Option C):
{
"mcpServers": {
"springboot-intel": {
"command": "uv",
"args": [
"--directory", "/path/to/spring-api-intel-mcp",
"run", "server.py"
],
"env": {
"SPRING_PROJECT_ROOT": "",
"SPRING_BOOT_URL": ""
}
}
}
}Add to ~/.cursor/mcp.json (Mac/Linux) or %USERPROFILE%\.cursor\mcp.json (Windows):
If installed via pip:
{
"mcpServers": {
"springboot-intel": {
"command": "springboot-intel",
"args": [],
"env": {
"SPRING_PROJECT_ROOT": "",
"SPRING_BOOT_URL": ""
}
}
}
}If using the cloned repo:
{
"mcpServers": {
"springboot-intel": {
"command": "uv",
"args": [
"--directory", "/path/to/spring-api-intel-mcp",
"run", "server.py"
],
"env": {
"SPRING_PROJECT_ROOT": "",
"SPRING_BOOT_URL": ""
}
}
}
}On Windows use double backslashes in the --directory path: C:\\path\\to\\...
Restart your client after saving the config. You should see a hammer icon (Claude Desktop) or MCP indicator (Cursor) confirming the server is connected.
Leave
SPRING_PROJECT_ROOTempty. The server remembers the last active project across sessions via.server_state.json. Useset_projectorclone_and_set_projectin chat to point it at a codebase.
Windows PATH note: If installed via pip and
springboot-intelis not recognised as a command, add your Python Scripts folder to PATH. Runwhere springboot-intelto find the path, then add that folder to your system PATH environment variable.
No manual cloning needed — just pass the URL or owner/repo shorthand:
Analyse this repo: gothinkster/spring-boot-realworld-example-app
Analyse this repo: https://github.com/spring-projects/spring-petclinicThe server clones with --depth=1 for speed, indexes it immediately, and
all tools work against the remote codebase. Re-running on the same repo
skips the clone and just reindexes from the cached copy.
Clones are stored in your system temp folder under springboot-intel/ and
persist across sessions. Use list_cloned_repos to see cached repos and
their disk usage, and delete_cloned_repo or delete_all_cloned_repos to
free up space.
Note: Public repositories only. For private repos, clone manually and use
set_projectinstead. Repos over ~500MB may timeout — clone manually withgit clone --depth=1and useset_projectinstead.
Set the project to C:\projects\my-spring-appClaude calls set_project, the index rebuilds, and all subsequent queries
run against the new codebase. The project path is saved automatically for
next session.
List all the endpoints in my Spring Boot project
Trace the /api/v1/customer/create endpoint
What classes use CustomerService and where?
Summarize the AccountService class
What version of Java and Spring Boot is this project using?
Generate a dashboard for this project
Reindex the project
List my cached repos and their sizes
Delete the spring-petclinic cloneThese prompts cause Claude to call several tools in sequence and synthesise a complete answer — good ones to screenshot for a demo:
I'm new to this codebase — give me a full onboarding overview
Which endpoints have no authentication annotations?
If I modify the Customer model, what else would be affected?
Give me a full architecture review of this codebaseClick the + button next to the chat input to access pre-built prompts:
Prompt | What it does |
| Clone and analyse any public GitHub repo |
| AI summary of any class |
| Full call chain walkthrough |
| Cross-codebase reference search |
| Full codebase overview for new developers |
| Endpoints, dependencies, and design observations |
| Visual HTML architecture dashboard, auto-opens in browser |
Repo | What makes it good to test |
| Clean layered architecture, good baseline |
| 21 endpoints across 4 domains, thin service layer pattern |
Variable | Required | Description |
| No | Pre-set a project path at startup. Leave empty — server remembers last project via state file |
| No | Base URL of a running app for live Swagger/Actuator enrichment e.g. |
Client | MCP Support | Notes |
Claude Desktop | Full — Tools, Sampling, Prompts | Recommended |
Cursor | Tools only | Works well for IDE use |
Windsurf | Tools only | |
VS Code (Copilot) | Partial / in progress | |
IntelliJ IDEA | Not supported yet | JetBrains roadmap |
ChatGPT | Not supported | Uses a different protocol |
MCP Sampling requires a client that supports the full MCP spec. Claude Desktop is currently the most complete implementation.
Parser is regex-based — handles standard Spring patterns well but may miss heavily customised or generated code
Constructor injection is detected; Lombok @RequiredArgsConstructor is not
Kotlin Spring Boot projects are not supported
Complex lambda expressions in method bodies may not trace correctly
Sampling falls back gracefully to raw data if the client does not support it
Dashboard dependency graph requires classes to be indexed with detected dependencies — heavily abstracted injection patterns may not appear
clone_and_set_project works with public repositories only — private repos
require manual cloning and set_project
Repositories over ~500MB may exceed the 2 minute clone timeout — clone
manually with git clone --depth=1 and use set_project instead
Multi-module repos should be pointed at a single submodule path rather than the repo root
spring-api-intel-mcp/
├── server.py # Entry point — ~60 lines, delegates to handlers
├── pyproject.toml # Package config and dependencies
├── core/
│ ├── __init__.py
│ ├── indexer.py # Walks .java files and builds in-memory index
│ ├── logger.py # Shared logger — writes to server.log
│ ├── sampling.py # MCP Sampling — delegates AI generation to client
│ ├── state_manager.py # Persists active project across sessions
│ └── swagger_client.py # Fetches live endpoint data from running app
├── handlers/
│ ├── __init__.py
│ ├── tool_handlers.py # All tool definitions and execution logic
│ └── prompt_handlers.py # All prompt definitions and routing logic
├── tools/
│ ├── __init__.py
│ ├── list_endpoints.py
│ ├── trace_endpoint.py
│ ├── find_usages.py
│ ├── summarize_class.py # Uses sampling for AI-generated summaries
│ ├── project_info.py # Parses pom.xml / build.gradle
│ ├── dashboard.py # Generates HTML dashboard, auto-opens in browser
│ └── git_clone.py # Clones public GitHub repos with partial clone cleanup
└── README.mdIssues and PRs welcome at github.com/mparth14/spring-api-intel-mcp.
MIT
Clear the saved project state so the server starts fresh next session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the effect without detailing what exactly is destroyed, reversibility, authentication needs, or side effects. For a destructive action, more transparency is needed.
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 conveys the purpose and effect without superfluous 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?
For a zero-parameter tool with no output schema, the description is adequate but lacks details on irreversibility or scope of the clear action. It covers the basic 'what' but not 'how' or 'implications'.
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?
There are no parameters, so the schema coverage is 100% by default. The description does not need to add parameter information, baseline is 4.
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 'clear' and the resource 'saved project state', with the purpose 'so the server starts fresh next session.' This distinguishes it from siblings that deal with project cloning, reindexing, or information retrieval.
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 is provided on when to use this tool vs alternatives like reindex or set_project. The description implies it's for resetting state, but there is no 'use this when' or 'instead of' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clone a public GitHub repository and index it as the active project. Accepts a full URL (https://github.com/owner/repo) or shorthand (owner/repo). Uses --depth=1 for speed. Re-uses existing clones automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| github_url | Yes | GitHub repo URL or owner/repo e.g. gothinkster/spring-boot-realworld-example-app |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses --depth=1 optimization and reuse of existing clones, but lacks details on error handling, permissions, or side effects on existing project state. No annotations provided, so description carries full burden.
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?
Three concise sentences, each adding unique info: purpose, input formats, optimization, reuse. No wasted 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?
Covers core operations but lacks details on error scenarios, whether it overwrites existing active project, and output expectations. No output schema, so more context needed.
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 already covers parameter with description. Description adds value by explaining full URL or shorthand format and giving an example, exceeding baseline of 3.
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?
Clear verb+resource: 'clone and index' a public GitHub repo. Distinguishes from siblings like 'set_project' and 'delete_cloned_repo' by specifying cloning and indexing as active project.
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?
Implied usage for cloning and setting a project, but no explicit when-to-use vs alternatives like 'set_project' for already cloned repos. Mentions automatic reuse, but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete all cloned repos from the temp folder to free up disk space.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions 'temp folder' but does not disclose whether the deletion is irreversible, whether confirmation is required, or any permissions needed. Minimal behavioral disclosure.
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 waste. Action and purpose are front-loaded. Every word is necessary.
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 tool with no parameters and no output schema, the description is mostly adequate. However, it lacks behavioral details like whether the operation is logged or if it requires confirmation, but these are minor given the simplicity.
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 tool has zero parameters, and schema coverage is 100%. The description is simple and does not need to add parameter details. Baseline for 0 params is 4.
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 action (delete all), the resource (cloned repos from temp folder), and the purpose (free up disk space). It distinguishes from sibling tools like 'delete_cloned_repo' (single deletion) and 'list_cloned_repos'.
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. It does not mention that 'delete_cloned_repo' exists for individual deletion or that 'list_cloned_repos' can be used to review before bulk deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific cloned repo from the temp folder to free up disk space.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_name | Yes | The repo folder name to delete e.g. spring-boot-realworld-example-app |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It only states the deletion action and disk space recovery, omitting critical details like irreversibility, error handling for missing repos, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (12 words) that is front-loaded with the key action and resource. Every word is necessary; there is no fluff.
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 tool with one parameter and no output schema, the description is minimally adequate. However, it lacks behavioral details (e.g., deletion finality) and usage conventions, leaving some contextual gaps.
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 schema description for 'repo_name' is already complete (100% coverage), including an example. The description adds no additional semantic value beyond what the schema provides, so 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 clearly states the verb 'Delete' and specific resource 'a specific cloned repo from the temp folder', distinguishing it from sibling tools like 'delete_all_cloned_repos' (which deletes all repos) and 'clone_and_set_project' (which clones).
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 explicit guidance on when to use this tool over alternatives such as 'delete_all_cloned_repos' or other disk management tools. It implies usage for freeing disk space but fails to mention contraindications or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all classes in the codebase that reference a given class name.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | The class name to search for, e.g. UserService |
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 only states what the tool does, without mentioning performance, side effects, or any constraints. The agent gains no insight into potential costs or limitations.
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 conveys the core purpose without any fluff. Every word is necessary and front-loaded.
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 simplicity of the tool (1 parameter, no output schema), the description is minimally adequate. However, it lacks details on return format, search scope (e.g., only direct references?), and any limitations, which would enhance 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% as the single parameter 'class_name' has a description in the schema. The tool description essentially repeats that the class name is used for searching, adding marginal value 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 action (find), the resource (classes in the codebase), and the input (given class name). It distinguishes from siblings like 'summarize_class' which summarizes a class rather than finding references.
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 mention when it is appropriate to use or when not to use, nor does it provide context about prerequisites or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a visual HTML architecture dashboard — layers, dependency graph, tech stack, and class overview. Opens in any browser.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it generates an HTML file and opens it in a browser, indicating a create-and-display behavior. Without annotations, this provides reasonable transparency, though it does not mention whether the output persists or is temporary.
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?
Two concise sentences that front-load the purpose and output format. Every word adds value.
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 tool with no parameters, no annotations, and no output schema, the description adequately explains what it does and how to access the result. A minor improvement could clarify if the HTML is saved to a file, but the current description is sufficient.
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?
There are no parameters, so the schema coverage is 100% (empty). The description adds no parameter information, which is appropriate since none exist. Baseline 4 applies.
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 explicitly states the tool generates a visual HTML architecture dashboard with specific components (layers, dependency graph, tech stack, class overview) and opens in browser. This clearly distinguishes it from sibling tools which deal with project state, cloning, searching, etc.
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 vs alternatives, but the tool's purpose is self-explanatory given its distinct function compared to siblings. A score of 3 reflects the lack of explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract project metadata from pom.xml or build.gradle — Java version, Spring Boot version, build tool, and all dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions extracting metadata, implying read-only operation, but does not specify side effects, error handling (e.g., missing build file), or required permissions. This is insufficient for safe agent invocation.
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 sentence that is direct and efficient. Every word contributes meaning, with no redundancy.
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 no parameters and no output schema, the description should explain the return structure or behavior in edge cases. It lists extracted items but does not mention format, what happens if build files are absent, or how the tool interacts with other project state (e.g., current project). Medium 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?
The input schema has zero parameters (100% coverage trivially), so the description adds value by specifying what the tool does without needing parameters. The description compensates for the lack of schema detail by naming the extracted fields.
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's purpose: extracting project metadata from pom.xml or build.gradle, including specific items like Java version, Spring Boot version, build tool, and dependencies. It uses a specific verb (Extract) and resource (project metadata), distinguishing it from sibling tools.
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 the tool is for retrieving project metadata but does not explicitly state when to use it versus alternatives like find_usages or summarize_class. No guidance on prerequisites (e.g., project must be cloned) or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all GitHub repos currently cached in the temp folder with their disk usage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It accurately describes the read-only listing behavior, but does not explicitly state that it is safe or side-effect-free, which is expected for a simple list operation.
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, no wasted words. Perfectly concise while conveying all necessary 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?
For a parameterless list tool with no output schema, the description is complete. It explains what the tool does and what information it provides, which is sufficient for an agent to decide to use it.
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 tool has no parameters, and schema coverage is 100%. According to the rubric, 0 parameters baseline is 4. The description does not need to add parameter information.
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 'list', the resource 'GitHub repos cached in temp folder', and the output 'disk usage'. It effectively distinguishes from sibling tools like clone_and_set_project or delete_cloned_repos.
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 only explains what it does without providing context for when it's appropriate or how it relates to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all REST endpoints in the Spring Boot project. Enriches with live Swagger/Actuator data if the app is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the enrichment behavior based on runtime state but doesn't detail return format or whether it's read-only.
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?
Two sentences, no wasted words, front-loaded with core action. Every sentence adds value.
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 adequately covers what the tool does and a key behavioral trait. Could mention the output format, but sufficient for a simple list tool.
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 tool has no parameters, so the description needs only to explain the overall function. The baseline for zero parameters is 4, and the description adds no parameter-specific info.
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 lists REST endpoints in a Spring Boot project and enriches with live data, which is a specific verb+resource. This distinguishes it from sibling tools like trace_endpoint.
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 does not explicitly state when to use this tool versus alternatives, though the purpose is implied. No guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-scan the project directory to pick up new or changed files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action but does not explain side effects, whether it is read-only or mutating, permissions needed, or what happens to internal state. This leaves the agent uncertain about potential impacts.
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 efficiently conveys the tool's purpose. It is front-loaded and contains no unnecessary 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?
While the tool is simple, the description lacks details about return values, prerequisites (e.g., project must be set), or error conditions. No output schema is provided, so the description should hint at what the agent can expect after execution.
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 has zero parameters, so schema coverage is 100%. The description does not need to add parameter information. The baseline score of 4 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 'Re-scans the project directory to pick up new or changed files', which is a specific verb and resource with a clear goal. It distinguishes itself from sibling tools like 'set_project' or 'get_project_info' which have different purposes.
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, such as requiring a project to be set, or situations where reindexing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch the active Spring Boot project by providing a directory path. Use this to point the server at a different codebase.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the Spring Boot project root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It only states the action but omits details like whether the switch triggers reindexing, if unsaved state is lost, or if it requires restart. This 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero wasted words. Front-loaded with the core action, followed by a clear usage statement.
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 a single parameter, no output schema, and sibling tools providing context, the description is mostly complete. However, missing details about post-switch behavior slightly reduce 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 coverage is 100% (parameter 'path' described as 'Absolute path to the Spring Boot project root'). The description reinforces that the path is a directory, but adds little beyond the schema. 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 the tool's action ('Switch the active Spring Boot project') and resource ('by providing a directory path'), distinguishing it from sibling tools like clone_and_set_project or delete_cloned_repo.
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. For example, it doesn't explain when to use set_project vs clone_and_set_project, or mention prerequisites like ensuring the path is valid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a structured summary of a Java class including its annotations, dependencies, and methods.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | The Java class name, e.g. OrderService |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It correctly indicates a read operation returning a summary, but omits details like whether a project must be set, error handling, or limitations. The description is minimally adequate but lacks depth.
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-formed sentence with no extraneous words. However, it could be slightly more informative without losing conciseness, e.g., by noting if a project must be set.
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's simplicity (one parameter, no output schema), the description partially explains what the summary includes. However, it does not clarify return format, error scenarios, or project dependencies, making it moderately complete for its complexity.
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 a clear parameter description. The tool's description adds context about the summary contents, but the schema already specifies 'class_name' as a Java class name. The description does not enhance parameter meaning 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's purpose: retrieving a structured summary of a Java class, explicitly listing included aspects (annotations, dependencies, methods). This specificity distinguishes it from sibling tools like 'find_usages' or 'trace_endpoint', which focus on different aspects.
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, nor does it mention prerequisites or exclusions. Sibling tools exist but no comparative context is given, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace the full call chain for an endpoint path. Shows controller → service → repository.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The endpoint path to trace, e.g. /api/orders |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only analysis behavior and output structure (controller → service → repository), but does not mention dependencies like current project state or potential performance impact. Slight gap but generally transparent.
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?
Two sentences, zero wasted words. Front-loaded with the action verb 'Trace' and immediately explains output. Ideal length for a simple 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?
For a single-parameter tool with no output schema, the description covers the core functionality. It lacks mention of context (e.g., which project or repository the trace applies to) but is otherwise complete for basic 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?
Schema coverage is 100% with a good example for 'path'. The description reinforces the parameter's purpose but adds little beyond the schema's own description. 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 the tool's purpose: tracing the full call chain for an endpoint path, showing controller, service, repository. This verb+resource combination distinguishes it from sibling tools like list_endpoints or find_usages.
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 vs alternatives. While the purpose implies it's for detailed tracing, it does not mention when it's appropriate over list_endpoints or any prerequisites (e.g., project must be set).
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.0.0clear_saved_stateclone_and_set_projectdelete_all_cloned_reposdelete_cloned_repofind_usagesgenerate_dashboardget_project_infolist_cloned_reposlist_endpointsreindexset_projectsummarize_classtrace_endpointEach tool has a clearly distinct purpose with no overlap. For example, clone_and_set_project and set_project differ in operation (clone vs just set), delete_all_cloned_repos vs delete_cloned_repo differ in scope. All other tools target unique actions.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., clear_saved_state, clone_and_set_project, list_endpoints, trace_endpoint). No mixing of styles or vague verbs.
13 tools is well-scoped for a Spring Boot analysis server. It covers project setup, information retrieval, endpoint analysis, code search, and maintenance without being bloated.
Core workflows are covered: project selection, metadata extraction, endpoint tracing, class summaries, usage search, and dashboard generation. A minor gap is the lack of a tool listing all classes or packages, though the dashboard may compensate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mparth14/spring-api-intel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
