Skip to main content
Glama
jonmmease

jons-mcp-java

by jonmmease

workspace_symbols

Search for Java symbols in your workspace using Eclipse JDT.LS to quickly locate classes, methods, and other identifiers across projects.

Instructions

Search for symbols in the workspace.

Args: query: Search query string (symbol name or pattern) file_path: Optional file path to determine which project to search

Returns: Dictionary with 'symbols' array or 'status'/'message' if initializing

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
file_pathNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function for the 'workspace_symbols' MCP tool. Decorated with @mcp.tool(), it sends an LSP 'workspace/symbol' request to search for symbols matching the query, formats the results, and handles initialization states.
    @mcp.tool()
    async def workspace_symbols(
        query: str,
        file_path: str | None = None,
    ) -> dict:
        """
        Search for symbols in the workspace.
    
        Args:
            query: Search query string (symbol name or pattern)
            file_path: Optional file path to determine which project to search
    
        Returns:
            Dictionary with 'symbols' array or 'status'/'message' if initializing
        """
        manager = get_manager()
        if manager is None:
            return {"status": "error", "message": "Server not initialized"}
    
        # If file_path provided, use that project; otherwise use first available
        if file_path:
            client, status = await manager.get_client_for_file_with_status(Path(file_path))
        else:
            # Get any initialized client
            for project in manager._projects.values():
                if project.client and project.client.is_initialized:
                    client = project.client
                    status = "ready"
                    break
            else:
                return {
                    "status": "error",
                    "message": "No initialized projects. Provide a file_path to start initialization."
                }
    
        if client is None:
            return {"status": "initializing", "message": status}
    
        response = await client.request(
            LSP_WORKSPACE_SYMBOL,
            {
                "query": query,
            }
        )
    
        if response is None:
            return {"symbols": []}
    
        # Response is SymbolInformation[]
        symbols = [format_symbol(sym) for sym in response]
        return {"symbols": symbols}
  • Import of the 'symbols' module in the FastMCP server setup, which triggers automatic registration of the @mcp.tool()-decorated 'workspace_symbols' function.
    # Import tools to register them
    from jons_mcp_java.tools import navigation, symbols, diagnostics, info  # noqa: E402, F401
  • Utility function to normalize and format LSP symbol information from workspace/symbol response into a consistent structure, recursively handling children for DocumentSymbol.
    def format_symbol(symbol: dict, include_children: bool = True) -> dict:
        """Format a DocumentSymbol or SymbolInformation to a common format."""
        # DocumentSymbol has range, SymbolInformation has location
        if "location" in symbol:
            # SymbolInformation
            loc = symbol["location"]
            uri = loc.get("uri", "")
            range_obj = loc.get("range", {})
            try:
                path = str(uri_to_path(uri))
            except ValueError:
                path = uri
        else:
            # DocumentSymbol (no path, just range within current file)
            path = None
            range_obj = symbol.get("range", {})
    
        start = range_obj.get("start", {})
    
        result = {
            "name": symbol.get("name", ""),
            "kind": symbol.get("kind", 0),
            "kind_name": SYMBOL_KINDS.get(symbol.get("kind", 0), "Unknown"),
            "line": start.get("line", 0),
            "character": start.get("character", 0),
        }
    
        if path:
            result["path"] = path
    
        # Include container name if present (SymbolInformation)
        if "containerName" in symbol:
            result["container"] = symbol["containerName"]
    
        # Include children if present (DocumentSymbol hierarchy)
        if include_children and "children" in symbol:
            result["children"] = [
                format_symbol(child, include_children=True)
                for child in symbol["children"]
            ]
    
        return result
  • LSP constant for the 'workspace/symbol' method invoked by the tool handler.
    LSP_WORKSPACE_SYMBOL = "workspace/symbol"
Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions that returns include a 'status'/'message' if initializing, hinting at potential initialization states, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or whether this is a read-only operation. The description doesn't contradict annotations (none exist), but fails to adequately disclose behavioral traits.

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

Conciseness4/5

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

The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args/Returns sections are structured but slightly verbose; every sentence adds value, though the return description could be more concise. No wasted text, but minor room for tightening.

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

Completeness3/5

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

Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is partially complete. It covers purpose and parameters adequately, and the output schema handles return values, but it lacks context on usage scenarios, error conditions, or integration with sibling tools. For a search tool with workspace scope, more guidance would be helpful.

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

Parameters4/5

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

The description adds meaningful semantics beyond the schema: it explains that 'query' is for 'symbol name or pattern' and 'file_path' helps 'determine which project to search'. With 0% schema description coverage, this compensates well by clarifying parameter purposes, though it doesn't detail format constraints (e.g., query syntax or file path patterns).

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

Purpose4/5

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

The description clearly states the tool's purpose as 'Search for symbols in the workspace' with a specific verb ('Search') and resource ('symbols in the workspace'). It distinguishes from sibling tools like 'document_symbols' (which likely searches within a single document) by specifying workspace scope, though it doesn't explicitly contrast with all siblings like 'definition' or 'references'.

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

Usage Guidelines3/5

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

The description implies usage through the parameter descriptions: 'query' for searching symbol names/patterns and 'file_path' to determine which project to search. However, it lacks explicit guidance on when to use this tool versus alternatives like 'document_symbols' or 'definition', and doesn't mention prerequisites or exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jonmmease/jons-mcp-java'

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