Skip to main content
Glama
753,201 tools. Updated 2026-11-06 19:34

"Lucid" matching MCP tools:

  • Audit compliance/GPSR del catalogo (EU/IT). Per ogni SKU verifica gli attributi compliance REALI del suo product type (schema-aware): manufacturer, rtip_manufacturer_contact_information (contatto fabbricante), country_of_origin, safety_warning, safety_data_sheet_url e — dove il product type li prevede — i GPSR: gpsr_safety_attestation, gpsr_manufacturer_reference, dsa_responsible_party_address (responsabile EU). Incrocia gli ISSUE Amazon a tema compliance (Amazon dice cosa manca/è rifiutato). Ritorna gli SKU con gap, priorità (alta = issue ERROR Amazon o GPSR mancante), conteggi per attributo e i gap più frequenti. Flagga "mancante" SOLO se il product type prevede davvero l'attributo. NB: i numeri EPR (Francia / LUCID DE / RAEE-batterie) sono a livello ACCOUNT in Seller Central → Conformità, NON attributi listing: SP-API ne legge l'alert ma non li imposta. Per correggere usa update_listing. READ-ONLY. mode="full" = verifica TUTTI I REQUISITI del product type: ogni attributo `required` dello schema Amazon della categoria (inclusi i requisiti di categoria, es. pharma/parafarmacia) + TUTTE le issue Amazon di qualsiasi categoria. Usa mode="full" quando l'utente chiede di verificare "tutti i requisiti di conformità" dei prodotti; il default (standard) resta il check rapido compliance/GPSR.
    ConnectorOAuth
  • Jobs — Opens the Worklittle jobs MAP for a place and an optional role. This is a map query, not a list of jobs: the map recenters on the place and shows jobs there, so send the place and the role as SEPARATE fields. Never write 'product manager in San Francisco' as one query. PLACE: always pass near_lat + near_lng (the city's coordinates, which you know) and location as the display name (e.g. 'San Francisco, CA'). radius_km 25-50 for a city. If the user names no place, omit all place fields; the map opens at the user's approximate (IP-based) area. When a nearby search runs short, results widen to the rest of the country and then worldwide (search.scope says which: near, country or world), so say where the roles are. ROLE: query holds only the job title text (e.g. 'product manager') and may be omitted for 'any job'. Search Worklittle job listings. People say Worklittle plus a role, city, company, or filters (or just 'jobs') — they will not name this tool. Call it whenever they want Worklittle jobs. Search by keyword, company, location, job type, seniority, or recency. Use for ANY industry (retail, finance, healthcare, tech, etc.). Search matches title and filter text (substring / FTS), not vector embeddings. Role / title text goes in query (+ optional keywords). The API matches job TITLE substrings only for that text — it does not mix company names into the same field. Preserve negative title terms with a leading dash, e.g. 'software engineer, -senior' excludes titles containing senior. Use company for employer slugs (include or exclude). Never concatenate many job titles into one query unless the user supplied comma-separated roles. Do not add seniority_level, stacks, or resume-derived terms unless they asked. Omit seniority_level unless they explicitly name a level as an inclusion filter (never infer from profile). Expand abbreviations only; umbrella phrases use neutral roles and/or company slugs. Umbrella or vague phrases ('big tech', 'FAANG', 'top retailers'): interpret intent, then one search_jobs with comma-separated company slugs and/or a broad role query — prefer one API call over many. company MUST be employer slug(s): bare slugs include (OR), e.g. meta,google,apple. Prefix a slug with '-' to exclude, e.g. -lucid-motors,-tesla. Same leading-dash rule as title negatives, but in company not query. Expand 'no car companies' / 'don't show Lucid' into -slug tokens. Never pass display names as query. If unsure of slug, try lowercase hyphenated brand. Add skills or stack to query/keywords only when the user mentioned them — not from profile by default. When an include company filter returns 0 results, try a broader query (drop include company, use role keywords) before telling the user nothing matched. Pass cursor from a previous response to paginate. Search is anonymous. Do not call get_account, apply, or ask the user to Connect to search or skip. Connect / OAuth is only when they apply. After the map renders, briefly say what was found and where (listed pay shows on each job). For visa / H-1B: set visa_sponsorship to 'yes' (plus optional query). Postings must be explicitly tagged. When visa_sponsorship is set and posted_within_days is omitted, do not apply the default 7-day recency cutoff — tagged visa roles are sparse. For regional / nearby intent: near_lat, near_lng, radius_km (e.g. 50–65). Prefer this over the location substring when coordinates are known. For two or more metros in one user message (e.g. SF or NYC), pass location_or as comma-separated place names — one API request matches ANY listed place. Do not use near_* for multi-metro; use location_or or location with 'or' between cities. Recency: set posted_within_days from the user's words — today/just posted → 1; past few days → 3; this week → 7; past two weeks → 14; this month → 30. Omit when they did not mention timing (defaults to the last 7 days, the map's default). Set 0 only when they want any age / no date limit. Never put today/new/this week into query. Filters are the same as the map's filter chips, and nothing else: posted_within_days (Past 24 hours / 3 / 7 / 14 / 30 days), seniority_level (Experience: intern, entry/new grad, senior, manager, director/executive), employment_type (Type: full-time, part-time, contract), and visa_sponsorship (Visa). Prefer no filters: use one only when the user explicitly asks for it, because each filter shrinks the results a lot. For remote-only jobs send remote: true (and no place fields). There is no salary, hybrid, or benefits filter. If the user asks to filter by salary, search without it and say they can see salaries on the map (listed pay shows on each job).
    ConnectorNo auth
  • Every trading account: broker/prop-firm account id, prop firm, category (evaluation | funded | live), account type, status (active | inactive | unlinked), first and last trade dates and trade count. Users refer to accounts loosely — "the 996", "my Apex funded", "the Lucid eval", "the one ending in 863": resolve against this list by id suffix, prop firm and category; if more than one account fits, ask which one instead of guessing. Ids feed the other tools.
    ConnectorOAuth
  • What a Korean exporter of this product is likely to miss in a market — the unknown unknowns beyond the product category's usual compliance: rules that can stop the sale (e.g. UV filters not allowed in US sunscreen, meat ingredients from countries the EU has not listed), approvals needed before import or sale (radio certification such as FCC, EU RED, Japan's Giteki or Canada's ISED; India BIS; registration of special-use cosmetics in China), extra duties or charges that change the quote (US Section 232 on steel and aluminium content, EU CBAM), and filings or labels (EU deforestation due diligence, producer registration (EPR) for batteries and electronics, and packaging EPR such as Germany's LUCID register in packaging_epr, EU ban on generic green claims), plus Korea-side checks (strategic items, dangerous goods in shipping). Each rule is triggered by the exact HS code or a product trait (pass description or traits) and comes with kind, gate (true = clear it before anything else: the plan's before-you-sell gate), who must act (you or the importer), the date it applies from (upcoming rules too), the official source and the date it was checked; stale marks rules not re-checked for 180 days. The category compliance pointer and its official source are included per market. Each market also says how much TradeGraph knows there (rules_coverage: national, bloc, pointers or none, where none is not a clearance and how_to_check lists where to look); where it has no rule note, rule_pointers gives official-source starting points for blocs and countries such as the EAEU (Kazakhstan, Russia, Belarus, Armenia, Kyrgyzstan), the Andean Community, Mexico, Chile, Argentina, Türkiye, Egypt, Israel, South Africa, Nigeria, Kenya, Pakistan, Bangladesh, New Zealand, Uzbekistan and Mongolia, gate marking what must be met before import or sale. Omit country to check every market in the plan's table. Starting points, not legal advice. Free, read-only.
    ConnectorNo auth
  • Health of the Lucyd service: API and database, settlement of ended markets on time, live trade stream. Use it when something looks stuck, e.g. a market is not resolving.
    ConnectorNo auth
  • Order book of a market outcome: bids (best first) and asks with prices in USDC per token and sizes in tokens, plus best bid, best ask and mid. Buying down at p is the same book as selling up at 1 - p.
    ConnectorNo auth

Matching MCP Servers

Matching MCP Connectors

  • LucidOAuth

    Lucid’s connector creates diagrams, searches, edits, shares, and retrieves docs to summarize.

  • Publish Markdown from any agent: POST Markdown, get a gorgeous shareable URL.

  • Full details of one market, including its rules and the ids of its up and down outcome tokens.
    ConnectorNo auth
  • Profit and loss over time of a wallet, as a series of points. Defaults to the configured wallet.
    ConnectorNo auth
  • Positions of a wallet: tokens held per market and outcome, average price, current value and profit. Settled markets show the payout. Defaults to the configured wallet.
    ConnectorNo auth
  • Stats of a wallet: total and realized profit, volume, markets traded, win rate. Defaults to the configured wallet.
    ConnectorNo auth
  • Recent trades, newest first. Filter by market and/or trader. Amounts are in USDC and tokens.
    ConnectorNo auth
  • List prediction markets on Lucyd. Each market asks whether the BTC price will be Up or Down at its end date versus the strike (strike is the price times 1e8). Returns address (the market id), state, period, start and end dates, strike, winner and volume.
    ConnectorNo auth