find_functions_by_argument matches Parameter.name, not type — Parameter nodes have no type property #1685

Summary

find_functions_by_argument (and the analyze_code_relationships / MCP tool built on the same underlying query) is documented/expected to let a caller find functions that take a given argument type — but the implementation matches Parameter.name (the identifier), and Parameter nodes never get a type property populated at all. Searching by a type name silently returns 0 results even when the type is used throughout the indexed codebase, with no error or warning.

Environment

• CodeGraphContext MCP server, backend Neo4j
• Indexed repo: a large multi-module Java/Spring codebase (~1,890 files)
• Reproduced via both the MCP tool call and a direct read of tools/code_finder.py on main

Reproduction

Given a Java function:

default Page<Order> findAll(OrderFilter filter, Pageable pageable) { ... }

Querying for functions taking OrderFilter as an argument:

find_functions_by_argument("OrderFilter")
# -> 0 results

But the type is clearly indexed and used — confirmed via direct Cypher against Function.arg_types, which correctly lists ["OrderFilter", "Pageable"] for this exact function, and via find_callers/find_all_callers, which correctly return this function's real callers.

Root cause

code_finder.py, find_functions_by_argument:

query = f"""
    MATCH (f:Function)-[:HAS_PARAMETER]->(p:Parameter)
    WHERE p.name = $argument_name {repo_filter}
    RETURN f.name AS function_name, f.path AS path, f.line_number AS line_number,
           f.docstring AS docstring, f.is_dependency AS is_dependency
    ...
"""

This matches Parameter.name — the parameter's identifier (e.g. filter, orderFilter, criteria) — not its type. Inspecting Parameter node properties directly:

MATCH (f:Function)-[:HAS_PARAMETER]->(p:Parameter) WHERE f.name = 'findAll' RETURN properties(p) LIMIT 5

returns only {path, name, function_line_number} — no type property exists on Parameter nodes at all, at least for the Java parser. The actual type information is stored only on the parent Function node's arg_types array (e.g. ["OrderFilter", "Int", "Int", "Sort.Direction", "String"]), which find_functions_by_argument never consults.

The tool name and its description ("Find functions that take a specific argument name") could be read either way, but for any typed language the useful/expected query is almost always "what functions take an argument of type X" — and there is currently no tool that can answer that at all, since Parameter.type doesn't exist and find_functions_by_argument only ever searches names.

Impact

For typed languages (confirmed on Java; likely affects any parser that populates arg_types on Function but not type on Parameter), this makes find_functions_by_argument unusable for its most obvious use case — finding every consumer of a shared DTO/filter/request type across a codebase, which is a common and valuable blast-radius query (e.g. "what else uses this filter class before I change its validation").

Suggested fix

One of:

1. Populate a type property on Parameter nodes at index time (from the same type info already captured into arg_types), and have find_functions_by_argument match against either name or type (or add a separate find_functions_by_argument_type tool).
2. At minimum, rewrite find_functions_by_argument's Cypher to also check membership against the parent Function.arg_types array, so a type-name query returns correct results without requiring a schema change.
3. Document clearly (tool description + MCP schema) that this tool searches parameter names only, so callers don't silently get 0 results expecting a type search — this is the more surprising failure mode since it looks like a normal empty-result rather than an error.

Workaround

Direct Cypher against the correctly-populated Function.arg_types property works reliably:

MATCH (f:Function) WHERE any(t IN f.arg_types WHERE t CONTAINS 'OrderFilter')
RETURN f.qualified_name, f.path, f.line_number, f.arg_types