KontrolX bronze
s-mcp-core.kx21.com
“KontrolX governed Profile-attribution agent — Profiles, Intakes, Enrichments, Placements, Lifecycles, Actions, Capsules, Datasets, and Webhooks.
a2a https://s-mcp-core.kx21.com/a2a talk to it https://s-mcp-core.kx21.com/.well-known/agent-card.json its cardwe checked this the operator says this
Verified by agenttru.st
Everything here is a check agenttru.st performed itself. Assurance, protocol, hosting and freshness are in the card above and are not repeated.
- Certificate
-
Issued by Let's Encrypt
domain-validated
Valid until 7 Nov 2026.Control of the hostname was checked; nothing about who operates it.
- DANE / TLSA
- Not verified (TLSA query returned RCodeNameError)
- Discovery
- Well-known document
- First seen
- 23 Aug 2026
View verification details
- Assurance
- bronze Bronze — agent card fetched over HTTPS with a valid certificate
- Protocols
- A2A verified by handshake or card fetch, not merely advertised
- Hosted in
- 🇺🇸 US · Oracle Corporation (AS31898)
- Last checked
- 1d ago
What this agent says it can do
Declared in the agent's own card. agenttru.st has not tested whether it completes any of these tasks — the operator of s-mcp-core.kx21.com controls every word below.
kx_toolkit
What this connection can do beyond the tools listed here. The listed set is what a session reaches for constantly — reads, search, catalogs, placements, intakes, lifecycle, actions. Everything else (configuring a Workflow, its screeners, enrichments and buyers; creating vendors, buyers, dashboards, datasets, knowledge bases, webhook subscriptions; bulk loads; sample activity) is REAL and available, just not listed, because their schemas would cost this conversation ~25,000 tokens before you asked a question. Call with no query to see every one by name, or with a query ('configure buyer routing', 'bulk load profiles') to get full schemas. Then invoke with kx_call. If a task seems impossible with the listed tools, call this BEFORE telling anyone it cannot be done — it almost certainly can.
kx_call
Invoke a tool that kx_toolkit named. Pass { tool: "<name>", args: { … } }. The arguments go through that tool's own schema, permissions, and environment rules unchanged — this is how it is reached, not a way around any of them. Get the exact argument shape from kx_toolkit first; guessing it produces a validation error, not a silent partial write.
catalog_list_profile_types
List Profile Types available to the caller's org (global defaults + org-specific). A Profile Type is the durable identity model for governed entities and may be used without any Workflow. A real Workflow can also lock to one Profile Type. Returned ids are used by profile_create/profile_list and workflow_create. Returns at most `limit` rows (default 100, hard cap 500); `truncated: true` marks a shortened answer.
catalog_list_workflows
List Workflows defined in the caller's org. A Workflow is a real channel or production line for arriving business events, locked to one Profile Type; it owns Intake screening, fixed Enrichment/action plans, and lifecycle transitions. Profile-only inventory/history needs no Workflow. Returns at most `limit` rows (default 100, hard cap 500); `truncated: true` marks a shortened answer.
catalog_list_vendors
List Vendors in the caller's org. A Vendor is a real party that delivers events into a chosen Workflow, performs Enrichment/screening, or both. Cost traceability is available when a cost exists but is not what defines a Vendor. Partner keys and Enrichment results carry vendor attribution. Returns at most `limit` rows (default 100, hard cap 500); `truncated: true` marks a shortened answer.
catalog_list_buyers
List Buyers configured in the caller's org. A Buyer is a downstream destination for a potential or completed sale represented by a Placement. partner_buyer API keys are bound to a buyerId and can accept, reject, or return routed Placements. Returns at most `limit` rows (default 100, hard cap 500); `truncated: true` marks a shortened answer.
catalog_list_screener_types
List screener types available to the caller's org. A screener decides whether a lead may proceed, before any enrichment cost is incurred. WHEN each one runs is a per-step setting on the workflow, not a property of the type: mode 'pre_ping' runs both when a supplier pings to ask whether we would take a lead AND on the posted lead, while mode 'post' only ever sees a posted lead. So a workflow whose screeners are all 'post' answers a ping having screened nothing — a lock surfaces as intake_preping's { locked: true, reason }, and that call can only report what the 'pre_ping' steps decided. Returns at most `limit` rows (default 100, hard cap 500); `truncated: true` marks a shortened answer.
catalog_list_enrichment_types
List Enrichment Types available to the caller's org, including Profile-level bulk/on-demand integrations and types fixed into Workflow pipelines. An Enrichment wraps an external or internal lookup with attributed history and optional cost/accounting metadata. Returns at most `limit` rows (default 100, hard cap 500); `truncated: true` marks a shortened answer.
catalog_list_action_types
List action types defined in the caller's org. An action type names a fireable side-effect (welcome email, SMS verify, CRM push, etc.). The returned id is the actionTypeId argument to action_fire. Returns at most `limit` rows (default 100, hard cap 500); `truncated: true` marks a shortened answer.
catalog_get_workflow_enrichment_steps
Return a workflow's current enrichment pipeline steps with each step's full integration config and its `wave` — which steps run at the same time, and what waits for what. Call this BEFORE workflow_enrichment_pipeline_configure to APPEND a step: that tool replaces ALL steps, so send the existing ones back WITH their wave numbers plus the new one, or the rewrite collapses a staged pipeline into one wave that fires everything at once. A step reported as wave 0 can never run — it waits on a cycle or on something no longer in the pipeline.
catalog_get_workflow_screener_steps
Return a workflow's current screener pipeline: each step's workflowScreenerId, code, name, `wave`, `waveRule`, mode, enabled flag, and stored config. Call this BEFORE workflow_screener_pipeline_configure — that tool REPLACES the whole pipeline, so a call made without reading first drops the steps you did not mention, their operator-set config, and the waves that say what runs together. `wave` is 1-based and steps sharing one run at the same time; `waveRule` is what that wave takes — 'all' (every member must pass) or 'any' (one passing member carries it). mode 'pre_ping' answers a supplier's ping AND the posted lead; 'post' only ever sees a posted lead. hasIntegration false on a custom screener means it has nowhere to send its request, so it cannot answer and refuses every lead.
action_list
List the most recent fired actions in the caller's org (org-wide scope). For per-profile scope use profile_get_actions. Returns at most `limit` rows (default 100, hard cap 500); `truncated: true` marks a shortened answer.
action_get
Get a single fired-action record by id. Returns the full row.
action_fire
Fire an action on a profile. Returns a RECEIPT { id, status } — not the full record. Use action_get with the returned id to retrieve the full row once status reaches "received".
profile_list
List profiles visible to the caller's role. Supports profileTypeId filter, limit, and createdAt cursor (before, ISO 8601). Use profile_get_lifecycles for per-profile history.
profile_get
Get one profile by id. Returns the bare row. Use profile_get_intakes / _enrichments / _actions / _lifecycles for related sub-resources.
profile_create
Create a profile under the caller's org. customer_admin only. Returns the created row (bare).
profile_bulk_load
Bulk-load HISTORIC Profile facts from CSV text at any time with NO pipeline (no screeners, Enrichment cost, Placements, or lifecycle). Dedupes + merges on identifiers via upsert. Caps at 500 rows/call; continue with nextOffset when returned. THE LOADER RETAINS ONLY THESE HEADERS (snake_case or camelCase): email, phone, first_name, last_name, address_line1, address_line2, city, region/state, postal_code/zip, country, and ONE identifier_type/identifier_value pair. The allowlist is fixed and global — a custom Profile Type does not extend it. Audit every supplied header against that list BEFORE calling. Every supplied header is preserve-or-stop: if ANY is unsupported, stop the whole file — no partial load, no supported subset, no splitting a field elsewhere, no Dataset or fake Workflow substitute, and never ask for a reduced or reshaped file. Rows process independently, so partial success is possible: inspect `failed` and every `results` entry, report each error, preserve the input, and never declare completi
profile_update
Patch a profile's attributes. customer_admin only. Only provided attribute fields are updated; others are left unchanged. Returns the updated row (bare).
profile_get_intakes
List intakes attached to a profile (every intake that flowed into this profile via dedupe). Returns a bare array.
profile_get_enrichments
List enrichments performed on a profile. Returns a bare array (empty if none).
profile_get_actions
List action runs on a profile (per-profile scope). Returns a bare array. Compare action_list for org-wide scope.
profile_get_lifecycles
List ALL lifecycle rows for a profile, including closed. Returns a bare array. Use this for history; use lifecycle_get for the single OPEN lifecycle (errors if none).
profile_count
Return the total number of profiles visible to the caller's role, with optional period filtering and groupBy aggregation. partner_source and partner_buyer keys are narrowed by their visibility bindings; customer roles see org-wide counts. Use period (today/yesterday/last_7d/last_30d/all) for common date windows, or since/until for custom ISO 8601 bounds. groupBy=profileType returns a bucket array alongside the total.
webhook_list
List webhooks registered for the caller's org. Returns a bare array. Returns at most `limit` rows (default 100, hard cap 500); `truncated: true` marks a shortened answer.
webhook_get
Get one webhook by id. signingSecret is NEVER returned by reads — only on create.
webhook_create
Create a webhook subscription for the caller's org. customer_admin only. Returns signingSecret ONCE — save it immediately; the secret cannot be retrieved later (revoke + re-create if lost).
webhook_update
Patch a webhook subscription. Only provided fields are updated. customer_admin only.
webhook_delete
Hard-delete a webhook subscription. Future events of subscribed types stop firing. customer_admin only. Returns { ok: true }.
webhook_get_deliveries
List recent delivery attempts for a webhook. Returns a bare array (oldest empty for fresh subscriptions).
webhook_replay_delivery
Re-enqueue a failed (or successful) delivery. Throws GoneError (410) if the source event has been pruned. customer_admin only.
lifecycle_get
Get the OPEN lifecycle row for a profile. Throws "no open lifecycle for profile X" if the profile has no open lifecycle (closed or never started). For full history including closed lifecycles, use profile_get_lifecycles instead.
lifecycle_list
List lifecycle rows in the caller's org. Optional state filter narrows the result. Workflow-specific states may also be valid beyond the enum hint.
lifecycle_transition
Transition a profile's open lifecycle to a new state code. Throws ConflictError if the transition is invalid for the workflow, or if expectedVersion doesn't match (optimistic concurrency).
placement_list
List placements visible to the caller. Partner keys bound to a buyer see only buyer-scoped placements; customer roles see org-wide placements (with profile-visibility narrowing applied). Each row carries workflowCode + vendorId + vendorCode (inherited from the originating intake) so vendor-level rollups (e.g., "which vendor produced the most placements") can be computed in a single pass without joining catalog_list_workflows or catalog_list_vendors.
placement_get
Get a placement by id. Returns the bare row (no envelope). Partner keys may only fetch placements routed to their bound buyer; cross-buyer reads return NotFoundError (existence-hiding).
placement_accept
Accept a placement as the bound buyer. Requires a partner_buyer key with buyerId binding — customer keys cannot accept. Idempotent on already-accepted rows.
placement_reject
Reject a placement as the bound buyer. Requires a partner_buyer key with buyerId binding. Terminal — the placement will not re-route to the same buyer.
placement_return
Return a previously accepted placement (post-accept refund/clawback). Requires a partner_buyer key with buyerId binding. Only valid on placements currently in status="accepted".
placement_count
Return the total number of placements visible to the caller, with optional period filtering and groupBy aggregation. partner_buyer keys are scoped to their bound buyer; customer roles see org-wide counts. Use period (today/yesterday/last_7d/last_30d/all) for common date windows, or since/until for custom ISO 8601 bounds. groupBy=status or groupBy=buyer returns a bucket array alongside the total.
intake_create
Submit a real arriving business event. Returns a RECEIPT { intakeId, status, dedupe } for a real event through a real Workflow, then runs the full pipeline asynchronously. Never use this tool to manufacture an intakeId for inventory or Profile-only history. Use profile_get_intakes or webhook events to observe progress. AUTH: Requires a partner_source API key (not a customer_admin key). To get one: 1. Call catalog_list_workflows to discover available workflow IDs. 2. In the admin UI go to Workflows → open the workflow → Vendors tab → expand the vendor → "Issue key". The key is bound to that workflow + vendor. (/admin/api-keys only mints customer_admin / customer_user keys.) 3. Configure the MCP server to use that bearer token instead of the customer_admin key. If you hit a missing-scope error, the current key lacks the workflow_id + vendor_id binding — follow the steps above.
intake_preping
Run pre-ping screening checks against an intake-shaped payload WITHOUT creating an intake. Returns { locked: false } when the payload is clear, or { locked: true, reason } naming the single check that locked it out (blacklist, duplicate_sold, duplicate_window, reentry_denied_rejected, reentry_denied_disqualified, reentry_denied_awaiting, reentry_denied_stuck, buyer_screeners_rejected). There is no `reasons` array and no `accepted` field on either of those — `accepted: false` with a `code` appears ONLY when the pre-ping could not run at all (missing_identifier, workflow_not_found, workflow_inactive). Use this to validate a real arriving event before committing it. AUTH: Same partner_source key requirement as intake_create — needs vendor_id + workflow_id binding. Call catalog_list_workflows to find the intended Workflow, then in the admin UI open that Workflow → Vendors → expand the bound Vendor → Issue key. Point the MCP server at that partner_source bearer. /admin/api-keys only creates customer_adm
intake_count
Return the total number of intakes visible to the caller, with optional period filtering and groupBy aggregation. partner_source keys are scoped to their bound workflow; customer roles see org-wide counts. Use period (today/yesterday/last_7d/last_30d/all) for common date windows, or since/until for custom ISO 8601 bounds. groupBy=status returns a bucket array alongside the total.
intake_bulk_load
Submit a CSV of real arriving events through the FULL intake pipeline — every row runs ingestIntake (screeners, dedupe, routing) attributed to the given vendor + workflow. Use for bulk files (e.g. an emailed vendor CSV) after mapping columns; use profile_bulk_load instead for historic Profile-only inventory with no pipeline. Row caps: 500 for inline csvText; 50,000 for stored-file r2Key loads (they run durably on the worker). csvText is the raw CSV including a header row; columnMapping optionally renames CSV headers to intake field names ({ "EmailAddress": "email" }). Accepts the raw csvText OR the r2Key of an already-stored file (inbound-email conversions expose convertedKey in the mission input). Returns { accepted, rejected, results[] } with per-row intakeIds and rejection reasons. AUTH: customer_admin keys work org-wide; partner_source keys may only load their own bound workflow.
enrichment_submit
Submit an Enrichment result back to KontrolX with a partner_enrichment API key bound to a Vendor, Enrichment Type, and when configured a Profile Type; bindings are server-derived and never passed in payload. This is a valid standalone Profile Enrichment result callback and result-ingestion callback only; it never invokes a provider or triggers Vendor execution. It is not the configure/trigger/poll operator batch path. For async Intake-bound work, pass the real intakeId. For unsolicited/standalone Profile Enrichment, pass intakeId:null and the identifiers configured by the key-bound Profile Type in payload so KontrolX can resolve/upsert the governed Profile. It accepts neither profile_id nor profileId and is never profileId-keyed; it is VIN-keyed only when VIN is configured on the key-bound Profile Type and supplied in payload. Never fabricate an Intake. The current MCP cannot configure, trigger, or poll customer-admin Profile Type bulk execution. Returns the Enrichment row.
enrichment_get_upload_url
Mint a pre-signed R2 PUT URL for uploading a binary enrichment artifact (PDF report, audio recording, etc.). Requires a partner_enrichment API key bound to a vendorId + enrichmentType. Returns { uploadUrl, objectKey } — PUT the binary to uploadUrl, then reference objectKey inside the payload submitted via enrichment_submit.
enrichment_test
Dry-run an enrichment integration against a sample Profile and its real existing Intake. This tool requires a real Intake: both profileId and intakeId are required. It resolves inputFields, makes the SSRF-guarded vendor call, and returns request + response without creating an Enrichment or charging configured cost. Never fabricate an Intake for Profile-only data. Profile-only bulk execution is an operator action in the Profile Type admin UI and remains a current MCP capability gap. Authorization is never echoed. WARNING: this makes a real outbound HTTP call, so user approval is required.
profile_type_create
Create or update the identity model for a durable governed Profile: code, name, identifiers, and kind. Upserts on (org_id, code). This tool does not create arbitrary Profile storage/attribute fields or columns and does not expand profile_bulk_load. A Profile Type can stand alone for entity inventory/history and does not require a Workflow. kind declares person | asset | organization | event; omitted → person on create, existing kind preserved on update. `event` is for durable records of moments (calls) that later Workflows connect to by exact identifier — never routed to Buyers. Create a Workflow afterward only when discovery identifies a real arriving business event or production line. identifiers is AUTHORITATIVE over every bound Workflow intake shape: workflow_create and workflow_update_rules reject a non-empty inputValidationRules that never requires one of these fields.
workflow_create
Create or update a Workflow for a real business event, channel, or production line. A Workflow IS the line: it owns its required data, screening, Enrichment, routing and Buyers, with no configurable layer beneath it. It locks to exactly ONE Profile Type — the primary entity whose history the arriving event attributes to — and a secondary identifier in the payload cannot switch that lock, though it may still key a Profile Lookup Enrichment step. Differences in required data, screening, Enrichment, routing or Buyers do NOT split Workflows; different arrival paths do. Discover the actual channels before naming them, and never create a temporary umbrella Workflow ahead of that discovery. Never create one for a Profile-only catalog/history upload or merely to obtain an intake ID. Upserts on (org_id, code); call after the relevant profile_type_create. status is draft | active | paused | closed (defaults active on create); an explicit status is applied on create and update and never touches a deleted Workflow. i
workflow_update_rules
Update only input_validation_rules and/or dedupe_rules on an existing real Workflow without restating the row. Use for its Intake validation or Workflow-local duplicate policy; it does not apply to Profile-only inventory/history. inputValidationRules is the Intake payload allowlist AND presence enforcement; dedupeRules is the Workflow-local duplicate policy. Two rules decide whether this call is accepted: unknown top-level keys are REJECTED (a typo'd `allowedFields` does not silently pass), and any non-empty inputValidationRules must put at least one of the bound Profile Type's identifier fields in requiredFields — naming it only in optionalFields does not satisfy it, and an Intake that omits every identifier silently drops at missing_identifier. Read the identifiers with catalog_list_profile_types first. Full shapes, validators, and the deny-by-default re-entry table: the kontrolx-wizard skill, §Field reference.
vendor_create
Create or update a real Vendor identity: a party that delivers business events into a chosen Workflow, performs Enrichment, or both. Upserts on (org_id, code). Defaults vendorType=source, isInternal=false. A Vendor is not required merely because Profile-only inventory was uploaded; create one only for a real delivering or enriching party.
buyer_create
Create or update a Buyer directory row for a potential or completed Placement destination. This is the directory entry only — it places the Buyer on no Workflow. Per-Workflow routing (priority, weight, cap, price, filters, schedule, pause, payload mapping, screeners) lives in workflows.placement_shape.routing.buyers[] and is set with workflow_routing_configure, or one entry at a time with workflow_routing_update_buyer. Delivery config — how accepted Placements physically reach this Buyer — is set with buyer_delivery_configure and read with buyer_delivery_get. Do not create Buyers for Profile-only storage or a Workflow with no Placement.
buyer_delivery_get
Read a Buyer's placement delivery configuration: deliveryMode (webhook | email | both) and delivery_config (delivery url/auth/format, email recipient). deliveryMode 'webhook' means a plain HTTP request to the buyer's own URL — the buyer does NOT need to support webhooks or register a subscription; any API endpoint works. This is the PLACEMENT DELIVERY channel — separate from Event Webhooks (webhook_* tools), which are notification subscriptions.
buyer_delivery_configure
Set a Buyer's placement delivery channel — how accepted placements physically reach them. deliveryMode webhook | email | both. 'webhook' is a misnomer kept for compatibility: it is a plain HTTP request to whatever URL the buyer gives you, so a buyer that 'does not support webhooks' but has an API is still deliveryMode webhook. Never reach for a Trigger to post leads to a buyer — Triggers are org event side-effects and carry no placement lifecycle, retry, or routing. Delivery config is environment-LOCAL: it does not travel sandbox→live, so set it per environment, and it is a separate system from Event Webhooks. Wire formats (json | form | query | raw + body_template) and where the field names come from: the kontrolx-wizard skill, §Field reference.
workflow_routing_configure
Configure a real Workflow's Placement routing: REPLACES requiredIntakeFields, requiredEnrichmentTypes, defaultPriceCents, and routing.buyers[] in one call. Never call this for a Profile-only catalog upload or to manufacture an Intake. Call after workflow_create and, only when Placements apply, buyer_create. payloadMapping must be {fields:[{kind:"field",target,source,default?}|{kind:"literal",target,value}]} — a flat key/value map is REJECTED. "target" is written verbatim: a dot in it is a literal character, never a nesting separator. "source" (field rows only) is likewise a flat lookup key with no dotted traversal. The addressable source catalog, worked examples, and default/omit behaviour: the kontrolx-wizard skill, §Field reference. Reformatting a field is a declarative "transform" on the field row, and that is the ONLY way — there is no scripted step to write instead. Catalog and fallback behaviour: the kontrolx-wizard skill, §Field reference.
workflow_routing_update_buyer
Update ONE entry in workflows.placement_shape.routing.buyers[] without restating the entire array. Use to tweak a buyer's priority, payload mapping, or screeners post-onboarding. Throws if the buyerId is not currently in the workflow routing. This is an A+E+P Placement-routing operation, not Profile-only configuration. payloadMapping must be {fields:[{kind:"field",target,source,default?}|{kind:"literal",target,value}]} — a flat key/value map is REJECTED. "target" is written verbatim: a dot in it is a literal character, never a nesting separator. "source" (field rows only) is likewise a flat lookup key with no dotted traversal. The addressable source catalog, worked examples, and default/omit behaviour: the kontrolx-wizard skill, §Field reference. Reformatting a field is a declarative "transform" on the field row, and that is the ONLY way — there is no scripted step to write instead. Catalog and fallback behaviour: the kontrolx-wizard skill, §Field reference.
workflow_screener_pipeline_configure
Wire screener_types into a real Workflow — global codes (blacklist, input_validation, duplicate_control) and this org's custom screener types both resolve. Screeners run in WAVES: pass `waves` as [{codes, rule}] to say what runs together, where rule is 'all' (every member must pass — what a flat list does) or 'any' (one passing member carries the wave, which is how "ask three vendors and take the lead if any will have it" is written; as separate waves it refuses the moment the first says no). Every member of an `any` wave is called every time. A flat `screenerCodes` list is one screener per wave, in the order given. REPLACES that Workflow pipeline and throws if a code is missing — call catalog_get_workflow_screener_steps FIRST, or the steps you omit, their operator-set config, and their waves are dropped. Each code may appear AT MOST ONCE (unique per workflow+type). Returns { inserted, steps: [{ id, code, orderIndex }] }. Screening applies to arriving Intakes; it is not part of Profile-only inventory/hi
workflow_enrichment_pipeline_configure
Configure Enrichments fixed to a real Workflow and its arriving Intakes: upsert types, then REPLACE workflow_enrichments. Steps run in WAVES, not in declaration order: give each step a `wave` (1-based) — steps sharing one run at the same time, and a wave waits for the wave before it. Omitting wave everywhere means everything fires at once. Call catalog_get_workflow_enrichment_steps first so an append does not wipe existing steps. This is for A+E or A+E+P Workflows, not Profile-only Enrichment.
enrichment_type_create
Create or update a standalone Enrichment type (a governed data integration) without attaching it to a Workflow. Upserts on (org, code). Catalog metadata ONLY: execution needs attachment to a real Workflow pipeline, or the operator-run Profile Type bulk path this surface cannot configure, trigger or poll — never invent a tool, Workflow or Intake to bridge that gap. `integration` carries the whole call: endpoint/method/inputFields, the body encoding (format json|form|raw, with bodyTemplate + contentType for raw), any fixed `headers` the vendor wants alongside the credential, and authMode (bearer/basic/raw/none) from the vendor's scheme. An ASYNC type also sends the return path — `callback_url`, `entry_url`, `enrichment_id` — because a vendor answering later cannot without it; a SYNC type sends none of it, since the answer comes back in the response. Override per field with `callbackFields: [{field, key}]` to rename a key the vendor spells differently, to drop one, or to give a sync vendor just `enrichment
workflow_screener_config_set
Set the per-Workflow config (jsonb) for one screener step, identified by its workflow_screener id (NOT the Workflow id — get it from workflow_screener_pipeline_configure / the Workflow screeners screen). Primary use is the duplicate_control re-entry policy: { windowDays: number, reentry: { rejected, disqualified, awaiting, stuck: 'allow' | 'deny' } } — windowDays bounds the dedupe lock; reentry decides, per the Profile's prior Intake status, whether a repeat event may re-enter (DEFAULT DENY for any status you omit). When the target step is duplicate_control the config is validated and rejected if malformed; other screeners take opaque jsonb config. Org-scoped. This applies only to a real Workflow that wires the screener, not Profile-only inventory/history.
workflow_lifecycle_configure
Declaratively define a Workflow's lifecycle state machine: REPLACES all states and transitions for that Workflow in one transaction. Custom state codes are fully supported — the standard intake→discovery→motion→trial→closed machine is only a default, and multiple terminal states (e.g. won + lost, or sold + returned) are legal. Call workflow_lifecycle_get FIRST and resend the full machine — a partial payload wipes whatever you omit. Rules: exactly one state has isInitial (intakes auto-open lifecycles there); every transition must reference declared codes; states that open lifecycles currently sit in cannot be dropped (transition or close those lifecycles first). Set manualAllowed: true on any transition you want to drive via lifecycle_transition; transitions default to auto-only. Config changes propagate to running intake pipelines within ~30s.
workflow_lifecycle_get
Read a Workflow's lifecycle state machine definition: states (code, name, orderIndex, isInitial, isTerminal) and transitions (from, to, manualAllowed, autoEvent). Empty arrays mean the Workflow has no machine and intakes will not open lifecycles. Always call this before workflow_lifecycle_configure — configure REPLACES the whole machine.
workflow_intent_set
State what happens to a lead that PASSED screening: 'enrich' (run this Workflow's enrichments, then offer it to buyers), 'enrich_capture' (run the enrichments, then keep the profile — no buyer, by choice), 'place' (straight to buyers, no enrichment), or 'capture' (keep the profile and stop — no buyer, by choice). null means follow the setup, deriving the answer from whether buyers happen to be attached. Set it whenever a Workflow is meant to keep leads rather than sell them: without it, a Workflow that deliberately sells nothing is indistinguishable from one whose buyers were never wired, and its setup reads as unfinished forever. Do NOT attach a buyer nobody asked for to make that go away.
workflow_vendor_cost_defaults_set
What this Workflow owes a vendor per lead, before any per-vendor override. Two moments carry a cost because two different things are being paid for: costOnQualifiedCents is owed when a lead passes screening (the vendor delivered something usable), costOnAcceptedCents when a buyer takes it. null means nothing is owed at that moment — distinct from 0, which is a stated free. A per-vendor figure set with workflow_vendor_set wins over this.
Technical agent card
Copied from the agent's card. The operator controls these values; agenttru.st has not verified them.
- Protocol
- a2a
- Version
- docker
- Auth schemes
- jwtBearer
- Card completeness
-
a2a.proto v1.0 requires eight top-level fields. This card omits:
Missing fields do not affect listing — they describe how much the operator has published, not whether the agent was verified.
View all card details
- Capabilities
- pushNotifications stateTransitionHistory streaming
- Agent card
- https://s-mcp-core.kx21.com/.well-known/agent-card.json
Operate this agent and would rather not be listed? Request removal.