EnskAI

The club's current squad — age, position, market value, contract, agent. Each player carries `in_my_organization`, so you can tell at a glance who is already on the books. `player_id` is the numeric Wyscout id: pass it to player_statistics or lookup_wyscout, NOT to tools that expect the org record UUID.

enskai_get_club_squad

The club's league table for the latest season it has standings for. Returns every row of the division (so you can say where the club sits and what is around it) plus `has_knockouts` — when true, the competition also has a playoff/knockout phase you can read with get_club_knockout.

enskai_get_club_standings

List the valid categorical values for a resource's search filters. Call this before a search_* when you need exact values (positions, stages, contract types, tags, statuses, …) rather than guessing them. For finances, pass resource="revenue" or "expense".

enskai_get_filter_options

Fetch one record of any resource by its id, with full detail. The compact summaries from search_* tools omit most fields; use this to get the complete record (all type-specific contract terms, the full activity, every report field, etc.). For finances, pass resource="revenue" or "expense". Returns 404 guidance if the id is wrong or not visible to you.

enskai_get_record

List the stages this organization actually uses, in board order. Stages are configured per organization — an org can rename the defaults, add its own (e.g. "Deadline Day") and retire ones it no longer uses — so this is the only reliable source of which stages exist. Call it before telling a user a stage does not exist, and to find the right name when moving an activity. Each stage has its `name` (what to pass as `stage`), `id` (pass as `stage_id` when names are ambiguous), `pipeline`, board `position`, and `is_default` — the stage a new activity lands in when none is given. Retired stages are excluded: they remain on old activities as history but are not valid destinations.

enskai_list_activity_stages

Resolve a match to its matchId, for tying a scouting report to a fixture. Pass `player_id` to list that player's matches, or `query` to search by a match label. Returns the raw candidate list — use the right entry's matchId on manage_scouting_report.

enskai_lookup_matches

Resolve an org user or staff member by name to their id. Use the returned `id` for assigned_to_record (assignment), staff_id (contract parties), or sharing. A staff member also carries `transfermarkt_staff_id` — the external catalogue's id, which is what market tools such as find_opportunities search on. They are different ids for the same person; don't substitute one for the other. Returns {items, total}. The lists are small, so this filters client-side by `search` rather than paging.

enskai_lookup_org_members

List a club's key staff (head coach, sporting director, etc.) from the catalogue. Resolves a club's Wyscout `team_id` to its current staff in the Transfermarkt catalogue — head_coach, assistant_coach, sporting_director, coaching_staff, club_executives, scouting — each with their role, tenure (appointed / in_charge_until) and league/country. This is the ONLY tool that answers "who is the coach/SD at club X"; do not infer or state a person's club or role from anything else. Returns `{team_id, staff: [...]}`. An empty `staff` list means the catalogue has no current staff on record for that club — say so plainly rather than guessing a name. Resolve the club first with lookup_wyscout(kind="team").

enskai_lookup_staff_by_team

Resolve an external entity by name to its Wyscout id, to onboard/reference it. Use this before creating something that references an entity not yet in the org: the player to onboard (manage_player source="wyscout"), the club on a team request or activity, an agency, or a staff member. Returns the raw candidate list from the catalog — pick the right one and use its numeric id (e.g. as wyscout_player_id / team_id). For records already in the org, prefer search_players / search_contacts instead.

enskai_lookup_wyscout

The caller's saved groups of contacts, with their email addresses. These are the named groups the platform offers when notifying people — "my Scandinavian clubs", "Bundesliga SDs". Use this to turn a group the user names in words into the addresses another tool needs: the emails here go straight into manage_team_request(notify_emails=...), which is the same path the website's notify picker uses. Lists are personal to the caller, not shared across the organization, and one is marked `is_default`. Members with no email address are returned but cannot be notified — say so rather than dropping them silently. Reading and composing only: sending a campaign is done in the platform.

enskai_mailing_lists

Update many activities in one call — bulk op="update". Use this instead of many sequential manage_activity calls, e.g. to advance a batch of deals to a new stage. `stage` accepts the org's own configured stage names (see list_activity_stages); resolve the name once before the call rather than per record. Each record is applied independently, so one failure never blocks the rest. Returns `succeeded`/`failed` counts and a `results` array with, per record, `ok=true` and the saved record or `ok=false` and an actionable error. Only updates are supported; create with manage_activity.

enskai_manage_activities_bulk

Create or update an activity — a deal or a task (the backend enforces role). CREATE needs `type` (deal|task) and `title`. Set `player_id` and/or `team_id` to tie it to a player/team. Use `due_date` for tasks and `next_action` for deals — a date with no time falls due at 09:00 in the user's timezone, so pass a time only when they named one. `player_id` can only be set at create time. Set `parent_activity_id` to make a task a subtask of another task, and `priority` (low|medium|high) on either. UPDATE needs `activity_id`; pass only the fields you want to change (type cannot change). Omitted fields are left untouched. `stage` is a free-text name resolved against this organization's own stages, which it can rename and add to — use list_activity_stages rather than assuming which stages exist. On create, omitting it lands the activity in the org's default stage. Returns the saved activity. A 403 means the caller's role can't write it; a 422 means a value was rejected — fix it and retry. A 400 naming a stage means that stage isn't in the org's pipeline (or is retired) — read the live list and pick one that is.

enskai_manage_activity

Create or update a contact (a person: club staff, agent, rep). CREATE has no strictly-required field, but a contact is only useful with a name — pass at least `first_name`/`last_name`. For a STAFF contact, link the club with `team_id` (Wyscout) and/or `staff_id` (Transfermarkt) rather than a free-text `organization`: the backend derives the club name from the link and blanks the free-text field for staff. Resolve both ids with lookup_wyscout (for a coach, its staff_id equals the Transfermarkt trainer id). UPDATE needs `contact_id`; pass only the fields you want to change. Omitted fields are left untouched. Note: changing `category` makes the backend clear the now-irrelevant club/agency link. Returns the saved contact. A 403 means the caller's role can't write it; a 422 means a value was rejected — fix it and retry.

enskai_manage_contact

Create or update a contract (needs the legal module; backend enforces role). Contracts are polymorphic and have many type-specific fields. This tool types the common core (parties, dates, currency, salaries, headline fees, commission) and accepts an `extra` dict for anything else — use the backend's exact field names there. CREATE needs `contract_type` and `active_status`. UPDATE needs `contract_id` and replaces the contract with the fields you send, so fetch it first with get_contract, then resend the full set you want kept plus your changes. Returns the saved contract. A 403 means the legal module is disabled or the role can't write it; a 422 means a value was rejected — fix it and retry.

enskai_manage_contract

Create or update a revenue or expense item (needs the legal module). CREATE needs `kind` and `amount`. UPDATE needs `kind` and `finance_id`; pass only the fields you want to change. The invoiced lifecycle (`invoiced`, `invoiced_at`) and `player_clause_id` apply to revenue only and are dropped for expenses. Returns the saved item. A 403 means the legal module is disabled or the role can't write it; a 422 means a value was rejected — fix it and retry.

enskai_manage_finance

Create or update a player record (the backend enforces the caller's role). CREATE onboards from a catalogue id — there is no manual entry. Pass `wyscout_player_id` (resolve a name with lookup_wyscout) and/or `tm_player_id` (the number in a Transfermarkt link); both go to the SAME endpoint and the backend builds the full record from it. Any enrichment fields you also pass (control_stage, transfer_strategy, quality, potential, prices, salaries, description, video_link, tags, assignments, associations) are applied automatically right after, so a scouted player is onboarded complete in ONE call. (If the created record can't be resolved to apply them, the result carries pending_enrichment=true so you follow up with op="update".) If a Transfermarkt id can't be resolved (its data isn't in the catalogue yet), resolve the player's NAME with lookup_wyscout and onboard with that `wyscout_player_id` instead. UPDATE needs BOTH `player_record_id` (the UUID, picks the record) AND `wyscout_player_id` (the numeric id, required in the body). Pass only the fields you want to change; omitted fields are left untouched. Quality and potential use a -1..13 scale: -1 means not yet rated (shown as "Pending review" — NOT a low score, and distinct from 1), 1-12 are the letter grades D- through A+, and 13 marks a youth player too young for the senior scale. Send the number; responses render the label. Returns the saved player record. A 403 means the caller's role can't write this record; a 422 means a value was rejected — fix it and retry.

enskai_manage_player

Update many player records in one call — bulk op="update". Use this instead of many sequential manage_player calls when enriching or remediating lots of players (e.g. after a Wyscout import or a hygiene audit). Each record is applied independently, so a bad value in one never blocks the others. Every item needs `player_record_id` and `wyscout_player_id`; include only the fields you want to change. Returns `succeeded`/`failed` counts and a `results` array carrying, per record, `ok=true` with the saved record or `ok=false` with an actionable error — retry just the failed ones. Only updates are supported here. Create players with manage_player (a Wyscout create can enrich in the same call).

enskai_manage_players_bulk

Offer a player to a club request, or remind colleagues about a deal. `propose_player` is the proper way to put a player forward: it records the proposal, opens the deal in the org's default stage and notifies — all of which a hand-made manage_activity call would miss. Both records must belong to the caller's organization. Resolve the player with search_players and the request with search_team_requests first, and name both in the confirmation so the user can catch a wrong match. `nudge` sends a push to the named people about the named deals — one per (deal, recipient). Use it when the user asks to chase someone, typically straight after work_queue surfaces a stale deal.

enskai_manage_proposal_or_nudge

Create or update a scouting report (needs the scouting_reports module). CREATE needs `player_id` (the record UUID from search_players). Tie it to a match with `match_id` (from lookup_matches) OR the manual_* fields when the match isn't in the system. Quality and potential use a -1..13 scale: -1 means not yet rated (shown as "Pending review" — NOT a low score, and distinct from 1), 1-12 are the letter grades D- through A+, and 13 marks a youth player too young for the senior scale. Send the number; responses render the label. If you leave them unrated, don't imply you scored the player. UPDATE needs `report_id`; pass only the fields you want to change. Omitted fields are left untouched. Returns the saved report. A 403 means the module is disabled or the role can't write it; a 422 means a value was rejected — fix it and retry.

enskai_manage_scouting_report

Update many scouting reports in one call — bulk op="update". Use this instead of many sequential manage_scouting_report calls. Each record is applied independently, so one failure never blocks the rest. Returns `succeeded`/`failed` counts and a `results` array with, per record, `ok=true` and the saved record or `ok=false` and an actionable error. Only updates are supported; create with manage_scouting_report.

enskai_manage_scouting_reports_bulk

Add a free-text note to a club — the club-level "Notes" tab. This is where club knowledge that isn't about a single player or deal belongs: a meeting with a sporting director, what a club is looking for, an ownership or budget change. Do NOT create a deal or attach such notes to a person's contact record for this — a club note is the right home. The note is scoped to the caller's organization and attributed to them. Returns the created note.

enskai_manage_team_note

Create or update a team request — a club's brief for one position. CREATE needs `team_id`, `position` and `type`. **One position per request**: if a club wants multiple positions, call this once per position (copy the club-level budget/window/contact to each). UPDATE needs `team_request_id`; pass only the fields you want to change. Omitted fields are left untouched. The request is saved SILENTLY unless you pass `notify_emails`. The website offers a "notify" tick that emails the brief to chosen people plus everyone assigned to that club; this is the same thing. Don't send unprompted — but when a club has colleagues covering it, it is worth asking whether to tell them, since they would have been emailed had the request been logged on the website. search_clubs(team_id) shows who covers a club. Returns the saved team request. A 403 means the caller's role can't write it; a 422 means a value was rejected — fix it and retry.

enskai_manage_team_request

Most suitable players for a team request (request → players). Returns the top `limit` players ranked by suitability for this brief, each with a 0–5 `suitability_rating`, price/salary, age, contract runway and pipeline stage — plus `total`, the full count of suitable players, so you can report "showing N of `total`". Pass a player's `id` to get_record(resource="players") for full detail. The brief's hard constraints are applied automatically: this tool reads the request's own max_age, max_value, max_net_salary and eu_passport and filters by them (age is a hard cap; the money caps get the platform's 20% negotiation tolerance), so the result matches the web view instead of an unfiltered, wrongly-ranked pool. The constraints actually applied are echoed back in `applied_constraints`. To override, pass any of `age_max`, `club_asking_price_max`, `max_net_salary`, `eu_passport` explicitly — an explicit value (including a deliberately loose one) wins over the auto-filled one. Every filter is null-safe — a player missing that datum is kept, not hidden. Scores are computed live from current ratings, so a request matches as soon as it exists — no evaluation step. A 404 means the request id is wrong or not visible to you — resolve it with search_team_requests first. Empty results are normal when no player in your organization plays the requested position for that window (or the clubs involved sit in a competition without rating coverage).

enskai_match_players_for_request

Most suitable team requests for a player (player → requests). Returns the open briefs this player fits best, split into two buckets: `private` (your own organization's requests) and `community` (shared requests from other agencies). Each bucket has the top `limit` requests ranked by suitability — club, position, window, deal type, budget and a 0–5 `suitability_rating` — plus its `total`. Pass a request's `id` to get_record(resource="team_requests") for full detail. The suitability score ranks on playing-level fit; it does NOT by itself enforce a brief's hard requirements, so pass `respect_constraints=true` to drop briefs this player is ineligible for (too old, non-EU when required, over the brief's budget or wage ceiling). A 404 means the player-record id is wrong or not visible — resolve it with search_players first. Empty results are normal when there are no open briefs for the player's position in the current window (or the player's club sits in a competition without rating coverage).

enskai_match_requests_for_player

A player's career: club moves with fees, club totals, and senior caps. Answers "give me his career path", "what did he cost", "how many caps has he got". Returns `transfers` (each with from/to club, date, type and fee), `club_totals` (appearances, starts, goals, cards across his career) and `international` (national team, caps, goals, minutes) — fetched together because these are almost always wanted together. For form over a recent period use player_statistics instead; this is the whole career. A transfer with an implausible date or a missing fee is a gap in the source data — report it as unknown rather than inferring one.

enskai_player_career

A player's injury record — what, when, how long, matches missed. Use this for "is he fit?", "which of my players are injured?" and injury history. Never answer an injury question from general knowledge: this is the record the platform shows, and guessing has previously understated a lay-off by weeks. Each row has the injury, the dates, its duration, `games_missed` and `active_injury` (true = still out). Set `current_only` for just the live ones. An empty list means no recorded injuries — say that, rather than that he is fit.

enskai_player_injuries

Aggregated match statistics for a player over a time frame. Use this to answer performance questions — "how did he do last season?", "how many goals since the start of the year?", minutes played, starts vs substitute appearances, assists, cards — for ANY player in the Wyscout database. Returns period `totals` plus a `by_competition` breakdown (matches, starts, sub_appearances, minutes, goals, assists, goal_contributions, yellow/red cards). Friendlies are excluded; continental cups (Champions League, Libertadores, …) are included. Resolve the player's numeric `player_id` with lookup_wyscout(kind= "player") FIRST — not search_players, which only covers players onboarded in your org. Because this reads the global Wyscout data it works for any player regardless of org, so prefer it over general knowledge for real match numbers. For all-time totals use period="career" (or career_summary); for individual games use lookup_matches. The response echoes the resolved window in `period`; check `period.resolved_from` to see how a fuzzy season was pinned (e.g. "Serie A 2024/2025").

enskai_player_statistics

Read the comments on a player, activity, staff, contact, contract or finance item. The mirror of add_comment: use it to see a record's existing notes — for example before adding one, so you don't write a duplicate, or to answer a question about what has been noted. Returns the comments (each with text, creator and time). The target must be visible to the caller; contract/finance comments also need the legal module (otherwise 403).

enskai_read_comments

List the organization's free-text notes on a club (its "Notes" tab). Use it to see what's already recorded about a club — and to check for an existing note before adding one, so you don't duplicate. Returns each note with its text, creator and time.

enskai_read_team_notes

List all scouting reports written about a given player record.

enskai_reports_for_player

Search the organization's activities (deals and tasks). Returns a compact, paginated list — each item has the activity id (UUID), title, type, stage, the player/team/staff it relates to, and dates; pass the id to get_record(resource="activities", id) for full detail. Filter by player_id / team_id to get one player's or team's activities, or by team_country / team_league to answer questions like "how many active deals with German clubs" in one query (no need to resolve each club). Combine filters freely — they AND together. Scoped to the caller's organization, role and visibility. When has_more is true, call again with offset set to next_offset. For a "how many" question read the `total` field (the full match count) — never count `items`, which is only the current page.

enskai_search_activities

Search the clubs the organization can see, with its own data attached. This is the club equivalent of search_players: one call answers "which clubs…" questions. Each row carries the club's identity (name, country, league, division) plus the organization's own context — the tags on it, the colleagues assigned to cover it, whether it's a favourite — and live counts of open requests, open deals, signed players, mandate players and players with a contract expiring inside 12 months. Use `assigned_to` to answer "which clubs does <person> cover?" — pass their platform user id (from lookup_org_members), not their name. Returns `{items, total, offset, limit, has_more, next_offset}`. Use `total` when asked how many, never the number of rows shown.

enskai_search_clubs

Search the organization's contacts (people: staff, agents, reps). Returns a compact, paginated list — each item has the contact id (UUID), name, type/category, organization and reachability; pass the id to get_record(resource="contacts", id) for full detail, or use the UUID as associated_with_record / agent_id on writes. Scoped to the caller's organization, role and visibility. When has_more is true, call again with offset set to next_offset. Filter by country, organization (club/company) or area_league ("League|Area", e.g. "Premier League|England" — use this for "contacts at Premier League clubs"). For a "how many" question read the `total` field (the full match count) — never count `items`, which is only the current page.

enskai_search_contacts

Search the organization's contracts (all types). Use this for questions like "which contracts expire in the next 3 months", "show this club's contracts", or "find this player's mandate". Returns a compact, paginated list — each item has the contract id (UUID), type, the player/team/agent it involves, active status, dates and gross salary; pass the id to get_record(resource="contracts", id) for full type-specific detail. Filter by player_id to get one player's contracts. Requires the `legal` module; scoped to the caller's organization, role and visibility. When has_more is true, call again with offset set to next_offset. contract_type is a constrained enum (valid values are in the schema — no pre-flight needed). Note: `agent` / `agent_id` is the contract's agent; `notify` is a separate list of people cc'd on reminders. Being in `notify` does NOT make someone the agent or the owner — don't infer ownership from it. Many contracts have no agent set at all (`agent`/`agent_id` null), and the backend has no "belongs to me" concept; visibility is org-scoped.

enskai_search_contracts

Search the organization's revenue or expense items. Returns a compact, paginated list — each item has the id (UUID), amount, currency, company, due date and paid/invoiced flags; pass the id to get_record(resource="revenue"|"expense", id) for full detail. Scoped to the caller's organization, role and visibility (needs the legal module). When has_more is true, call again with offset set to next_offset. For a "how many" / total question read the `total` field (the full match count) — never count `items`, which is only the current page.

enskai_search_finances

Search the whole player catalogue — any player, not just your own book. Use this to FIND players you don't already track: "free-agent centre-backs in Poland under 24", "left-footed full-backs whose contract expires in June", "is he GBE eligible". For players already in your organization use search_players instead, which carries your own notes, stages and prices. Returns a **ranked shortlist**, not the full match set: `total` says how many players match, `shown` how many are returned, and `capped` whether there are more. Always tell the user what they're looking at — "the 50 best matches out of 4,127" — rather than implying the list is everything. There is no next page, by design: this is the catalogue, and the useful next step is a sharper question, not more rows. When `capped` is true, say so plainly and offer to narrow — by age, division, contract window, minutes played — rather than apologising for a limit or implying the data is withheld. `narrowing_hint` in the response suggests which filter would help most. The shortlist can be widened to `max_shortlist` at a push, but a 4,000-match query wants a better filter, not a longer list. Ranking defaults to market value, descending. Set `sort_by` when the question implies another order (contract expiry for expiring deals, age for youth) — with a cap in play, the ranking decides who makes the cut, so it matters more here than on your own book.

enskai_search_market_players

Search the organization's player records with optional filters. Covers ONLY players onboarded in the caller's organization — their book, with their own stages, prices and notes. To find players they don't yet track, use search_market_players, which searches the whole catalogue. Use this to find players by name, position, age, foot, control stage or tags. Returns a compact, paginated list — each item has the player's id (a UUID), name, position, current team, ratings and key terms; pass the id to get_record(resource="players", id) for full detail. Results already respect the caller's organization, role and per-record visibility, so you never see records the user can't. When has_more is true, call again with offset set to next_offset. position, control_stage and transfer_strategy are constrained enums (valid values are in the schema — no pre-flight needed); only `tags` is org-defined, so call get_filter_options(resource="players") when you need the exact tag set. Filter by current club (team_id), team_country, passport_country (nationality) or area_league ("League|Area", e.g. "Premier League|England"). For a "how many" question read the `total` field (the full match count) — never count `items`, which is only the current page.

enskai_search_players

Search the organization's scouting reports. Returns a compact, paginated list — each item has the report id (UUID), the player_id it concerns, ratings and the scout's notes; pass the id to get_record(resource="scouting_reports", id) for full detail. Scoped to the caller's organization, role and visibility. To see every report about one player, prefer reports_for_player. When has_more is true, call again with next_offset.

enskai_search_scouting_reports

Search the organization's team requests (clubs' player briefs). Returns a compact, paginated list — each item has the request id (UUID), the club, desired position, budget and window; pass the id to get_record(resource="team_requests", id) for full detail. Scoped to the caller's organization, role and visibility. When has_more is true, call again with offset set to next_offset. status, position and foot are constrained enums (valid values are in the schema); transfer_period and tags are org-defined, so call get_filter_options(resource="team_requests") when you need those exact values. For a "how many" question read the `total` field (the full match count) — never count `items`, which is only the current page.

enskai_search_team_requests

What the platform has flagged about one player. Use when asked "is there anything on <player>?" or while building a picture of someone — a trigger is a dated observation (a club change, a contract nearing its end) rather than a record the user wrote.

enskai_triggers_for_player