get_mutual_fund_navGet the latest NAV of an Indian mutual fund by AMFI scheme code.
Args:
amfi_scheme_code: AMFI scheme code (e.g. '119598' for SBI Bluechip Direct).
Find codes at mfapi.in or amfiindia.com.
Returns:
Scheme name, latest NAV, NAV date, fund house, scheme type.
| Name | Required | Description | Default |
|---|---|---|---|
| amfi_scheme_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it readOnlyHint=true and destructiveHint=false, so no safety contradiction exists. The description adds behavioral value by listing the return fields (scheme name, latest NAV, NAV date, fund house, scheme type) and clarifying that the input is an AMFI scheme code. It does not cover failure modes, but for a simple read-only tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a single-sentence summary, followed by standard Args/Returns docstring sections. Every section earns its place: the example and returns list are useful, and the external references are concise. It is slightly verbose due to docstring formatting, but still well-structured and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by explicitly listing the return fields. Input requirements are covered by the required parameter in schema plus an explanatory Arg section with an example. For a simple one-param read-only tool, this is complete enough; missing error behavior is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the sole parameter 'amfi_scheme_code'—and it does. It provides a concrete example ('119598' for SBI Bluechip Direct) and directs users to external sources for finding codes. This adds real meaning beyond the bare 'string' type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('latest NAV of an Indian mutual fund by AMFI scheme code'), clearly distinguishing it from sibling calculator and product tools. The one-sentence summary is unambiguous and leaves no doubt about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the context clear: use this when you need the latest NAV for a given AMFI scheme code. It also provides guidance on finding codes via mfapi.in or amfiindia.com, though it does not explicitly name alternatives or exclusions. This is clear context with no exclusions, matching the '4' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: the calculate_* tools cover different financial formulas, find_best_* tools recommend different product types, and search/get/compare form a coherent product workflow. There is no realistic ambiguity between tools despite the overlap in financial domain.
Tool names consistently follow a verb-first snake_case pattern, with clear groupings like calculate_*, find_best_*, and get_*. Minor use of abbreviations like CAGR and EMI is natural and does not break the naming convention.
12 tools is well-scoped for a personal finance assistant covering calculators, product search, product details, comparisons, recommendations, and concept explanations. Each tool earns its place without redundancy or bloat.
The tool set covers core financial calculations, product discovery, comparison, recommendations, and educational explanations, which is strong for the stated purpose. Minor gaps exist around loan/insurance product comparisons and more advanced investment planning, but agents can accomplish most typical finance workflows.