Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

MCP trace still uses light-class names for external calls and node className

Open Beginner friendly
#591 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
85/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
kotlin
Domain
tooling

Research direction

Open CallChainTracer.kt near line 185 and SpringMcpProvider.kt near line 1553. Replace direct light-class name usage with SourceNames.qualifiedNameOf or SourceNames.shortNameOf for external call targets and trace-node className. Verify that non-companion member trace output remains unchanged by running the relevant tests.

Written by the indexing model from the issue text.

Description

spring-mcp-tools

Component

MCP tools

Problem

On current public/main, CallChainTracer.kt:185 builds external-call targets directly from the light-class and JVM method names:

TracedCall("${receiverClass.name}.${callee.name}", ...)

For an external Kotlin class, this can expose JVM/light-class names such as Companion or $module instead of the source declaration name.

Also, SpringMcpProvider.kt:1553 builds trace-node className from the light class:

className = containingClass?.qualifiedName ?: containingClass?.name

Consequently, a companion member can still expose a class name containing ...Companion, even though PR #585 fixed the node methodName and call target/name paths that use SourceNames.

This is a code-reading finding, not a reproduced runtime run.

Expected

Trace external-call targets and trace-node className should use source-level names. Route both through SourceNames (qualifiedNameOf / shortNameOf) while keeping the trace output of non-companion members byte-identical.

Related

#571, #585, #568

Dominant language
Kotlin
Stars
163
Forks
16
Avg merge
7h 4m
Merged PRs (30d)
122

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from explyt/spring-plugin

All issues in explyt/spring-plugin

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.