Funding histories, bank filings and settlement data with source receipts, units and capture clocks.
Scored across 6 tools
Each tool targets a distinct research resource: analysis outputs, catalog discovery, entity identifiers, observational data, metric series, and tracked institution populations. No two tools describe overlapping operations or ambiguous boundaries.
All tools follow a strict 'research_' prefix followed by a clear resource noun (analysis, catalog, entities, observations, series, tracked_institutions). The verb_noun pattern is consistent and predictable across every tool.
With six tools covering distinct aspects of the data source domain (catalog discovery, analysis retrieval, entity mapping, observation reads, series search, and tracking populations), the count is well-scoped and each tool earns its place without unnecessary redundancy.
The toolkit provides comprehensive read-only coverage for research workflows: discovering datasets, reading analyses and observations, searching metrics, and querying entity/tracking info. Minor gaps exist (e.g., no direct bulk export or cross-referencing tool), but core needs are fully covered.
Read descriptive funding, institution concentration and settlement analysis with input references and limits.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds little beyond 'Read' and the vague 'with input references and limits'; it does not explain output shape, pagination, limits behavior, or what the input references refer to. There is no contradiction with the annotations.
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 short sentence, which is concise, but it is structurally awkward: 'descriptive funding' is unclear, and 'with input references and limits' is ambiguous. It front-loads the verb but does not communicate clearly enough for the length.
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 tool with one optional parameter, no output schema, and sibling tools that overlap in the research domain, the description should explain what the product parameter does and what kind of analysis output to expect. It provides neither, leaving an agent unable to confidently select the right product value or understand the tool's scope.
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?
There is only one parameter, 'product', and the schema description coverage is 0%. The description never explains what 'product' means, how the enum values (seiche, liquilens, undertow) map to the mentioned analysis types, or why the parameter is optional. The description completely fails to compensate for the missing schema documentation.
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 names a specific action ('Read') and a concrete resource ('funding, institution concentration and settlement analysis'), which distinguishes it from the sibling tools that focus on catalog, entities, observations, series, and tracked institutions. However, the phrase 'with input references and limits' is vague and the overall wording is awkward, so it is not a 5.
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 reading certain analysis types, but it provides no explicit guidance about when to use this tool versus the five siblings, no conditions, and no exclusions. An agent is left to infer usage context from the tool name and the analysis categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover scoped funding, institution and chain-settlement datasets with coverage and rights.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety behavior is clear without description-level disclosure. The description adds some domain context about scoped datasets and coverage/rights, but it does not mention response format, pagination, or any operational quirks. This is consistent with the annotations, so no contradiction.
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 focused sentence with no filler, and the intended action is front-loaded via 'Discover scoped...'. It is appropriately concise, though the phrase 'coverage and rights' is compressed to the point of mild ambiguity.
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 one optional parameter and no output schema, the description should clarify what product values mean and what kind of result an agent should expect. It does neither. An agent could guess the purpose but would not know how to correctly select a product or interpret the returned datasets. The description is minimally usable but incomplete.
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%, and the description never mentions the 'product' parameter or its enum values (seiche, liquilens, undertow). The schema only provides allowed values without meaning, and the description does not explain how selecting a product changes the results. The single parameter is left semantically opaque.
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 ('Discover') and a clear object ('scoped funding, institution and chain-settlement datasets') to identify the tool's core function. It conveys a catalog/discovery role, though it does not explicitly differentiate itself from the sibling research_* tools. The mention of 'coverage and rights' adds a distinguishing flavor but leaves some ambiguity.
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?
There is no guidance on when to use this tool versus research_analysis, research_entities, or other siblings. No conditions, exclusions, or alternatives are given. The imperative 'Discover' only weakly implies that an agent should call this when looking for datasets, but that is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find regulator identifiers for institutions; names are not fuzzy-joined across regimes.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| offset | No | ||
| dataset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which cover safety. The description adds a specific behavioral trait—that name matching is not fuzzy across regimes—which goes beyond the annotations and informs the agent about exact-match semantics. This is valuable additional context.
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 sentence that front-loads the primary purpose ('Find regulator identifiers') and then adds the key caveat. It contains no filler or redundant content, achieving maximum efficiency.
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 four parameters (one required), no output schema, and no parameter descriptions, the description is far too sparse. It does not explain what 'dataset' refers to or how 'q', 'limit', and 'offset' behave. An agent cannot confidently construct a correct call without additional information.
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 parameter meanings. It fails to explain any of the four parameters, including the required 'dataset' and the optional 'q', 'limit', and 'offset'. The description gives no clues about what these parameters control, leaving the agent to guess.
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 and resource: 'Find regulator identifiers for institutions.' This is clear and distinct from sibling tools like research_analysis or research_catalog, though it doesn't explicitly name any sibling. The caveat about fuzzy-joining adds specificity but doesn't directly differentiate from alternatives.
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 exact matching per regime ('names are not fuzzy-joined across regimes') but does not explicitly state when to use this tool versus research_tracked_institutions or other siblings. It provides a limitation but no direct usage guidance or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read cited observations or a captured historical vintage. Earlier point-in-time availability is not assumed.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| limit | No | ||
| start | No | ||
| entity | No | ||
| offset | No | ||
| series | Yes | ||
| dataset | Yes | ||
| as_known_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral caveat that earlier point-in-time availability is not assumed, which is useful context beyond the annotations. However, it doesn't disclose pagination behavior, return format, or how 'as_known_at' interacts with the vintage concept.
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 sentence plus a short caveat, which is appropriately concise. The key action and resource are front-loaded, and the caveat about point-in-time availability is placed second. It earns its place, though it could add a bit more guidance without becoming bloated.
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 8 parameters, 0% schema coverage, no output schema, and no parameter descriptions, the description is too thin. An agent cannot determine what 'dataset' vs 'series' vs 'entity' mean, how 'as_known_at' works, or what the response looks like. The annotations cover safety but not semantics, so the description is incomplete for a tool of this complexity.
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 8 undocumented parameters. It only hints at 'historical vintage' and 'point-in-time availability', which loosely maps to 'as_known_at' and 'start'/'end', but it doesn't explain the meaning of 'dataset', 'series', 'entity', 'limit', or 'offset'. The description adds minimal value over the bare 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 ('Read') and resource ('cited observations or a captured historical vintage'), which distinguishes it from analysis/catalog/entities/series tools. However, it doesn't explicitly name a sibling or elaborate on what 'cited observations' means, so it's clear but not fully differentiated.
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 phrase 'Earlier point-in-time availability is not assumed' implies a caution about historical data availability, giving some context for when to use this tool. But it doesn't explicitly state when to use this vs. research_analysis or research_catalog, nor does it provide exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the metric catalog and native unit definitions in a dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| offset | No | ||
| dataset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool searches both metric catalog and native unit definitions, which is useful scoping, but it does not disclose pagination behavior, query semantics, or what happens with no query.
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, clear, front-loaded sentence with no wasted words. It is concise, though it sacrifices useful detail for brevity.
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 search tool with no output schema and no parameter documentation, the description is incomplete. An agent cannot reliably know what 'q' expects, how pagination works, or what the result set contains. The annotations cover safety but not operational semantics.
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%, and the description does not explain the meaning of 'q', 'limit', or 'offset'. It only mentions 'dataset', leaving the primary search parameter and pagination controls undocumented for the agent.
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 action ('Search') and a specific resource ('the metric catalog and native unit definitions in a dataset'). It is clear about what the tool operates on, though it does not explicitly distinguish itself from the similarly named sibling 'research_catalog'.
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?
No guidance is given about when to use this tool versus alternatives like research_catalog or research_observations. The description implies a search use case but provides no exclusions, prerequisites, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the existing Indian dossier and RBI registry populations, retaining financial-evidence gaps and source clocks. Populations overlap and are not a global census.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| scope | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety burden is covered. The description adds meaningful behavioral context by saying results retain financial-evidence gaps and source clocks and that the two source populations overlap, which clarifies what the search will and won't represent. No contradiction with annotations.
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?
Two sentences with the main action front-loaded and no filler. The second sentence earns its place by adding a census caveat, though the phrase 'retaining financial-evidence gaps and source clocks' is jargon-heavy and slightly undermines clarity.
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 search tool with no output schema and no parameter descriptions, the definition is adequate but incomplete: it conveys the population and scope but leaves return shape, default behavior, and explicit usage conditions to inference. Annotations cover the safety profile, which prevents this from being lower.
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 carries the burden. It maps the domain-specific scope values ('Indian dossier', 'RBI registry') and adds overlap semantics, but it does not address q, limit, or offset, even though those are largely self-explanatory search and pagination parameters.
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 leads with a specific verb ('Search') and identifies the exact resource: existing Indian dossier and RBI registry populations. It makes the tool's subject clear but does not explicitly distinguish it from sibling research_* tools, so it stops short of a 5.
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 note that populations overlap and are not a global census implies a bounded, non-exhaustive search context and warns against treating results as a full census. However, it does not state when to prefer this tool over alternatives or offer explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
research_analysisresearch_catalogresearch_entitiesresearch_observationsresearch_seriesresearch_tracked_institutionsSource-backed treasury data, settlement costs. Free instrument records and history.
Read-only public financial evidence from LiquiLens, Undertow, Seiche and Palimpsest.
Multi-venue VWAP, bid/ask, crypto FX, metals and equities with provenance receipts for AI agents
Dated funding and SEC 8-K events, each linked to the filing it came from.
Add one secure layer between your agents and this server.
