Search mutual funds by name keyword. Optionally filter by SEBI category or AMC.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query — fund name or partial name | |
| amc | No | Filter by AMC name (optional) | |
| limit | No | Max results to return (default: 3, max: 100) | |
| category | No | Filter by SEBI fund category (optional) | |
| include_sif | No | Include SIF strategies in results (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It states the core action (search) and filters, which are minimal. It does not disclose the default result limit (3), pagination behavior, return format, or safety profile, but for a read-only search tool, the implicit behavior is straightforward. This adds minimal context beyond the purpose, earning a 3.
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 a single, concise sentence of 14 words, beginning with the verb 'Search.' It efficiently conveys the purpose and optional filters with no redundant wording. This is exemplary conciseness, earning a 5.
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?
The description is incomplete for a tool with no annotations and no output schema. It does not mention the default result limit (3), that results are limited, how SIF strategies fit in, or the return payload shape. An agent might incorrectly assume all matches are returned, which could affect invocation. The schema provides parameter details but not behavioral context, so the description falls short.
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 100%, so the baseline is 3. The description repeats 'SEBI category or AMC' which is already in the schema parameter descriptions. It does not add new meaning to parameters like 'limit' or 'include_sif.' Thus, the description adds no meaningful value beyond the schema, so a 3 is appropriate.
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 clearly states the tool's function: 'Search mutual funds by name keyword.' It specifies the resource (mutual funds) and the verb (search), and the optional filters (SEBI category or AMC) add specificity. This effectively distinguishes it from the sibling tool 'search_nps_schemes,' which searches NPS schemes, making the purpose unambiguous.
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 provides clear context for when to use the tool: when searching for mutual funds by name keyword. It mentions optional filters, implying the tool is appropriate for name-based searches with optional refinement. However, it does not explicitly exclude alternatives or mention when to use a different tool (e.g., 'list_funds_in_category' for browsing all funds in a category), but the intended use is evident.
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.
Tools are mostly distinct, with clear prefixes (gift, nps, sif) separating fund types. Some overlap exists among metrics/returns tools, but descriptions clarify their specific scope. Overall, an agent can differentiate tools without much ambiguity.
All tools follow a consistent snake_case verb_noun pattern (e.g., get_fund, list_categories, screen_funds). Verbs are standardized (get, list, search, compare, find, screen), making the API predictable and easy to navigate.
At 28 tools, the set exceeds the 'too many' threshold. While the domain covers multiple fund types, the count is excessive; several tools (e.g., get_metrics, get_gift_metrics, get_nps_metrics) could be consolidated with parameters. This may overwhelm agents.
The tool surface is comprehensive for a read-only mutual fund data server. It covers search, comparison, screening, NAV history, holdings, quantitative metrics, benchmarks, and specialized segments (GIFT, NPS, SIF). No critical gaps were identified.
