Skip to main content
Glama
vic3custodio

Trade Surveillance Support MCP Server

by vic3custodio

search_java_code

Search Java code by metadata keywords in javadoc comments to find relevant classes for trade surveillance workflows, enabling targeted discovery without file paths.

Instructions

Search for Java classes using metadata keywords instead of file paths.

This tool searches through indexed Java files by their javadoc metadata annotations.
Java classes should include metadata in javadoc comments like:

/**
 * @keywords trade, settlement, report_generator
 * @type report_engine
 * @description Generates daily settlement reports
 */

Args:
    search_keywords: Keywords to search for (e.g., "report generator", "trade processor")
    code_directory: Path to the directory containing Java source files (used for initial scan)
    
Returns:
    A dictionary containing matching Java files with their metadata and methods

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
search_keywordsYes
code_directoryNo./src

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The decorated handler function implementing the 'search_java_code' MCP tool. Includes registration via @mcp.tool(), type-hinted parameters serving as input schema, comprehensive docstring describing usage, and core logic that scans Java directories for metadata-annotated files if needed and searches the index for keyword matches.
    @mcp.tool()
    async def search_java_code(
        search_keywords: str,
        code_directory: str = "./src"
    ) -> dict[str, Any]:
        """
        Search for Java classes using metadata keywords instead of file paths.
        
        This tool searches through indexed Java files by their javadoc metadata annotations.
        Java classes should include metadata in javadoc comments like:
        
        /**
         * @keywords trade, settlement, report_generator
         * @type report_engine
         * @description Generates daily settlement reports
         */
        
        Args:
            search_keywords: Keywords to search for (e.g., "report generator", "trade processor")
            code_directory: Path to the directory containing Java source files (used for initial scan)
            
        Returns:
            A dictionary containing matching Java files with their metadata and methods
        """
        logger.info(f"Searching Java code for keywords: {search_keywords}")
        
        # Scan directory if index is empty
        if not metadata_index.index.get("java_classes"):
            logger.info(f"Scanning Java classes in: {code_directory}")
            metadata_index.scan_java_classes(code_directory)
        
        # Search by keywords
        matches = metadata_index.search(search_keywords, file_type="java")
        
        result = {
            "status": "success",
            "search_keywords": search_keywords,
            "matches_found": len(matches),
            "java_classes": matches
        }
        
        logger.info(f"Found {len(matches)} Java class matches")
        return result
  • Core search method of MetadataIndex class, called by search_java_code handler with file_type='java'. Matches query keywords against extracted metadata (keywords, type, description, filename) in indexed Java classes.
    def search(self, query: str, file_type: str = "all") -> list[dict[str, Any]]:
        """
        Search the index by keywords, type, or description.
        
        Args:
            query: Search terms (space or comma separated)
            file_type: "sql", "java", or "all"
        
        Returns:
            List of matching files with their metadata
        """
        query_terms = [term.strip().lower() for term in re.split(r'[,\s]+', query)]
        results = []
        
        # Search SQL configs
        if file_type in ("sql", "all"):
            for file_name, metadata in self.index.get("sql_configs", {}).items():
                if self._matches_query(metadata, query_terms):
                    results.append({
                        "type": "sql_config",
                        "file": file_name,
                        **metadata
                    })
        
        # Search Java classes
        if file_type in ("java", "all"):
            for file_name, metadata in self.index.get("java_classes", {}).items():
                if self._matches_query(metadata, query_terms):
                    results.append({
                        "type": "java_class",
                        "file": file_name,
                        **metadata
                    })
        
        return results
  • Scanning method called by search_java_code to index Java source files if not already done. Discovers *.java files, extracts metadata from Javadoc comments using _extract_java_metadata, lists public methods, and persists the index to JSON.
    def scan_java_classes(self, code_dir: str) -> dict[str, Any]:
        """
        Scan Java files and extract metadata from javadoc comments.
        
        Looks for annotations like:
        /**
         * @keywords trade, settlement, report_generator
         * @type report_engine
         * @description Generates daily settlement reports
         */
        """
        code_path = Path(code_dir)
        if not code_path.exists():
            return {}
        
        classes = {}
        for java_file in code_path.rglob("*.java"):
            metadata = self._extract_java_metadata(java_file)
            if metadata:
                classes[str(java_file.relative_to(code_path))] = metadata
        
        self.index["java_classes"] = classes
        self._save_index()
        return classes
  • Private helper extracts key metadata from individual Java files: @keywords, @type, @description from Javadoc, plus public method names via regex. Only indexes files with keywords or type.
    def _extract_java_metadata(self, file_path: Path) -> dict[str, Any]:
        """Extract metadata from Java file javadoc comments."""
        metadata = {
            "file_path": str(file_path),
            "file_name": file_path.name,
            "class_name": file_path.stem,
            "keywords": [],
            "type": None,
            "description": None,
            "methods": []
        }
        
        try:
            with open(file_path, 'r') as f:
                content = f.read()
            
            # Extract @keywords
            keywords_match = re.search(r'\*\s*@keywords[:\s]+([^\n]+)', content, re.IGNORECASE)
            if keywords_match:
                keywords = [k.strip() for k in keywords_match.group(1).split(',')]
                metadata["keywords"] = keywords
            
            # Extract @type
            type_match = re.search(r'\*\s*@type[:\s]+([^\n]+)', content, re.IGNORECASE)
            if type_match:
                metadata["type"] = type_match.group(1).strip()
            
            # Extract @description
            desc_match = re.search(r'\*\s*@description[:\s]+([^\n]+)', content, re.IGNORECASE)
            if desc_match:
                metadata["description"] = desc_match.group(1).strip()
            
            # Extract public methods
            method_pattern = r'public\s+(?:static\s+)?[\w<>\[\]]+\s+(\w+)\s*\('
            methods = re.findall(method_pattern, content)
            metadata["methods"] = methods
            
            return metadata if metadata["keywords"] or metadata["type"] else None
        except Exception:
            return None
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool searches 'indexed Java files' and uses 'javadoc metadata annotations', adding context about the search mechanism. However, it lacks details on behavioral traits such as performance (e.g., speed, limitations), error handling, or prerequisites (e.g., need for pre-indexed files), leaving gaps in transparency.

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

Conciseness5/5

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

The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by explanatory details and a structured format with 'Args' and 'Returns' sections. Every sentence adds value, such as the javadoc example and parameter explanations, with no redundant information.

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

Completeness4/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 mostly complete. It covers purpose, usage context, parameter semantics, and return value overview. The output schema exists, so detailed return explanations are not needed, but it could improve by addressing behavioral aspects like indexing requirements or error cases.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'search_keywords' with examples (e.g., 'report generator') and clarifies that 'code_directory' is 'used for initial scan', providing context beyond the schema's basic titles. However, it does not detail parameter constraints or formats (e.g., keyword syntax, directory validity), partially compensating for the low coverage.

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

Purpose5/5

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

The description clearly states the specific action ('search for Java classes') and the unique mechanism ('using metadata keywords instead of file paths'), distinguishing it from potential file-based search tools. It explicitly mentions the resource (Java classes) and the method (javadoc metadata annotations), making the purpose unambiguous and distinct from siblings like 'search_sql_configs'.

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

Usage Guidelines4/5

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

The description provides clear context on when to use this tool: for searching Java classes via metadata keywords rather than file paths. It implies usage for indexed Java files with javadoc metadata, but does not explicitly state when not to use it or name alternatives among siblings like 'rebuild_metadata_index' for indexing tasks.

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/vic3custodio/mcp_test_2'

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