Genny – Generative Process and Decision Modeler by Blue Polaris

Returns the current status of a job started by `start_dmn_conversion`, or a job_id returned by a synchronous convert tool with status `running`. Waits server-side for up to ~45s while the job is still running, then returns. Call it again immediately on `running` -- never sleep between calls. Response statuses: `running` — job still processing; `elapsed_s` reports time so far. `success` — `diagram_url` and `complete_model_id` are present. `error` — conversion failed; the `message` field contains the reason. Pass `verbose=True` to include status_history and timings_s.

Confirms the active Bluepolaris connection is ready to use. Response statuses: `success` — connection is ready; tools can be called. Returns `account_id`, `user_id`, and `api_url`. `auth_required` — Clerk sign-in has not completed (or the session expired); the response includes an `auth_url` — open it, sign in, then retry. `trial_expired` — the account's free-trial window has ended; the response includes a `contact_url`. Typical first-time use: 1. User adds the connector and asks Claude to connect to DFM (this tool runs). 2. If `auth_required`, the user opens `auth_url`, signs in via Clerk, and returns to Claude. 3. User retries; connection is ready for all subsequent tool calls.

Synchronously converts one or more uploaded files into a DMN decision diagram. Returns a `diagram_url` plus `complete_model_id` on success. The companion tool `start_dmn_conversion` performs the same operation asynchronously and is appropriate when the conversion may exceed the synchronous request window. If the diagram isn't ready within ~45s, returns `status: "running"` with a `job_id` instead; call `check_dmn_conversion(job_id)` right away (it waits server-side, so never sleep between calls). Parameters: upload_id — a single upload_id (str) or a list for multi-file jobs. Each must come from a successful `create_upload_ticket` + PUT upload cycle. output_type — `"dmn"` or `"process"` (default `"dmn"`). target_language — language for generated artifacts (default English). timeout — REST upload timeout in seconds. event_timeout — maximum seconds to wait for the CompleteModel event. verbose — include status_history and timings_s in the response. model — Leave unset; defaults to `"Genny"`, which accepts .txt, .md, .pdf, .doc and .docx files only (other types return an error). Genny is the only model; any value passed here is ignored. `.zip` inputs are rejected.

Reserves a one-time upload slot on the server for a single file. Returns an `upload_id`, an `upload_url`, and an `upload_token`. The client uploads the raw file bytes via: PUT <upload_url> X-Upload-Token: <upload_token> The resulting `upload_id` is consumed by the conversion tools (`convert_to_dmn`, `import_file`, `import_files`, `start_dmn_conversion`). Only `.txt`, `.md`, `.pdf`, `.doc` and `.docx` filenames are accepted; anything else returns an error asking for one of those. Tickets expire after a fixed TTL.

Adds decisions, input data, knowledge sources, and requirement arrows to a DRD. Everything is addressed by name — a node that already exists on the diagram is reused rather than duplicated. Positions are worked out automatically; do not try to supply coordinates (use dfm_move_node afterwards if the user wants a specific placement). Send the whole picture in one call where you can — it lays out better than several small calls. Parameters: diagram_id — the diagram to build in. decisions — names of decisions, e.g. ["Candidate Meets Requirements"]. input_data — names of input data, e.g. ["Years Of Experience"]. knowledge_sources — names of policies, regulations, or analytics that give a decision its authority, e.g. ["Screening Policy"]. requirements — the arrows, as [{"decision": "<decision name>", "requires": "<name of the decision, input data, or knowledge source it needs>"}]. A decision requires; nothing else does. Both names must already be on the diagram or be listed in decisions / input_data / knowledge_sources in this same call — an arrow to any other name is skipped (reported in "skipped"), never created.

Reads what is currently on a Decision Requirements Diagram. Returns its decisions, input data, knowledge sources, and every requirement arrow actually drawn between them, plus `created_date`, `created_by` and `source_files` (see dfm_find_diagram). Call this before dfm_build_drd, dfm_rename_node, or dfm_move_node so you can confirm with the user what's already there and which node/arrow they mean. Parameters: diagram_id — the diagram's id, from dfm_find_diagram or the user.

Finds a Decision Requirements Diagram (DRD) or ERD by (partial) name. Use this first when the user names a diagram rather than giving its id — show them the matches so they can confirm which one they mean before calling dfm_describe_drd, dfm_build_drd, dfm_rename_node, or dfm_move_node. For a BPMN process diagram, use dfm_find_process instead — process diagrams are a separate resource this tool does not search. Parameters: name — part of the diagram's name, or its full id; empty lists all diagrams. page — which page of 20 results to return, starting at 1. The response says how many diagrams match in total and whether there are more; if the one the user wants isn't listed, ask for a more specific name or fetch the next page. Each result also carries `created_date` (ISO-8601 UTC) and `created_by` (email) from the diagram's DFM history, and `source_files` — the names of the files it was imported from (empty if it was drawn by hand). Any of these may be null/empty if DFM couldn't supply them.

Repositions one node on a DRD, dragging its arrows along with it. Only use this when the user asks for a specific placement — layout is otherwise left exactly as a person arranged it. The canvas runs x to the right and y DOWNWARD, so a smaller y is higher up. Call dfm_describe_drd first if you need to know where things currently are. Parameters: diagram_id — the diagram the node is on. name — the node to move (as shown by dfm_describe_drd). x — horizontal position, increasing to the right. y — vertical position, increasing downward.

Renames a decision, input data, or knowledge source. The rename applies to the object across DFM, not just this diagram — check with the user if the name might be reused elsewhere before calling this. Parameters: diagram_id — the diagram the node is on. name — its current name (as shown by dfm_describe_drd). new_name — what to call it instead.

Returns a freshly generated UUID4 string in the `uuid` field. Utility for constructing `requestid` or `transactionid` values when calling the DFM API directly. The conversion tools generate their own identifiers internally and do not need this.