Skip to main content
Glama
pzalutski-pixel

javalens-mcp

by pzalutski-pixel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

get_di_registrations

Scan a Java project for Spring dependency injection registrations, including components, configurations, beans, and injection points. Requires load_project first.

Instructions

Find all dependency injection registrations in the project.

USAGE: get_di_registrations() OUTPUT: Components, configurations, beans, and injection points

Scans for:

  • Spring components: @Component, @Service, @Repository, @Controller, @RestController

  • Configuration: @Configuration

  • Bean definitions: @Bean

  • Injection points: @Autowired, @Inject (javax and jakarta)

Returns empty categories for non-Spring projects (does not error).

maxResults caps the matches listed for each annotation type (default 200). Each summary count is the exact number of registrations in its category; meta.totalCount counts every registration, meta.returnedCount those listed, and meta.truncated is true when an annotation type has more matches than maxResults. potentialMatches lists, the first maxResults of each annotation type, the annotations JDT could not confirm, each with the annotation it names; none is a registration.

potentialMatches, present only when there are any, holds the places JDT's search reports as possible matches but cannot confirm, because a type or name there does not resolve (a missing dependency or a compile error): count is their exact number, and locations lists them, as many as the results it stands beside may list. They are never counted or listed as results.

Requires load_project to be called first.

Input Schema

NameRequiredDescriptionDefault
maxResultsNoMaximum results per annotation type (default 200)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.4
  2. Removedv1.3.3
  3. First observedv1.2.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses that non-Spring projects return empty categories rather than erroring, explains the maxResults cap and its interaction with meta.totalCount/returnedCount/truncated, and carefully defines potentialMatches as unconfirmed, never-counted results. That is exactly the kind of behavioral context annotations would otherwise have to supply.

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

Conciseness3/5

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

Front-loading is good (purpose, then USAGE/OUTPUT, then semantics), but the potentialMatches passage is verbose and grammatically tangled ('as many as the results it stands beside may list'), requiring re-reading. The meta/potentialMatches detail is repeated and could be tightened substantially.

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

Completeness5/5

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

No output schema and no annotations, yet the description fully specifies the return shape (categories, meta counters, potentialMatches), the prerequisite, and edge-case behavior. An agent has everything needed to invoke and interpret the result correctly.

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

Parameters3/5

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

Schema coverage is 100% and the single parameter's description ('Maximum results per annotation type (default 200)') is essentially duplicated in the prose. The description adds only marginal nuance about per-type truncation, which the schema text already conveys. Baseline 3 is correct.

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?

States a specific verb and resource ('Find all dependency injection registrations') and then enumerates exactly what it scans for (Spring components, @Configuration, @Bean, @Autowired/@Inject). An agent can distinguish this from generic siblings like find_annotation_usages or get_dependency_graph without opening the schema.

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?

Gives a clear prerequisite ('Requires load_project to be called first') and an explicit USAGE signature. However, it never names an alternative tool or states when NOT to use it (e.g., versus find_annotation_usages for a single annotation), so guidance stops short of the 5-level routing clarity.

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

Deploy Server

Other Tools