Returns the customer + partner accounts the user approved during the MCP consent screen. Call this first when you need to resolve a partner by name or when the user has multiple roles. Each entry has: id, type ('customer' | 'partner'), name, company_id, partner_id (null for customer), affiliate_company_name (partner only — the customer company hosting the partnership), and dashboard_url (the canonical EULER web-app URL for this account's role — use this when the user needs to do something MCP doesn't expose, like creating an incentive program; customer accounts point to /dashboard, partner accounts to /partners). To resolve a partner by name, match `type === 'partner'` AND `affiliate_company_name === <target>`; use that entry's `partner_id` for referrals / partner_artifacts / performance / commissions. Response also includes `consent_summary` with `hidden_count` — if non-zero, some user accounts were not authorized in this session; ask the user to disconnect/reconnect to include more rather than guessing. Downstream tools auto-resolve partner_id to its company_id, so you only need to pass partner_id. IF the response includes a `backend_data_issue` field (only ever present when the backend returned zero accounts for a provisioned user), this is a backend data anomaly, NOT a consent problem — do NOT suggest disconnect+reconnect; surface the support_email from that field and offer to continue with other tools (partners, performance, commissions) which read directly from the user's company and may still work. When the user asks to do something this MCP doesn't cover (creating incentives, billing/account settings, adding new partners from scratch), surface the matching account's `dashboard_url` instead of guessing a URL.

Searches EULER's Partner Directory — public-facing partner profiles, tiers, status, custom-fields completeness, iframe analytics, saved filters. Returns directory `profile_id` values that are DIFFERENT from the `partner_id` used by referrals / partner_artifacts / performance / commissions; using a profile_id where partner_id is expected produces `partner_not_in_consent`. To resolve a partner_id from a name, prefer `list_accounts` (match by `affiliate_company_name`) or `partners(action: 'list', filter_name: ...)`. entity_key selects mode: 'partner_directory' is THE workhorse search mode — filter by name, status, tier, type, email, featured, incomplete, language, or website, INCLUDING language-coverage queries like 'which partners serve Spanish?'. 'partner_history' returns a single profile's change history (also requires profile_id). 'partner_filter' applies a named saved filter via `version_description` — only used when the user explicitly references a saved filter name. The `status` enum here filters Directory profile status (Active / Under Review / Awaiting Setup / Rejected / Hidden) — that's distinct from the partner roster's active-vs-pending state. Route generic partner-status / partner-count questions ('how many partners are active?', 'how many active partners do we have?', 'partner status breakdown') to `partners(action: 'summary')`; only use this tool's `status` filter when the user is explicitly asking about the Partner Directory. Filterable by name, status, featured, incomplete, tier, profile_id, type, email, language, website.

Query partners of the user's company (customer-admin view). action='list' searches by name (filter_name='<name>') and returns partner_id values usable in referrals / partner_artifacts / performance / commissions. If the user is asking about a partner where they themselves have an account (they are a partner OF that company), prefer `list_accounts` matched by affiliate_company_name. action='pending' returns partners awaiting approval. action='summary' returns company-wide aggregate metrics broken down by partner status — this is the canonical source for company-level partner-status / partner-count questions like 'how many partners are active?', 'how many active partners do we have?', 'partner status breakdown', 'partner totals'. Generic mentions of partner status refer to the company's partner roster and belong here; route to `partner_directory_search` ONLY when the user explicitly mentions the Partner Directory (which uses a separate profile-status concept). The summary result is stable across a conversation, so call it at most once per conversation when needed.

Returns artifacts linked to a specific partner. All actions require partner_id. To resolve partner_id, prefer (a) `list_accounts` (when the user has an account with that partner, match by `affiliate_company_name`) or (b) `partners(action: 'list', filter_name: ...)` (customer admin querying their company's partners). IDs from `partner_directory_search` are profile_ids and will be rejected as `partner_not_in_consent`. action='agreements' returns signed agreements; 'tracking_links' returns affiliate links; 'deals' returns the partner's deals (paginated); 'charges' returns charges assigned to the partner (paginated); 'invoices' returns the partner's invoices (paginated).

Query existing referrals / deal-registrations. action='search' (requires os_referral_type) returns a filtered search across the company's referrals (optional partner_id filter, date range, status). action='for_partner' returns referrals submitted by a specific partner (paginated). action='get_form_for_partner' returns the referral-form question schema a partner must fill in — call this before `submit_referral` to discover form_id + questions[]. Partner_id sources: `list_accounts` (the user's own partner roles) or `partners(action: 'list', filter_name: ...)` (customer admin querying their company's partners). IDs from `partner_directory_search` are profile_ids and will be rejected. Use `submit_referral` to actually send a new referral after collecting answers.

Submits a new referral or deal registration on behalf of a partner the authenticated user has an account with. Required flow: (1) resolve partner_id from `list_accounts` — match by `affiliate_company_name`, e.g. 'send a referral to <Partner>' means the user has a partner account with that affiliate_company_name. (2) call `referrals(action: 'get_form_for_partner', partner_id)` to fetch form_id + questions[]. (3) have the user fill in every required question. (4) call this tool with partner_id + form_id + answers (a JSON array of {question_id, answer_text, multiselect_options[]} entries). Customer admins cannot submit referrals on behalf of their company's partners — that's a partner-side action. IDs from `partner_directory_search` are profile_ids and will be rejected as `partner_not_in_consent`.

Look up a specific deal by name. Returns deals whose name matches `deal_name`. REQUIRED: deal_name. partner_id behaviour depends on caller role: partner-role callers MUST pass partner_id (the search is scoped to that partner's deals); customer-role callers MAY pass partner_id to narrow the search to one partner — when omitted, the search covers all the company's deals. Use this for questions like 'find the Acme deal' or 'show me deals named *renewal*'; for generic listings or aggregates use `performance(action: 'overall')` instead.

Inspect specific charges (for partner-scoped charge lists, use `partner_artifacts(action: 'charges')`). action='for_deal' returns all charges linked to a deal_id (e.g. 'show me what was charged on deal X', 'list charges for deal abc'). action='by_id' returns the full detail of a single charge — amount, commission, partner, date, status (e.g. 'inspect charge xyz', 'why was this charge created'). Customer-only.

Create or edit Flow containers (onboarding / training / certification programs). action='create' creates a new flow (requires name, description, type, enable_due_date; optional due_date). action='edit' saves/activates/publishes/archives an existing flow (requires flow_id, flow_status, final_order, entity_key='edit'|'publish'). To inspect an existing flow's details, use `flow_details`.

Returns Flow and/or Step details. All parameters are optional: pass `flow_id` alone to get a flow's details + its assignments; pass `flow_step_id` to get step details; pass `name` alone to search flows by name (returns all matches); pass `flow_id` + `flow_step_id` together to get both flow and step joined in one response.

Create, edit, or deactivate Steps inside a Flow. action='create_or_edit' creates/edits a step (requires flow_id, name, description, os_flow_step_type, order_temp, entity_key='create'|'edit'). action='deactivate' enables/disables an existing step (requires flow_id, flow_step_id, step_status='Active'|'Inactive', entity_key='step'). To list attachable resources (content/agreement/quiz) before creating a step, use `flow_step_attachments`. Note: `entity_key` overloads two distinct discriminators across the two actions — see its field description.

Lists attachable resources (content items, agreements, or quizzes) available to embed inside Flow Steps. Pass entity_key='content' | 'agreement' | 'quiz' to scope which resource type to list. Returned ids feed `flow_steps(action: 'create_or_edit')` via content_id / agreement_term_id / quiz_from_schema_id. Note: 'Task', 'File Upload', 'SCORM', and 'Text' are valid Flow step types but NOT valid entity_key values here — those step types don't have an attachable-resource pool.

Assign or unassign Flows to partners/users. action='assign' assigns a flow (requires flow_id, assign_to_option — exact strings; pass partners_id_list and/or users_id depending on the option). action='unassign' removes an assignment (requires flow_id, entity_key='all'|'partner'|'user'). To list eligible partners/users before assigning, use `flow_assignment_candidates`.

Returns the partners and users that can be assigned to a Flow. Requires partner_id (the scope partner). Use the returned ids in `flow_assignment(action: 'assign')`.

Query invoices at the company level. action='list' returns invoices with advanced filters (status, currency, date range, sort, descending); 'summary' returns aggregate totals by status (paid/pending/processing) — use for 'how much was invoiced', 'total revenue', invoice aggregate questions.

Commission payouts and expense calculations over a date range. action='company' returns the third-person aggregate (e.g. 'how much did we pay', 'our commission expense', 'company-wide payout', 'total spent on partner commissions') — customer-only. action='partner' returns first-person or specific-partner queries (e.g. 'how much commission did I earn this month', 'minha comissão', 'commission owed to <Partner X>', 'partner X earnings') — requires partner_id, callable by partner-role tokens. Partner_id sources for action='partner': `list_accounts` (the user's own partner roles, match by `affiliate_company_name`) or `partners(action: 'list', filter_name: ...)` (customer admin querying their company's partners). IDs from `partner_directory_search` are profile_ids and will be rejected as `partner_not_in_consent`. start_date and end_date are required (no defaults).

Returns the company's incentives and the count of partners associated with each. Use for incentive program reporting.

Partner performance metrics and rankings over a date range. action='overall' ranks all partners (e.g. 'top 5 partners', 'best performing partners', 'leaderboard', 'highest performers', 'partner ranking') and REQUIRES start_date, end_date, page, limit, and entity_key. Dates use YYYY-MM-DD format (e.g. '2024-04-07') — NEVER include a time component; full ISO 8601 datetimes are silently mis-parsed downstream and return corrupted years. When the user doesn't specify a window, default start_date to today − 90 days and end_date to today. Pagination defaults: page=1, limit=10. entity_key selects the ranking metric — pass 'revenue' for closed-won/invoiced revenue ($) questions (top sellers, biggest accounts, highest revenue contributors) and as the default for generic performance questions; pass 'deals' only when the question is specifically about deal COUNT (most deals closed, most wins). 'overall' is terminal — it returns ranking plus aggregate metrics in one call, considering deals only (no commissions data); subsequent partner_artifacts/commissions calls aren't necessary unless the user asks for more depth. action='partner' returns a single partner's metrics — requires partner_id, callable by partner-role tokens. action='company' returns the user's own company aggregate (sales/deals/charges) — customer-only. Disambiguation when the user names an entity: if the name matches the user's own company (`list_accounts` entry where `type==='customer'` AND `name===<asked>`), use action='company'. If it matches an `affiliate_company_name` in `list_accounts` OR a partner of the user's company, use action='partner' with that partner_id. Partner_id sources for action='partner': `list_accounts` (match by `affiliate_company_name`) or `partners(action: 'list', filter_name: ...)`. IDs from `partner_directory_search` are profile_ids and will be rejected as `partner_not_in_consent`.

Returns deal attribution data for a date range: counts and totals for sourced deals (partner-originated), influenced deals (partner-touched), and combined sourced-and-influenced deals — with per-partner breakdowns suitable for ranking. Use for deal-source-attribution questions: counts of sourced/influenced deals, total value of sourced/influenced deals, sourced vs influenced comparisons, and partner rankings by sourced/influenced deal performance. Pass `partner_id` to scope the response to a single partner's attribution (sourced/influenced deals owned by that partner only); omit it for the company-wide view across all partners. For generic partner deal lists without sourced/influenced framing, `partner_artifacts(action: 'deals')` is the right tool; for company-wide aggregates use `performance(action: 'overall')`; for looking up a specific deal by name use `get_search_deals`.

Semantic search across the EULER knowledge base / partner-facing content. Use for how-to questions and documentation lookups.

Sends feedback to the EULER engineering team about the MCP itself — tool errors, ambiguous descriptions, missing capabilities. Use proactively when: (a) type='error' — a tool returned an unrecoverable error and the user couldn't get what they asked for; (b) type='improvement' — a tool's description was ambiguous and led down the wrong path before recovering; (c) type='feature_request' — the user asked for something this MCP doesn't support yet; (d) type='recommendation' — a general suggestion (UX, naming, missing context, etc). Feedback is delivered to a Slack channel monitored by EULER engineering. Do NOT use for routine user-fixable errors (wrong input, missing partner_id, malformed deal_id) or to surface successful operations — only when the MCP itself fell short.