Search or list National Pension System (NPS) schemes by scheme/PFM name, tier, plan, or PFM.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search query (optional) | |
| pfm | No | Exact Pension Fund Manager name (optional) | |
| plan | No | Plan label filter, e.g. Equity, Central Government, Vatsalya (optional) | |
| tier | No | Tier I or Tier II filter (optional) | |
| limit | No | Max results (default: 50, max: 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action (search/list) and filter dimensions, but does not mention return format, pagination, default/max limits, or whether searches are exact or fuzzy. It is not misleading, but it is rather minimal for a search tool.
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, front-loaded sentence that efficiently conveys the tool's purpose and scope. There is no redundancy or filler; every phrase adds value.
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?
For a simple search tool with full schema coverage, this one-line description is mostly complete: it identifies the resource, the action, and the available filters. It lacks explicit guidance on when to prefer it over search_funds or get_nps_scheme, and does not state the read-only nature (which is otherwise obvious for a search), but given the low complexity, it is sufficient.
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% as all five parameters have descriptions. The description merely paraphrases the parameter fields ('scheme/PFM name, tier, plan, or PFM') without adding new meaning such as query syntax, filter interplay, or formatting rules. Baseline 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 uses a specific verb ('Search or list') and identifies the resource ('National Pension System (NPS) schemes') along with the filter dimensions (scheme/PFM name, tier, plan, PFM). This clearly distinguishes the tool from similar siblings like search_funds, which targets mutual funds, and get_nps_scheme, which likely retrieves a single scheme.
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 implies the tool is for searching or listing NPS schemes, which provides some context for when to use it. However, it does not explicitly mention alternatives such as search_funds or get_nps_scheme, nor does it provide any exclusions or conditions for choosing this tool over siblings. The guidance is indirect.
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.
