Skip to main content
Glama
643,791 tools. Updated 2026-10-06 06:53

"Flask" matching MCP tools:

  • Fetch all player props for one game identified by eventId. Read-only. No side effects. Requires an API key; rate-limited per your tier. Returns: { eventId, sport, homeTeam, awayTeam, startTime, props: Array<{ player, stat, line, overOdds, underOdds, bookCount, gameState?, flashProjection? }>, sources: string[], fetchedAt, delayed, snapshotId, snapshotConsistency }. flashProjection is present when that sport + market has a registered Flash model and a player baseline is available; it is { value, sampleN, method, marketKey, basis, seasonId, basisNote } and is never fabricated. basis prior_season means a prior-season baseline, never current form. overOdds and underOdds are American-format integers (e.g. -110, +115); null when odds are not available. The stats parameter filters to specific markets (e.g. "points,rebounds" for basketball, "strikeouts,hits_allowed" for MLB). Typical workflow: (1) call list_games to get eventIds, (2) call get_game_props with the eventId. Alternatively, call find_game with team names to resolve the eventId when you know the matchup. Event ids are prefixed ud- (Underdog Fantasy source) or sc- (soccer odds board). Returns an error when the event id is not found, the game has ended with no active props, or lines have not been posted yet. When to use: when you have an eventId and want all props for that specific game. When not to use: use scan_props instead when you want a cross-game market view. Use find_player_props when you know the player name but not which game they are in.
    ConnectorNo auth
  • Use this when the user asks to permanently delete a whole deck, every subdeck under it and all their cards. The first call deletes nothing and returns decks_affected, the affected card IDs and count, and a confirm_token: name every affected deck, ask once, then repeat the same deck with the token. Tokens last ten minutes across reconnects; a changed card or subdeck needs a fresh confirmation. To keep the cards but stop studying them, use archive_deck.
    Connector
    Destructive
    OAuth
  • Use this when the user asks to delete specific cards. Takes 1-500 card IDs (from list_cards) with one confirmation for the batch: the first call deletes nothing and returns the exact set and a confirm_token; ask the user once, then repeat the same card_ids with confirm_token. Tokens last ten minutes and survive reconnects; a completed retry returns its original result. For a whole deck use delete_deck; to stop studying a deck but keep it, archive_deck.
    Connector
    Destructive
    OAuth
  • Every active prop for one player across today's board for a sport; same rows as scan_props, filtered by name (exact normalized match preferred, case-insensitive contains match as a fallback; see matchType in the response) instead of stat. Read-only. No side effects. Requires an API key. When to use: you know the player but not which game or event they are in, and you want their posted lines. When not to use: get_prop_evidence explains ONE prop with its line, gap and form; get_player_context gives season baselines and recent form but no posted lines; scan_props is the whole board.
    ConnectorNo auth
  • Monta uma REDE MULTIBARRA (concessionária → transformadores → cabos → quadros) e calcula o curto-circuito IEC 60909 em TODAS as barras de uma vez, pelo mesmo motor validado da plataforma (redução nodal do Anexo B: aceita alimentação radial, em paralelo e malha). Use quando o usuário tem os dados de VÁRIOS equipamentos — típico de quem acabou de ler um datasheet, uma carta da concessionária ou um memorial antigo — em vez de chamar `calcular_curto_circuito` (que é de UM ponto) várias vezes. Devolve também `projeto_json`: o arquivo de projeto da plataforma com a rede inteira. Entregue esse conteúdo ao usuário para salvar como `.json` e abrir em "Abrir projeto" no app — a rede aparece nas tabelas para ele CONFERIR e seguir para coordenograma, arco elétrico e memorial. Nenhum valor extraído de documento deve virar laudo sem essa conferência humana. ── barras: lista de objetos ──────────────────────────────────────────────── {"id": "SE_BT", "label": "Subestação 480 V", "Vn_kV": 0.48} `id` é o identificador único (sem espaços é mais seguro); `Vn_kV` é a tensão NOMINAL da barra em kV (0,48 = 480 V). A barra de conexão com a concessionária é a que NÃO recebe nenhum elemento (nenhum `to_id` aponta para ela) — é ela a raiz da rede. ── elementos: lista de objetos (o que liga uma barra à outra) ────────────── element_type "transformer": {"from_id","to_id","element_type":"transformer", "Sn_kVA":1000,"Vcc_pct":5.0,"Pcu_W":10000,"XR_trafo":null,"Rn_ohm":null} Sn e Vcc são de PLAQUETA e obrigatórios (>0). `Pcu_W` = perdas no cobre; `XR_trafo` (opcional) sobrepõe o X/R estimado por Pcu. Modelado como Dyn (delta na alta, estrela na baixa). `Rn_ohm` = resistor de aterramento do NEUTRO de baixa (NGR), em Ω: ausente = neutro SÓLIDO, e a resposta avisa que foi assumido. Com NGR a fase-terra cai em ordem de grandeza — SEMPRE informe quando a instalação tiver. `tipo_aterramento` (opcional) aceita 'solido' ou 'resistivo' (este exige Rn_ohm), como no `calcular_curto_circuito`; 'isolado' é RECUSADO aqui (neutro isolado não é modelado na rede multibarra). O aterramento é do TRANSFORMADOR, nunca da `fonte`. element_type "cable" (ou "busbar"): {"from_id","to_id","element_type":"cable", "secao_mm2":95,"material":"Cu","comprimento_m":40,"num_conductors":1} Liga barras de MESMA tensão (para mudar de tensão use "transformer"). element_type "reactor": {"from_id","to_id","element_type":"reactor", "u_kR_pct":6,"I_rR_A":400} (reator limitador, §6.5 — u_kR e I_rR de plaqueta) ── fonte: a contribuição da concessionária ──────────────────────────────── {"Vn_kV":13.8, "Scc_MVA":500, "XR":10, "Icc_1ph_kA":0, "XR_1ph":0} Informe `Scc_MVA` OU `Icc_kA` (não os dois). `Vn_kV` é a tensão do ponto de conexão. §7.1.2 d): use a contribuição MÁXIMA declarada pela concessionária, não a de hoje — dimensionar pelo valor de hoje subdimensiona o equipamento quando a rede reforça. `Icc_1ph_kA`/`XR_1ph` são opcionais (0 = estimar Z0). ── motores (opcional): contribuição de motores por barra ────────────────── {"bus_id":"QD-01","P_kW":75,"n_motores":4,"cos_phi":0.85,"rendimento":0.92, "Xd_sub_pu":0.17} Erro de FORMA (campo faltando, valor não-numérico) e erro de FÍSICA (tensões que não casam num cabo, trafo sem Sn/Vcc, duas alimentações para a mesma barra) voltam em {"erro": ...} explicando o que corrigir — nada é calculado "pela metade". Gratuito (uso limitado).
    ConnectorNo auth
  • Monta uma REDE MULTIBARRA (concessionária → transformadores → cabos → quadros) e calcula o curto-circuito IEC 60909 em TODAS as barras de uma vez, pelo mesmo motor validado da plataforma (redução nodal do Anexo B: aceita alimentação radial, em paralelo e malha). Use quando o usuário tem os dados de VÁRIOS equipamentos — típico de quem acabou de ler um datasheet, uma carta da concessionária ou um memorial antigo — em vez de chamar `calcular_curto_circuito` (que é de UM ponto) várias vezes. Devolve também `projeto_json`: o arquivo de projeto da plataforma com a rede inteira. Entregue esse conteúdo ao usuário para salvar como `.json` e abrir em "Abrir projeto" no app — a rede aparece nas tabelas para ele CONFERIR e seguir para coordenograma, arco elétrico e memorial. Nenhum valor extraído de documento deve virar laudo sem essa conferência humana. ── barras: lista de objetos ──────────────────────────────────────────────── {"id": "SE_BT", "label": "Subestação 480 V", "Vn_kV": 0.48} `id` é o identificador único (sem espaços é mais seguro); `Vn_kV` é a tensão NOMINAL da barra em kV (0,48 = 480 V). A barra de conexão com a concessionária é a que NÃO recebe nenhum elemento (nenhum `to_id` aponta para ela) — é ela a raiz da rede. ── elementos: lista de objetos (o que liga uma barra à outra) ────────────── element_type "transformer": {"from_id","to_id","element_type":"transformer", "Sn_kVA":1000,"Vcc_pct":5.0,"Pcu_W":10000,"XR_trafo":null,"Rn_ohm":null} Sn e Vcc são de PLAQUETA e obrigatórios (>0). `Pcu_W` = perdas no cobre; `XR_trafo` (opcional) sobrepõe o X/R estimado por Pcu. Modelado como Dyn (delta na alta, estrela na baixa). `Rn_ohm` = resistor de aterramento do NEUTRO de baixa (NGR), em Ω: ausente = neutro SÓLIDO, e a resposta avisa que foi assumido. Com NGR a fase-terra cai em ordem de grandeza — SEMPRE informe quando a instalação tiver. `tipo_aterramento` (opcional) aceita 'solido' ou 'resistivo' (este exige Rn_ohm), como no `calcular_curto_circuito`; 'isolado' é RECUSADO aqui (neutro isolado não é modelado na rede multibarra). O aterramento é do TRANSFORMADOR, nunca da `fonte`. element_type "cable" (ou "busbar"): {"from_id","to_id","element_type":"cable", "secao_mm2":95,"material":"Cu","comprimento_m":40,"num_conductors":1} Liga barras de MESMA tensão (para mudar de tensão use "transformer"). element_type "reactor": {"from_id","to_id","element_type":"reactor", "u_kR_pct":6,"I_rR_A":400} (reator limitador, §6.5 — u_kR e I_rR de plaqueta) ── fonte: a contribuição da concessionária ──────────────────────────────── {"Vn_kV":13.8, "Scc_MVA":500, "XR":10, "Icc_1ph_kA":0, "XR_1ph":0} Informe `Scc_MVA` OU `Icc_kA` (não os dois). `Vn_kV` é a tensão do ponto de conexão. §7.1.2 d): use a contribuição MÁXIMA declarada pela concessionária, não a de hoje — dimensionar pelo valor de hoje subdimensiona o equipamento quando a rede reforça. `Icc_1ph_kA`/`XR_1ph` são opcionais (0 = estimar Z0). ── motores (opcional): contribuição de motores por barra ────────────────── {"bus_id":"QD-01","P_kW":75,"n_motores":4,"cos_phi":0.85,"rendimento":0.92, "Xd_sub_pu":0.17} Erro de FORMA (campo faltando, valor não-numérico) e erro de FÍSICA (tensões que não casam num cabo, trafo sem Sn/Vcc, duas alimentações para a mesma barra) voltam em {"erro": ...} explicando o que corrigir — nada é calculado "pela metade". Gratuito (uso limitado).
    ConnectorNo auth

Matching MCP Servers

  • F
    license
    Not graded
    quality
    A
    maintenance
    Provides a collection of MCP servers for computational chemistry tasks including molecular generation and retrosynthesis. Also offers property prediction and molecule pricing capabilities.
    -

Matching MCP Connectors

  • flaskOAuth

    Feedback layer for video. Reviewers talk through feedback; agents read it as structured comments.

  • FlashOAuth

    Spaced-repetition flashcards your AI writes, quizzes you on by voice, and schedules with FSRS.

  • Use this when the user wants flashcards: made from notes, slides or a file they share, a topic they name, or this conversation, or to memorize something and review it later. Saves 1-500 cards into one deck of their Flash account (created if missing, with parents for Parent::Child), where spaced repetition schedules each card's reviews. Follow the field notes; cloze uses {{c1::answer}}; keep media as /media/{id}. To change existing cards use update_cards, not new copies.
    ConnectorOAuth
  • Use this when the user wants to see, find or check their cards, and before update_cards or delete_cards. Returns whole cards and editable sources, newest first, by deck or search text, with authenticated media URLs (GET with the connector Bearer token; never speak URLs or markup). Sources show cloze answers, so quiz with start_study_session. Edits to a shared source reach its sibling_card_ids. Page with next_cursor as before_card_id while has_more; trust has_more, not the count.
    ConnectorOAuth
  • Use this when the user asks to fix, reword, correct or retag cards they already have. Changes 1-500 cards atomically: give card_id and only the fields to change (front_html, back_html, tags); the rest stay, cards keep their schedule and review history, and restore_cards can undo the edit. Read list_cards first; for a shared source copy its sibling_card_ids, one edit per source. The note type stays; an edit that would remove cards is refused (use delete_cards). Follow create_cards' field notes.
    ConnectorOAuth
  • Use this when the user wants an earlier version of a card back, for example after an edit they did not want. Every edit keeps the text it replaced. Give card_id alone to list the card's earlier versions, newest first, and confirm with the user which one; then call again with its revision_id. A restore rewrites the card's source and its sibling cards in place, keeping their schedules and review history, and keeps the text it replaces too. A restore that would remove cards is refused.
    ConnectorOAuth
  • Return today's games that have player props available for a sport. Read-only. No side effects. Requires an API key; rate-limited per your tier. Returns: { sport, count, games: Array<{ id, sport, homeTeam, awayTeam, startTime, live, source }> }. id is the eventId to pass to get_game_props (prefixed ud- for Underdog or sc- for the soccer odds board); live is true when the game is in progress; source is "underdog" or "theoddsapi". Live games sort first; scheduled games follow. Typical workflow: call list_games to discover eventIds, then pass an eventId to get_game_props. If sport is omitted the server selects the active in-season league automatically. Returns count=0 with an empty games array (not an error) when no props are posted yet for the day. When to use: to browse all games on the slate or to find an eventId before calling get_game_props. When not to use: if you already have the eventId, skip this and call get_game_props directly. Use find_game instead when you know the team names but want a single-game eventId without browsing the full slate.
    ConnectorNo auth
  • Translate a matchup (home team + away team) into the eventId needed by get_game_props. Read-only. No side effects. Requires an API key; rate-limited per your tier. Use this when you know the teams playing but don't have the eventId. On success returns: { eventId }. Pass that id straight to get_game_props. On failure returns an error explaining that the game was not found on today's board. If multiple games match the team names (rare), returns the first match sorted by start time. Matching is case-insensitive substring containment against the full team name. When not to use: use list_games to browse a slate, or get_game_props directly if you already have the eventId.
    ConnectorNo auth
  • Deploy an application to sota.io. The platform auto-detects your framework and builds a Docker image automatically: - Next.js: Detected via next.config.js/ts. Add output: 'standalone' to next.config for optimal builds. - Node.js: Detected via package.json with a "start" script. Works with Express, Fastify, Koa, Hapi, etc. - Python: Detected via requirements.txt or pyproject.toml. Works with Flask, FastAPI, Django. - Custom Dockerfile: If a Dockerfile exists in the project root, it takes priority over auto-detection. Use this for Go, Rust, Java, or any other language. The EXPOSE directive in the Dockerfile is used to detect the app port automatically. THREE WAYS to supply the source code — pick EXACTLY ONE: 1. **files** (inline source from AI): Pass a map of relative paths to UTF-8 text content. Best when you've just generated a small app in this conversation and want to deploy it without any filesystem step. Up to 200 files, 10 MB total. Include the framework manifest (package.json, requirements.txt, or Dockerfile) so auto-detection works. 2. **git_url** (clone a public repo): Pass an https://, git://, ssh://, or git@host:path URL. We shallow-clone it (--depth=1 --single-branch) on the server and deploy. Optional git_branch picks a non-default branch. Only public repos are supported in v1. Max 200 MB after clone. 3. **directory** (local filesystem): Pass an absolute path. Only works when the MCP client has filesystem access (Claude Code / CLI; not Claude.ai web). Defaults to the current working directory when omitted. IMPORTANT: Your app MUST listen on the PORT environment variable. For auto-detected frameworks (Next.js, Node.js, Python) PORT is 8080. For custom Dockerfiles, the port is auto-detected from the EXPOSE directive (e.g. EXPOSE 3000 sets PORT=3000). If no EXPOSE is found, it defaults to 8080. Every project includes a managed PostgreSQL 17 database. Six environment variables are auto-injected into your container — no manual database configuration needed: DATABASE_URL (full connection string), PGHOST, PGPORT, PGUSER, PGPASSWORD, and PGDATABASE. Libraries that follow libpq conventions (node-postgres, pgx, psycopg2, Django) pick up the PG* variables automatically with no configuration. If your app needs database migrations, run them on startup. Deployments use blue-green strategy for zero downtime. The old container keeps running until the new one passes health checks (60s timeout). Use get-logs to monitor build progress. Files matching .gitignore, .git/, node_modules/, .env, and .DS_Store are excluded from the archive.
    Connector
    Destructive
    No auth
  • Use this when the user wants more new cards today than the daily limit allows ('give me 10 more new cards today'). Adds extra new cards for today only: to one deck, or without a deck to the account-wide allowance. Each call adds more, up to 500, and returns the total extra granted today. To change the limit for every day, use set_limits.
    ConnectorOAuth
  • Use this when the user asks how many new cards or reviews they get per day, or why a session stopped while cards remain. Shows today's study limits: the account defaults (new cards per day, max reviews per day, any extra new cards granted today) and every deck's override (null = inherits) with how many new and due cards it can still serve today.
    ConnectorOAuth
  • Use this when the user asks what flashcard decks they have or what is due, or before choosing a deck to study or add cards to. Lists every deck with its due and new card counts. A name is a path: Parent::Child is a subdeck of Parent, and each deck is followed by its subdecks. A deck's counts already include its subdecks, so never add rows up. An archived deck keeps its place, with archived: true and zero counts.
    ConnectorOAuth
  • Use this when the user is done with a deck (an exam passed) but wants to keep it. Every card, its media and its review history stay, but the deck and its subdecks leave the study queue and the due counts, and start_study_session on it finds nothing. Nothing is deleted, so no confirmation is needed; unarchive_deck reverses it. Cards can still be added to an archived deck by name.
    ConnectorOAuth
  • Use this when the user asks to rename a deck, nest it under another, or pull it out to the top level. new_name is the full path: Pharm::Cardio moves Cardio into Pharm (created if missing). Its subdecks, cards and review history follow. Refused if a deck already has that name (decks are never merged) or the target is inside the deck itself.
    ConnectorOAuth
  • List every sport supported by Flash Props API with its live status and how deep the Flash model goes. Read-only. No side effects. Rate-limited per your tier. Returns { sports: Array<{ id, name, category, enabled, status, activeGames, activeProps, projectedProps, projectionCapability, effectiveProjection, contextCapability, marketFamilies, supportedMarkets, sources, lastFetchedAt, cacheAgeSeconds, shapeCanaryTripped, legalLine, notes, dataStatus, dataReason, projectableMarkets, projectionBasis, coverage, snapshotId, event, season }> }. id is what you pass as the sport parameter to other tools. status: "live" = props posted now, "idle" = none posted now but lines were archived recently, "offseason" = no lines archived for an extended period (observed, never a calendar). snapshotId identifies the exact board the counts describe. projectionCapability is the structural model ceiling; effectiveProjection tempers that by what is actually posted right now. contextCapability "deep" means a registered Flash pack can serve player context; "none" means it cannot. Call this tool instead of hard-coding which sports are modeled. enabled=false means the sport is outside your tier. When to use: to discover valid sport ids, or to check which sport actually has projections/context before asking for them. When not to use: if you already know the sport id and just want its props.
    ConnectorNo auth
  • Return the machine-readable stat vocabulary for a sport: for each live market, its label, family, scope (map1/maps13/full_game), unit, display order, and whether a Flash projection is supported (with a reason when not). Read-only. No side effects. Rate-limited per your tier. Returns { sport, count, markets: Array<{ statKey, label, family, scopeKind, scope, scopeLabel, unit, displayOrder, uiGroup, projection: { supported, reason }, contextSupported, lineOnly, alternateLine }> }. This is what turns a raw stat key like "kills_on_game_1" into a labeled, scoped market so you can group props without guessing. Projection support is provider-driven per market, so partially modeled sports stay honest. When to use: after scan_props / get_game_props, to explain or group the raw stat keys you got back. When not to use: if you only need one sport's existence/access, list_sports already carries marketFamilies.
    ConnectorNo auth
  • Flatten every active player prop across all of today's games for a sport into a single list. Read-only. No side effects. Requires an API key; rate-limited and row-capped per your tier (Free 15 rows, Builder 100, Pro 3,000, Enterprise 5,000). Returns: { sport, stat, count, rows: Array<{ player, stat, line, overOdds, underOdds, bookCount, gameState?, flashProjection?, eventId, sport, homeTeam, awayTeam, startTime, source, fetchedAt }>, snapshotId, snapshotConsistency }. Each row is a player prop merged with its event context; use homeTeam/awayTeam for matchup context. overOdds/underOdds are American-format integers; null when odds unavailable. Use scan_props when you need a broad cross-game market view. Returns count=0 with an empty rows array (not an error) when no props are posted for the day yet. When not to use: use get_game_props when you already have an eventId; use find_player_props for one player.
    ConnectorNo auth