-
Notifications
You must be signed in to change notification settings - Fork 14
updated tool naming as per suggestion #125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
modelcontextprotocol/server.py
Outdated
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, | ||
) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
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,
...
)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
modelcontextprotocol/server.py
Outdated
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
responded there.
🔧 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_tool
→search_assets
get_assets_by_dsl_tool
→get_assets_by_dsl
traverse_lineage_tool
→traverse_lineage
update_assets_tool
→update_assets
Implementation Improvements:
_impl
suffix to avoid naming conflictsDocumentation Updates:
README.md
tool restriction examples and available tools list.cursor/rules/project-structure.mdc
architecture documentationTesting
✅ All 7 tools properly registered and functional
✅ No old tool names remaining
✅ Server imports and starts successfully
✅ No linting errors
Breaking Change
Migration: