Skip to content

Conversation

rahul-madaan
Copy link
Contributor

🔧 Rename MCP Tools to Follow Clean Naming Convention

Resolved #75

Summary

Renamed MCP tool functions from *_tool suffix to clean <action>_<type> format to improve API consistency and remove redundant naming.

Changes Made

Tool Renames:

  • search_assets_toolsearch_assets
  • get_assets_by_dsl_toolget_assets_by_dsl
  • traverse_lineage_tooltraverse_lineage
  • update_assets_toolupdate_assets

Implementation Improvements:

  • Added clean top-level imports with _impl suffix to avoid naming conflicts
  • Removed messy local imports before return statements
  • Updated all docstring examples to use new tool names

Documentation Updates:

  • Updated README.md tool restriction examples and available tools list
  • Updated .cursor/rules/project-structure.mdc architecture documentation
  • Fixed all configuration examples to use new tool names

Testing

✅ All 7 tools properly registered and functional
✅ No old tool names remaining
✅ Server imports and starts successfully
✅ No linting errors

Breaking Change

⚠️ Client code using old tool names will need to update to new names

Migration:

- search_assets_tool(...)
+ search_assets(...)

Comment on lines 11 to 15
from tools.glossary import (
create_glossary_category_assets as create_glossary_category_assets_impl,
create_glossary_assets as create_glossary_assets_impl,
create_glossary_term_assets as create_glossary_term_assets_impl,
)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we importing the tools separately? can we follow the previous import style.

Copy link
Contributor Author

@rahul-madaan rahul-madaan Sep 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because we have to import it as implementation function.

we could change the names of functions directly in modules to avoid importing like this.
but as a standard in python we prefer Import Aliasing

Why current approach is better:

  • Preserves Original API: The implementation functions keep their intended names
  • Context-Specific Naming: The alias reflects the usage context, not the implementation
  • Less Invasive: Doesn't require changing the actual function definitions
  • Flexibility: Different modules can import with different aliases as needed
  • Clear Intent: Shows that the renaming is for disambiguation, not because the function is "internal"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no no, i meant why not

from tools import (
search_assets as search, 
get_assets_by_dsl as fetch_assets_by_dsl,
...
)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup that will be cleaner, I will make that change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

create_glossary_term_assets as create_glossary_term_assets_impl,
)
from tools.search import search_assets as search_assets_impl
from tools.dsl import get_assets_by_dsl as get_assets_by_dsl_impl
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_impl doesn't sound nice. lets improve the code readability here please.

Copy link
Contributor Author

@rahul-madaan rahul-madaan Sep 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Python, _impl is a naming convention

When you see _impl in a Python codebase, it often signifies that the associated code (e.g., a function, class, or module) is an internal implementation detail and is not intended for direct public use.

we need to do this in order to not have naming conflicts of tool names with implementation functions in respective modules.

This approach is widely used in professional Python codebases

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_impl is a java convention and not python, please check

Comment on lines 39 to 47
from tools.glossary import (
create_glossary_category_assets as create_glossary_category_assets_impl,
create_glossary_assets as create_glossary_assets_impl,
create_glossary_term_assets as create_glossary_term_assets_impl,
)
from tools.search import search_assets as search_assets_impl
from tools.dsl import get_assets_by_dsl as get_assets_by_dsl_impl
from tools.lineage import traverse_lineage as traverse_lineage_impl
from tools.assets import update_assets as update_assets_impl
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

responded there.

@rahul-madaan rahul-madaan mentioned this pull request Sep 5, 2025
@rahul-madaan rahul-madaan requested a review from Hk669 September 5, 2025 11:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEATURE] Add standardisation to tool naming
3 participants