Skip to main content
Glama
Sign In

NightWatch Live Intelligence

by io.github.jamboree777
OverviewDiscussionsAdmin

Search tokens

search_tokens
Read-onlyIdempotent

Search for tokens by symbol or name across all monitored exchanges. Each item has rating {grade, grade_detail} (the 7-day liquidity grade, same as get_token_intel rating); the top-level grade is the last single scan's grade, with grade_last_as_of and grade_last_stale saying how old that scan is. Requires: query.

Input Schema

NameRequiredDescriptionDefault
limitNoMax items (default 20, max 100)
queryYesSearch query (e.g. BTC, ETH, DOGE)
offsetNoItems to skip, for paging (default 0)
exchangeNoFilter by exchange id or two-letter venue code (optional)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / exchange / description
      Previous value: -"Filter by exchange (optional)"New value: +"Filter by exchange id or two-letter venue code (optional)"
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 20,
+  "description": "Max items (default 20, max 100)",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "Items to skip, for paging (default 0)",
+  "type": "integer"
+}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes further by explaining the returned rating structure, the distinction between the 7-day liquidity grade and the last-scan grade, and the staleness fields. It does not mention pagination limits or any rate/cost constraints, so it stops short of full behavioral coverage.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence and the return-field semantics follow compactly. The middle sentence is dense but each clause (rating shape, top-level grade meaning, staleness fields) carries distinct information, so little is wasted.

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?

With no output schema, the description usefully explains the non-obvious return fields, and annotations cover safety while the schema covers all four parameters. It omits paging behavior and what the exchange filter accepts, which are minor given the 100% schema coverage.

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 limit, offset, exchange, and query are already documented in the schema, and the description adds no syntax or format detail beyond restating the query requirement. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

States a specific verb and resource ('Search for tokens by symbol or name') plus the scope ('across all monitored exchanges'). It also implicitly distinguishes itself from get_token_intel by cross-referencing that tool's rating field, so an agent can tell the two apart.

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

Usage Guidelines3/5

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

The search-by-symbol-or-name framing and 'Requires: query' imply when to reach for this tool, but there is no explicit when-not guidance or routing to alternatives. get_token_intel is mentioned only to disambiguate a return field, not to tell the agent when to prefer one over the other.

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

All NightWatch Live Intelligence toolsInspect
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