Qanvo Stock Screener

Create an email alert

create_alert

Turn a screen into an email alert. Give a plain-English screen in prompt (it runs like market_query and uses the same credits), or the query_id and session_id of an earlier result. Qanvo then re-runs that screen's saved query on a fixed schedule (no AI, no credits) and emails the account's address when stocks enter or leave the results, or every time. Schedules follow the market's exchange hours: "after_close" (once that day's prices are in: usually that evening for US stocks, early next morning for other markets), "pre_open" (an hour before the open, trading days) or "weekly" (first trading day, before the open). Today's list is emailed straight away. Example: prompt "stocks crossing above their 200-day average on twice their average volume", schedule "after_close". Research alerts only, not investment advice.

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": "create_alert"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	A short name for the alert; defaults to the screen's title.
`market`	No	Optional market (ISO country code such as US, GB, IN); also sets whose trading hours the schedule follows.
`prompt`	No	The screen in plain English. Omit when passing query_id and session_id.
`query_id`	No	query_id of an earlier market_query result to alert on.
`schedule`	No	after_close (default), pre_open or weekly.	after_close
`session_id`	No	session_id of that result.
`notify_when`	No	changes (default: only when stocks enter or leave) or always.	changes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), it discloses that the saved query re-runs on a schedule with no AI and no credits, that emails go to the account address, that today's list is sent immediately, and how each schedule maps to exchange hours. That is substantial behavioral context an agent could not infer from structured fields.

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?

Front-loaded with the core action and dense with useful detail, but the schedule values are restated from the schema and the parenthetical timing explanations make it longer than strictly necessary.

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?

For a 7-parameter creation tool with no output schema, it covers inputs, scheduling behavior, and the immediate email side effect well. It omits what the call returns (e.g., an alert id) and any limits on number of alerts or name collisions.

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

Parameters4/5

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

Schema coverage is already 100%, but the description adds real meaning: prompt 'runs like market_query and uses the same credits', market also determines whose trading hours the schedule follows, and the schedule enum values are explained with concrete timing. It does not clarify notify_when beyond the schema's own wording.

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 opening sentence states a specific verb and resource ('Turn a screen into an email alert') and the body clarifies the two input modes, which cleanly separates it from update_alert, delete_alert and list_alerts.

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 clearly explains the two ways to supply a screen (plain-English prompt vs. query_id/session_id of an earlier market_query result) and when each applies. It does not explicitly contrast with update_alert or qanvo_app_alert_create, so the sibling routing is only implied.

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

All Qanvo Stock Screener 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?