Skip to main content
Glama
myfinancialria

MyFinancial Market Data MCP

by myfinancialria
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update Portfolio Stock

update_portfolio_stock

Update an existing stock's total quantity and average buy price in your portfolio. Handles additional buys, quantity changes, and partial sells with weighted average calculations.

Instructions

Update the quantity and/or average price of an existing stock in the user's portfolio.

Use cases: • User says "I bought 10 more RELIANCE at ₹1,400" → you must calculate the new total qty and weighted avg price, then call this tool • User says "Change my TCS quantity to 50" → direct update • User says "I sold 5 shares of INFY" → reduce quantity (calculate new qty = old - 5)

IMPORTANT workflow for additional purchases:

  1. First call get_user_portfolio to get current quantity and avg_price

  2. Calculate: new_qty = old_qty + additional_qty

  3. Calculate: new_avg = (old_qty × old_avg + additional_qty × purchase_price) / new_qty

  4. Call this tool with the NEW total quantity and NEW weighted average price

For partial sells:

  1. new_qty = old_qty - sold_qty (avg_price stays the same)

  2. If new_qty = 0, use remove_portfolio_stocks instead

Both quantity and avg_price are required — always provide the final values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYesStock symbol to update (e.g. RELIANCE)
quantityYesNew TOTAL quantity (not the additional amount)
avg_priceYesNew average buy price per share in ₹

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses critical behavioral expectations: the tool expects final total quantity and weighted average price rather than deltas, both fields are required, and it should not be used when the result quantity is zero. The step-by-step workflow for additional purchases and partial sells gives the agent a clear mental model of how the update behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured logically: a concise opening statement, clear use-case examples, a numbered workflow, and a final reminder about required values. It is long, but every sentence contributes actionable guidance needed to call the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully covers the operational context for a complex mutation tool: prerequisite reads, calculation steps, edge cases like partial sales and zero quantity, and the exact input contract. No essential information is missing for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While the schema already has strong descriptions at 100% coverage, the description adds meaning through worked examples and explicit formulas. It reinforces that quantity and avg_price must be final values, resolves ambiguity about 'additional amount', and even clarifies currency in examples. This goes well beyond the schema's baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: updating quantity and/or average price of an existing stock in the user's portfolio. It is easily distinguished from sibling tools like add_portfolio_stocks and remove_portfolio_stocks, and explicitly references the removal tool as the alternative when quantity reaches zero.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is exceptional. It gives concrete user-prompt examples, explains when to first call get_user_portfolio, supplies the exact weighted-average formula, and explicitly routes zero-quantity cases to remove_portfolio_stocks. There is no ambiguity about when to invoke this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools