Stock Screener

Stock Screener (SentiSense)

Filter the tracked US stock and ETF universe in one query. This is the only surface where SentiSense's own signals, the SentiSense Score and social attention, sit in the same WHERE clause as analyst consensus, technicals, momentum, and price. A screen on analyst ratings alone is something a dozen free tools already do; a screen on analyst ratings where the Score disagrees is not. 28 curated screens ship ready to run, and all 49 screenable fields are available for custom plans; both are enumerated in the appendix at the end of this skill.

This skill's job is translation: turning what the user actually asked ("find me oversold stocks people are turning bullish on") into a valid, honest screen plan, running it, and presenting the results with the plan visible so the user can tighten or loosen it.

Read-only educational data interface. Output is informational context, never a personalized buy or sell recommendation.

When to Use

• "Find me stocks that..." or "which stocks are..." in any combination of sentiment, analyst, price, momentum, or size conditions
• "Screen for unusual social volume", "what is oversold but loved", "where do analysts and the crowd disagree"
• "Run the momentum screen", "what are the curated screens?"
• "Screen my watchlist": the same plans run against a fixed ticker list
• ETF questions in the same shape: "low-cost broad funds with bullish holdings"

Not this skill: single-ticker deep dives (stock-sentiment, stocks-analysis; the latter is us-stocks-analysis on ClawHub), options positioning (unusual-options-activity), price quotes (the sentisense reference). Screener rows read a snapshot refreshed every 20 minutes; it is a research surface, not a quote feed.

Prerequisites

• A free SENTISENSE_API_KEY. Get one at https://app.sentisense.ai/get-api-key. The key is required on every call; anonymous requests return 401 api_key_required.
• Any HTTP client.
• Read-only scope: everything here is a GET or a filter-only POST. Nothing this skill does can place a trade, move money, or modify account state.

A screen is a single request no matter how many rows it returns, so prefer one broad screen plus client-side slicing over many narrow ones.

Permissions

• Network: HTTPS to app.sentisense.ai only.
• Credentials: SENTISENSE_API_KEY from the environment.
• Shell: none required.
• Files: none.

How to Run

The REST recipe in this file is the primary path. A maintained command-line client is available as the separate sentisense-cli skill for hosts that prefer one.

Identify your client. Send a User-Agent naming your agent runtime and this skill, for example OpenClaw/1.4 (stock-screener) or ClaudeCode/2.1 (stock-screener). Substitute your own runtime and version if neither matches. You can also volunteer what your agent is called by adding an agent/<your-agent-name> token inside the same parentheses, as in OpenClaw/1.4 (stock-screener; agent/research-desk). All of it is optional, and it is what tells us this skill has real integrations behind it, so it gets prioritized and you get notice before it changes.

Use this REST request:

curl -X POST https://app.sentisense.ai/api/v1/screener/execute \
  -H "X-SentiSense-API-Key: $SENTISENSE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "plan": { "filters": [ { "fieldName": "SENTI_SCORE_7D", "op": "GTE", "value": 13 } ], "sort": { "fieldName": "SENTI_SCORE_7D", "dir": "DESC" } }, "limit": 25 }'

The response is flat and the rows are at .results[], not .data. execute answers with exactly three top-level keys, { results, matched, limit }: results is the row array, matched is the pre-limit total and limit echoes what you asked for. There is no { isPreview, previewReason, data } envelope on this endpoint, so an agent carrying the .data habit over from the rest of the API reads undefined and reports "no matches" on a screen that matched. results is an empty array when nothing matched, which is the real no-match signal, and matched says how many rows exist behind the limit.

Endpoints: POST /api/v1/screener/execute (stocks), POST /api/v1/screener/etfs/execute (ETFs, same shape), GET /api/v1/screener/fields (the catalog), GET /api/v1/screener/screens (curated screens with their full plans). limit sits next to plan (default 100, cap 500); an optional top-level tickers array scopes the screen to a watchlist. An unrecognized field name returns HTTP 400 with a message naming the bad field and listing the valid ones, and field names are case-sensitive: take them from GET /api/v1/screener/fields, never from guesswork.

One REST shape difference that the numeric example above does not show: IN and NOT_IN filters take a values array, not value. Sending "value" (singular) gets a generic 400 malformed_request that does not name the problem, so this is worth getting right the first time:

{ "plan": { "filters": [ { "fieldName": "ISSUER", "op": "IN", "values": ["Vanguard", "iShares"] } ] } }

The shorthand ISSUER:IN:Vanguard,iShares means { "fieldName": "ISSUER", "op": "IN", "values": ["Vanguard", "iShares"] }; convert every shorthand filter in this file to that JSON shape before executing it. Four fields are string-typed and take IN/NOT_IN: SENTISENSE_RATING in the stock universe, and ISSUER, ASSET_CLASS, TRACKED_INDEX in the ETF universe. The live values for the three ETF fields come back in the fields catalog at GET /api/v1/screener/fields, alongside each field's name, operators, unit, description, and values array.

Translating a fuzzy ask (the procedure)

Most screening requests arrive fuzzy. Translate them honestly:

1. Check the curated screens first with GET /api/v1/screener/screens. If one matches the intent, post its plan unchanged to the stock or ETF execute endpoint and say which one you used; the curated plans are also worked examples of the plan shape, so quote the plan when adapting one. In the names, + means both conditions hold and vs means the two sides disagree.
2. Get the field catalog with GET /api/v1/screener/fields rather than guessing names. The catalog carries units, operators, descriptions, and allowed array values, and grows without notice; a guessed field name is a 400, never a silent wrong answer. The appendix below is a per-release snapshot of the same catalog, good for planning without a call; the live catalog can be ahead of it.
3. Map intent words to field groups. "Loved / bullish / mood improving" is the Score group; "everyone is talking about it" is popularity (SOCIAL_DOMINANCE, MENTION_VELOCITY); "cheap lately / beaten down" is PCT_OFF_52W_HIGH or the moving-average distances; "analysts like it" is the analyst group; "big / liquid" is MARKET_CAP and VOLUME.
4. Add a coverage guard when a ratio can be thin. ANALYST_BUY_RATIO_PCT from one analyst is noise: pair it with ANALYST_COUNT GTE 5. If a screen returns fewer rows than expected, check field coverage before loosening thresholds.
5. Show the plan with the results. The user can only correct a translation they can see. State filters, sort, and matched count; matched is the pre-limit total, so truncation is visible. Say it as three numbers when they differ: "56 matched, showing 50, more exist" (more exist whenever matched is greater than the rows returned).
6. There is no OR. Filters AND together; for an OR, run two screens and merge client-side, saying so.

Popular asks, translated

The phrases people actually type, mapped to the screen that answers them. For a curated id, find that entry in GET /api/v1/screener/screens, then post its returned plan unchanged to the stock execute endpoint, or the ETF endpoint for an etf- id. Custom plans below use compact FIELD:OP:VALUE shorthand: convert each triple to { "fieldName": "FIELD", "op": "OP", "value": VALUE }, using values instead of value for IN and NOT_IN, then put the displayed sort in the plan's sort object. Show the executed plan with the results every time, so the user can loosen or tighten it.

Two habits keep these honest: say which window a field measures (the 7-day Score versus its 1-month baseline, 3-day mention velocity, 30-day analyst momentum), and treat an empty result as the data, not a broken filter; the fix is to loosen one threshold and say so, never to invent a row.

Field semantics that produce wrong-but-plausible screens

These four are the known traps; getting them wrong yields a screen that runs fine and means nothing:

• SENTISENSE_RATING is a letter, and it is a rank. Values A, B, C, D, F; operators IN and NOT_IN only, with the letters in a values array ({ "fieldName": "SENTISENSE_RATING", "op": "IN", "values": ["A", "B"] }). The letters are fixed slices of the rated universe, so an A means "top 10 percent of stocks rated today", never "a stock to buy". Sorting the field resolves to the underlying percentile rather than the letter's alphabetical order, so DESC puts the strongest rank first. Rows come back with ratingLetter and ratingPercentile; quote the percentile beside the letter. Stocks with too little data are unrated and match no letter, so NOT_IN ["F"] is not the complement of IN ["F"].
• ANALYST_RATING_MEAN is inverted. Vendor 1-to-5 scale where 1.0 is strong buy. Bullish is LTE 2.5, not GTE. Prefer ANALYST_BUY_RATIO_PCT, which runs the intuitive direction.
• Score fields are banded, not [-1, 1]. The SentiSense Score is unbounded (roughly -30 to +45 across the universe) with bands at 5, 13, and 23 either side of zero: above +5 bullish lean, +13 bullish, +23 strong. Filter on band edges; GTE:0.5 is a polarity-scale habit that silently means "any positive score". SENTI_SCORE_7D and SENTI_SCORE_1M are window averages; SCORE_CHANGE_7D is the 7-day minus the 1-month baseline, so positive means strengthening.
• Nulls never match, in either direction. RETURN_1Y >= 0 and RETURN_1Y < 0 do not partition the universe: a recently listed stock is in neither. Sorting puts nulls last regardless of direction.

Two enum fields are used with EQ: MA_CROSS_STATE (1 golden cross, -1 death cross, 0 neither) and SENTIMENT_DIRECTION (1 above +5, -1 below -5, 0 the neutral band, where most of the universe sits on a typical day). The catalog lists EQ as their operator; stick to it even where other operators happen to evaluate.

SCORE_CHANGE_7D and SENTI_SCORE_TREND_7D are different measurements, not aliases, and mixing them up in an explanation is a common slip. SCORE_CHANGE_7D is a level difference: the 7-day Score minus the 1-month baseline, so positive means stronger than the longer window. SENTI_SCORE_TREND_7D is a slope: score points per day over the last 7 days, null when the week is too sparse to call. A stock can be positive on one and negative on the other (strong versus last month but fading this week). Use the field's own catalog description when explaining a screen, and name the field you actually filtered on. ANALYST_COUNT sums the rating buckets, which deliberately differs from the vendor's own analyst count.

ETF universe: CONSTITUENTS_WEIGHTED_SENTISENSE is the holdings-weighted Score across what the fund owns (usually the one you want); DIRECT_SENTISENSE is chatter about the fund's own ticker, mostly macro noise on an index fund. Check WEIGHT_COVERED_PCT before leaning on a weighted number, and use IN/NOT_IN on the string fields (ISSUER, ASSET_CLASS, TRACKED_INDEX), whose live values come back in the fields catalog.

Workflows

1. Run a curated screen. Fetch GET /api/v1/screener/screens, pick an entry by intent, and post that entry's plan unchanged to POST /api/v1/screener/execute, or to POST /api/v1/screener/etfs/execute when its id starts with etf-. Wrap the returned plan in the request body's plan field, with limit alongside it, as in the example above. Do not send a screen id to either execute endpoint. The 17 stock screens and 11 ETF screens are listed with what each finds in the appendix. Screen ids are stable and never reused, but a screen can be retired, so handle a missing id gracefully.

2. Translate a fuzzy ask. "Beaten-down names the crowd is warming to" becomes: PCT_OFF_52W_HIGH:LTE:-30, SCORE_CHANGE_7D:GTE:5, sort by SCORE_CHANGE_7D:DESC, with the plan shown alongside the results. Compare with the curated oversold-with-positive-sentiment and say if you diverged and why.

3. Screen a watchlist. Add a top-level tickers array next to plan in the execute request to run any plan against the user's own list instead of the universe.

4. Hand off the results. For "research these candidates", hand off to the stocks-analysis skill when available. Pass the executed plan, universe, one to three user-selected rows, source dates where available, and the research question. Return per-name thesis evidence and contrary facts for the selected names. Hand off only when the user changes the question; do not automatically route back. If the sibling is unavailable, answer the supported part here using a connected tool or the inline REST workflow, state any remaining gap, and never require an install.

Reading results

Rows arrive in results[] (see How to Run: this endpoint is flat, with no .data envelope). Every row carries the full field set (nulls where uncovered) plus render-ready extras: week52High/week52Low, lastUpdated (epoch seconds), and three small series per ticker (sentisenseScoreBars7D, sentisenseScoreBars30D, priceSparkline30D), so results are chartable without a second call. Prices in rows come from the 20-minute snapshot: fine for screening, not for quoting; say "as of the latest screener snapshot" rather than presenting them as live.

Appendix: every field and every curated screen (snapshot)

Generated from the same catalog the API serves, refreshed with every release of this skill. The live responses from GET /api/v1/screener/fields and GET /api/v1/screener/screens are authoritative and can be ahead of this table; use this appendix to plan, and the live catalog to execute. Field names are case-sensitive and go into plans verbatim. Numeric fields take GTE/GT/LTE/LT and are sortable; nulls never match a filter and always sort last.

Stock fields (33)

ETF fields (16)

Curated stock screens (17)

Fetch GET /api/v1/screener/screens for the full plans, then post the selected plan to the matching execute endpoint.

Curated ETF screens (11)

Going further

PRO ($15/mo) lifts the monthly request cap (no monthly limit, just a 300/min rate) and unlocks full depth across the SentiSense API: institutional flows, insider detail, full congressional history, and AI insights. Apply coupon AGENTS26 at checkout for a builder launch discount: https://app.sentisense.ai/pricing?coupon=AGENTS26

For the full REST reference, install the sentisense skill; for the complete CLI command set, install sentisense-cli.

Install: npx skills add SentiSenseApp/skills (add -s stock-screener for just this skill).

SentiSense is a read-only financial intelligence API. This data is for informational and educational purposes only, not investment advice.