Skip to main content
The connector exposes a set of tools that your assistant calls on your behalf. You don’t call these directly. You ask in natural language, your assistant picks the right tools and chains them together, and you read the result. This page documents what each tool does, what it takes, and what it returns, so you understand what is happening and can guide your assistant when you want to. Kepler runs are asynchronous, so the tools fall into four groups: start a run, wait for its result, manage existing runs, and look up reference data without a run.

Tools at a glance

How your assistant chains the tools

Because a run continues in the background, starting one and reading its result are two separate steps. Your assistant orchestrates the loop for you: A run usually finishes in a few minutes, though deeper models can take longer. The waiting tools hold the connection open and stream progress while Kepler reads sources, so you see narration in the conversation rather than a spinner.

Start a run

run_financial_research

Start a new Kepler run. This is the entry point for any research question or model request. Returns immediately with a conversation_id and a status of running. The run itself continues in the background. Your assistant then calls get_run_result to wait for the answer.

continue_research

Send a follow-up into an existing conversation. Refine a model, ask about prior results, or extend the research. The agent keeps full context from the earlier run. Returns a conversation handle, the same shape as run_financial_research. Follow it with a wait.

Wait for results

get_run_result

Fetch a run’s final result. It blocks while the run is still going and streams progress while it waits. Finished runs return immediately, so this is also how your assistant pulls the result of an earlier run. Your assistant calls this right after starting or continuing a run. A wait holds the connection open for a few minutes. A very long run can come back with status: running before it finishes. That is expected, and your assistant resumes with continue_waiting. The returned object carries everything about the result:

continue_waiting

Resume waiting after get_run_result returned running. Identical blocking behavior, used for follow-up waits on long runs. Your assistant calls it in a loop until the run completes or fails. Returns the same shape as get_run_result.

is_run_done

A one-shot, non-blocking check of whether a run has finished. Returns right away. This is a status check, not a polling loop. To actually get the result, blocking on a running run or fetching a finished one, use get_run_result. Returns done (boolean) and the current status.

Manage runs

cancel_run

Stop a running conversation, for example when you changed your mind, mistyped a ticker, or started a duplicate. Non-destructive: the conversation and any partial results survive, and continue_research can re-engage it with full context. No effect on finished runs. Returns the conversation_id and a status of cancelling.

list_recent_runs

List your most recent Kepler conversations. Useful for finding an earlier run, such as “the Netflix model from yesterday,” to continue or fetch results from. Returns a list of runs, newest first, each with a conversation_id, title, created and updated timestamps, and a conversation_link.

Look up reference data

lookup_company

Resolve a company and list the SEC filings and earnings-call transcripts Kepler has on file. Instant, with no run required. It answers questions like “is the Q3 call available?”, “when did they last file a 10-K?”, or “does Kepler cover this company?”. It returns metadata only. For the contents of a filing, the numbers, quotes, or analysis, run a research request instead. Returns:

get_workbook_data

Get the full cell data of one workbook sheet as CSV (RFC 4180), for downstream analysis beyond the tables shown in a result. Omit sheet_name to list a multi-sheet workbook’s sheets first. Returns the sheet as CSV text, alongside the workbook_id, the workbook name, and the list of available sheets.

Result shapes

The result-bearing tools share a few nested structures. Knowing the field names helps you read what your assistant brings back, and ask it for more.

Citations and sources

Each entry in citations and all_sources describes one source: citations are the sources actually referenced in the answer. all_sources is everything Kepler consulted, whether cited or not, ordered newest period first.

Workbooks

Each workbook in a result includes:

Sourcing report

The sourcing object summarizes how much of the answer is backed by citations: Lead with this when work has to be right: it tells you, at a glance, whether an answer is fully sourced before you rely on it.
Tool names, parameters, and behavior are set by the connector and may evolve. Your assistant always sees the current definitions when it connects, so you don’t need to track changes yourself. For the canonical list, point your client at the connector and read its advertised tools.