Added a note in the MCP doc for directly referencing a MCP tool within a client

[AnuradhaKaruppiah]

Description

Closes

By Submitting this PR I confirm:

• I am familiar with the Contributing Guidelines.
• We require that all contributors "sign-off" on their commits. This certifies that the contribution is your original work, or you have rights to submit it under the same license, or a compatible license.
  • Any contribution which contains commits that are not Signed-Off will not be accepted.
• When the PR is ready for review, new or existing tests cover these changes.
• When the PR is ready for review, the documentation is up to date with these changes.

Summary by CodeRabbit

• Documentation
  • Added guidance on referencing a tool inside a function group via dot-notation (function_group.tool_name), noting the tool must be listed in the group’s optional include list.
  • Linked to function accessibility details and added a YAML example demonstrating usage for building custom sub-tools that leverage an MCP server tool.

[coderabbitai]

Walkthrough

Adds documentation explaining that a tool inside a function group can be referenced by full name using <function_group_name>.<tool_name>, requires the tool be listed in the function group's optional include list, and includes a YAML example and link to function accessibility details.

Changes

Cohort / File(s)	Change Summary
MCP Client Documentation docs/source/workflows/mcp/mcp-client.md	Added explanation of dot-notation tool referencing within function groups (<function_group>.<tool>), noted the tool must appear in the group's optional include list, added link to function accessibility docs, and included a YAML example (tool_names: [mcp_tools.tool_a]).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Pre-merge checks and finishing touches

Important

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

❌ Failed checks (1 error)

Check name	Status	Explanation	Resolution
Title Check	❌ Error	The pull request title "Added a note in the MCP doc for directly referencing a MCP tool within a client" is clearly related to the actual changeset, which adds documentation about directly referencing MCP tools within a client. However, the title does not fully meet the specified requirements: it uses past tense "Added" instead of imperative mood, and at 79 characters, it exceeds the recommended maximum of approximately 72 characters by about 7 characters. The title would need to be rewritten in imperative mood (e.g., "Add a note...") and shortened to comply with the formatting requirements.	Update the title to use imperative mood and reduce it to approximately 72 characters or fewer. A suggested revision would be: "Add note to MCP doc for directly referencing tools in client" (63 characters), which maintains the core message while meeting both the mood and length requirements.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c2175bf and ba76bc9.

📒 Files selected for processing (1)

• docs/source/workflows/mcp/mcp-client.md (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• docs/source/workflows/mcp/mcp-client.md

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[willkill07]

As written, a user may naively assume they can always do this, which is not true.

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e37307d and 98d3231.

📒 Files selected for processing (1)

• docs/source/workflows/mcp/mcp-client.md (1 hunks)

🧰 Additional context used

📓 Path-based instructions (3)

docs/source/**/*.md

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

docs/source/**/*.md: Use the official naming throughout documentation: first use “NVIDIA NeMo Agent toolkit”, subsequent “NeMo Agent toolkit”; never use deprecated names (Agent Intelligence toolkit, aiqtoolkit, AgentIQ, AIQ/aiq)
Documentation sources are Markdown files under docs/source; images belong in docs/source/_static
Keep docs in sync with code; documentation pipeline must pass Sphinx and link checks; avoid TODOs/FIXMEs/placeholders; avoid offensive/outdated terms; ensure spelling correctness
Do not use words listed in ci/vale/styles/config/vocabularies/nat/reject.txt; accepted terms in accept.txt are allowed

Files:

• docs/source/workflows/mcp/mcp-client.md

**/*

⚙️ CodeRabbit configuration file

**/*: # Code Review Instructions

• Ensure the code follows best practices and coding standards. - For Python code, follow
  PEP 20 and
  PEP 8 for style guidelines.
• Check for security vulnerabilities and potential issues. - Python methods should use type hints for all parameters and return values.
  Example:

  def my_function(param1: int, param2: str) -> bool:
      pass

• For Python exception handling, ensure proper stack trace preservation:
  • When re-raising exceptions: use bare raise statements to maintain the original stack trace,
    and use logger.error() (not logger.exception()) to avoid duplicate stack trace output.
  • When catching and logging exceptions without re-raising: always use logger.exception()
    to capture the full stack trace information.

Documentation Review Instructions - Verify that documentation and comments are clear and comprehensive. - Verify that the documentation doesn't contain any TODOs, FIXMEs or placeholder text like "lorem ipsum". - Verify that the documentation doesn't contain any offensive or outdated terms. - Verify that documentation and comments are free of spelling mistakes, ensure the documentation doesn't contain any

words listed in the ci/vale/styles/config/vocabularies/nat/reject.txt file, words that might appear to be
spelling mistakes but are listed in the ci/vale/styles/config/vocabularies/nat/accept.txt file are OK.

Misc. - All code (except .mdc files that contain Cursor rules) should be licensed under the Apache License 2.0,

and should contain an Apache License 2.0 header comment at the top of each file.

• Confirm that copyright years are up-to date whenever a file is changed.

Files:

• docs/source/workflows/mcp/mcp-client.md

docs/source/**/*

⚙️ CodeRabbit configuration file

This directory contains the source code for the documentation. All documentation should be written in Markdown format. Any image files should be placed in the docs/source/_static directory.

Files:

• docs/source/workflows/mcp/mcp-client.md

🪛 LanguageTool

docs/source/workflows/mcp/mcp-client.md

[grammar] ~75-~75: Ensure spelling is correct
Context: ...-function-accessibility](Function Group Accessiblity] for more details. ::: Example: ```yaml ...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

[AnuradhaKaruppiah]

Thanks for the review @willkill07

[AnuradhaKaruppiah]

/merge