Skip to main content
Glama
longbridge

longbridge

Official
by longbridge
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
Rust
Hybrid

Create Watchlist Group

create_watchlist_group

Create a watchlist group to organize securities, optionally adding initial tickers for tracking.

Instructions

Create a new watchlist group. Optionally pass securities (e.g. ["AAPL.US", "700.HK"]) to pre-populate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
_jqNoOptional jq filter (jaq syntax) applied to this tool's JSON response before it is returned; it never changes the upstream request. One output is returned as-is, several as a JSON array, none as []. Module imports and the `env`/`debug`/`stderr` builtins are unavailable. Example: .data | map({symbol}). Omit for the full response.
nameYesGroup name
securitiesNoSecurities to add, e.g. ["700.HK", "AAPL.US"]

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.0
    • addedInput schema / properties / _jq / description
      Added value: +"Optional jq filter (jaq syntax) applied to this tool's JSON response before it is returned; it never changes the upstream request. One output is returned as-is, several as a JSON array, none as []. Module imports and the `env`/`debug`/`stderr` builtins are unavailable. Example: .data | map({symbol}). Omit for the full response."
  2. Changed2 schema fields changedv0.10.6
    • addedInput schema / properties / _jq
      Added value: +{
+  "type": "string"
+}
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "id": {
-      "format": "int64",
-      "type": "integer"
-    }
-  },
-  "required": [
-    "id"
-  ],
-  "type": "object"
-}New value: +null
  3. Changed1 schema field changedv0.7.1
    • removedInput schema / title
      Removed value: -"CreateWatchlistGroupParam"
  4. Changed4 schema fields changedv0.6.0
    • removedOutput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • removedOutput schema / description
      Removed value: -"Returned by `create_watchlist_group`."
    • removedOutput schema / properties / id / description
      Removed value: -"The newly-created watchlist group ID. Pass this to\n`update_watchlist_group` / `delete_watchlist_group`."
    • removedOutput schema / title
      Removed value: -"CreateWatchlistGroupResponse"
  5. Changed1 schema field changedv0.5.6
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "description": "Returned by `create_watchlist_group`.",
+  "properties": {
+    "id": {
+      "description": "The newly-created watchlist group ID. Pass this to\n`update_watchlist_group` / `delete_watchlist_group`.",
+      "format": "int64",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "id"
+  ],
+  "title": "CreateWatchlistGroupResponse",
+  "type": "object"
+}
  6. Addedv0.4.5
  7. Removedv0.4.0
  8. Addedv0.3.2
  9. Removedv0.3.1
  10. First observedv0.1.12

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already indicate a write operation (readOnlyHint=false, idempotentHint=false). The description adds minimal extra behavior: it explicitly says securities can be passed to pre-populate, which is also echoed in the schema. It does not disclose failure modes, permissions, or side effects beyond that. Given annotations cover the safety profile, this is acceptable but not rich.

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 one concise sentence with an example, front-loading the core purpose. No filler or redundant repetition of schema information. It is appropriately sized for the tool's simplicity.

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

Completeness3/5

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

For a simple create tool with no output schema and full annotation coverage, the description covers the essential purpose and optional parameter. However, it lacks information about behavior on duplicate names, whether the group is created empty when no securities are passed, or any constraints like group size limits. In a large sibling space, more context on uniqueness or relation to sharelist could improve completeness.

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 parameters are already documented. The description adds value by explicitly stating that securities are optional and providing a concrete example format (["AAPL.US", "700.HK"]). This reinforces the schema but doesn't significantly expand semantics beyond what's already present.

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

Purpose4/5

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

The description states a clear verb ('Create'), a specific resource ('watchlist group'), and the optional pre-population behavior. It is not a tautology and distinguishes this from delete/update siblings by the action, though it doesn't explicitly differentiate from sharelist_create or related group tools.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. There are sibling tools like delete_watchlist_group and update_watchlist_group, but the description does not mention when to choose this one, nor does it note any prerequisites or limitations (e.g., duplicate names). It leaves usage context entirely to inference.

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