fund_holdingsA fund's current portfolio positions with quarter-over-quarter change.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Fund slug (URL identifier). |
| Name | Required | Description | Default |
|---|---|---|---|
| fund | Yes | ||
| quarter | Yes | ||
| holdings | Yes | ||
| provenance | Yes | ||
| total_value | Yes |
Changes observed during successful MCP inspections.
Output schema / properties / holdings / items / properties / change / enumPrevious value: -[
- "new",
- "add",
- "trim",
- "hold",
- "sold"
-]New value: +[
+ "new",
+ "add",
+ "trim",
+ "hold",
+ "sold",
+ "unknown"
+]Output schema / properties / holdings / items / properties / security / properties / listingAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "disclosure_note": {
+ "type": "string"
+ },
+ "event_type": {
+ "enum": [
+ "ipo",
+ "direct_listing",
+ "spin_off"
+ ],
+ "type": "string"
+ },
+ "listed_on": {
+ "format": "date",
+ "type": "string"
+ },
+ "recently_listed": {
+ "type": "boolean"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "listed_on",
+ "event_type",
+ "recently_listed",
+ "source_url",
+ "disclosure_note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / holdings / items / properties / security / requiredPrevious value: -[
- "ticker",
- "name"
-]New value: +[
+ "ticker",
+ "name",
+ "listing"
+]Output schema / properties / holdings / items / properties / position_typeAdded value: +{
+ "enum": [
+ "direct",
+ "call",
+ "put"
+ ],
+ "type": "string"
+}Output schema / properties / holdings / items / requiredPrevious value: -[
- "security",
- "shares",
- "value",
- "percent_of_fund",
- "change",
- "change_percent"
-]New value: +[
+ "security",
+ "position_type",
+ "shares",
+ "value",
+ "percent_of_fund",
+ "change",
+ "change_percent"
+]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 it returns current positions and quarter-over-quarter change, which is useful behavioral context about the data content. However, it does not mention pagination, limits, or any special handling beyond the annotations, so it adds moderate value.
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 that front-loads the core purpose ('current portfolio positions') and includes the key differentiator (QoQ change). There is zero redundancy or irrelevant detail.
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 tool with one parameter and an existing output schema, the description is largely complete. It conveys the essential information: the resource (fund holdings) and the temporal aspect (current, with QoQ change). The output schema likely covers the exact structure, and annotations cover safety. Minor gaps like whether holdings are limited to top positions are not critical given the schema.
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?
The input schema fully describes the slug parameter as 'Fund slug (URL identifier)' with 100% coverage. The tool description adds no additional parameter semantics, so the baseline of 3 applies since the schema carries the burden.
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 provides a fund's current portfolio positions and quarter-over-quarter change. This specific verb-resource combination distinguishes it from siblings like fund_history (historical data) and get_fund (fund metadata), 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?
No guidance is given on when to use this tool versus alternatives. While the description implies it is for current holdings with QoQ change, it does not explicitly mention that fund_history might be used for historical trends or that get_fund covers basic fund details. The agent is left to infer usage context from the name and sibling list.
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.