AstraEye Labs

Add to the watchlist

add_to_watchlist

Idempotent

Adds assets to the member's watchlist, by the assetIds from find_assets, or every member of one market slice with a fixed list (marketSliceId from list_market_slices). Call it only when the member asked to add them. At most 25 assets per call, all added together or none. An asset already there is reported, not added twice.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "add_to_watchlist"
  }
}

Input Schema

Name	Required	Description
`assetIds`	No	The assets to add, by assetId. From find_assets or list_watchlist; at most 25.
`marketSliceId`	No	Instead of assetIds: a market slice id whose members are all added.
`clientRequestId`	No	Optional UUID you generate for this request. Retrying with the same id never does it twice.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important mutation behavior: the 25-asset cap, atomic all-or-none insertion, and duplicate handling where existing assets are reported rather than added twice. This is consistent with readOnlyHint=false and idempotentHint=true, and it gives the agent transaction-level context that the annotations do not.

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 short and front-loaded: it states the action first, then the usage condition, then the size and atomicity constraints, then duplicate behavior. Every sentence adds useful information with no filler.

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

Completeness4/5

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

It covers the core semantics needed to invoke the tool correctly, including input modes, cap, atomicity, and duplicate behavior. However, with no output schema and no required parameters declared, it does not explicitly state that at least one of assetIds or marketSliceId must be supplied, nor does it fully describe the success response.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents assetIds, marketSliceId, and clientRequestId. The description adds the provenance of assetIds and marketSliceId and reinforces their either/or relationship, but it does not explain clientRequestId or add much beyond the schema. Baseline 3 is appropriate.

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 states a specific verb and resource: adds assets to the member's watchlist. It clearly distinguishes the two input modes, assetIds from find_assets or a marketSliceId from list_market_slices, so an agent can tell it apart from list_watchlist and remove_from_watchlist without opening the schema.

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

Usage Guidelines4/5

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

It gives a clear usage condition: call it only when the member asked to add the assets. It also points to find_assets and list_market_slices as input sources. It does not explicitly name when to prefer list_watchlist or remove_from_watchlist instead, so it is strong but not complete.

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

All AstraEye Labs tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?