Back to tracker
Plugin tracker
Tools
Explore what tracked Claude Connectors and ChatGPT Plugins can actually do. Search by tool, Plugin, Brand, category, verb, or access requirement.
Latest snapshot2026-09-12USmethodology registry-public-v1
Searchable tools
113,018
Authless tools
7,424
Auth required
100,766
Described tools
61,167
113,018 tools
- Compose revealed Codex readingcompose · Used only by the Oracle widget to compose a selected reading form from an already revealed server-side session.The Altiora Codex OracleDimensional Frequency
PluginrequiredConsumer & Lifestyle - Get revealed Altiora Codex reading resultget · Used only by the Oracle widget to load the automatically revealed cards for its current server-side session.The Altiora Codex OracleDimensional FrequencyPluginrequiredConsumer & Lifestyle
- Reveal chosen Codex cardsreveal · Used only by the Oracle widget to reveal selected positions from an already shuffled session. Do not call this after the user says the cards are chosen.The Altiora Codex OracleDimensional FrequencyPluginrequiredConsumer & Lifestyle
- Start Altiora Codex readingstart · Start one, three, or five unique Altiora Codex cards only for non-directive spiritual reflection or personal development. The Oracle supports exactly 1, 3, or 5 cards. If the user requests any other number of cards, do not simulate, reinterpret, construct, or suggest an alternative spread. State briefly that only 1-, 3-, and 5-card readings are available and ask the user to choose one of those options. Never call this tool when the user asks a card to diagnose or explain health or psychological symptoms, change medication or treatment, provide legal advice, choose an investment or make another financial decision, guarantee a prediction, or replace qualified professional guidance. For those requests, do not start a session; state the boundary and invite a safe, open reflective reformulation. This tool does not accept or store the user's personal question. For an eligible request, call exactly once. A loading_cards result is successful and must never be retried: the Oracle widget completes the reading independently. An identical technical retry within 60 seconds is handled only as a safety fallback. Cards are always drawn without replacement.The Altiora Codex OracleDimensional FrequencyPluginrequiredConsumer & Lifestyle
- Verwijder mijn tijdelijke Oracle-gegevensdelete · Permanently delete all current server-side Oracle sessions, selected cards, generated readings, caches, and export links belonging to the authenticated user. Only call this after the user explicitly requests deletion and confirms with the exact phrase.The Altiora Codex OracleDimensional FrequencyPluginrequiredConsumer & Lifestyle
- Analyze bank statementsanalyze · Use when the user asks to analyze bank statements, trace money, or review financial transactions in a Mary matter (a bank statement analysis in Mary). The run reads the matter's financial documents and builds a table of transactions, each citing the statement page it came from. The query describes the requested analysis — name the accounts, bound the period, and state the thresholds or counterparties of interest. The read_mary_guide topic 'financial-analysis' has fuller query guidance and examples.
Successful completion creates a persistent financial-analysis workspace in Mary; runs can take several minutes. It does not modify the matter's source documents.
Each invocation is a non-destructive write to the authenticated user's private Mary account: it adds an assistant turn to the conversation and starts asynchronous processing. Omitting conversation_id creates a new conversation; providing it continues that conversation. reference_document_ids, when provided, limits the source documents used.
The initial response contains a run_id. assistant_wait_for_run returns the run's status and eventual result. A run may return an elicitation_request containing follow-up questions for the user. assistant_reply_to_elicitation submits the user's answers and continues the run; its elicitation_response.messageId must match the request's messageId.MaryMary TechnologyPluginrequiredOperations
- Answer Mary's questionsassistant · Submits the user's answers to an elicitation_request and continues the run. It takes the run_id of the run that returned the elicitation_request and returns a new run_id, whose result is retrieved with assistant_wait_for_run. The elicitation_response.messageId must equal elicitation_request.messageId (required). answers holds one item per question, keyed by questionId, with option ids in selectedOptionIds and other input types in the matching typed value field. message is the optional short user-visible confirmation text.MaryMary TechnologyPluginrequiredOperations
- Audit trailget · Get the audit and review history for one workspace entry.
Use artifact_id from search_workspaces and item_id from get_workspace
or query_workspace (item_id is returned as each row's itemId). The
optional action and category arguments narrow the timeline to one
audit action or category. The result includes who acted, when it
happened, review notes, and before/after field changes.
This tool displays nothing by itself; it returns the timeline plus a
task_id. When an interactive timeline would help the user inspect the
result, call render_search_results with that task_id. Skip rendering
when this call is only supporting internal research, reasoning, or
another intermediate tool call. The renderer shows a read-only
timeline consistent with Mary's entry-history view.MaryMary TechnologyPluginrequiredOperations
- Create chronologycreate · Use when the user asks to generate a chronology — a timeline of events — from the documents in a Mary matter. A chronology is Mary's table of dated events extracted from the matter's uploaded documents, each entry citing the source document and page it came from. Despite the name, it also builds other generic tables from the documents — a dramatis personae of the people and parties, a schedule of documents, an issues table — when the query asks for one. The query describes the requested scope, focus, and formatting: bound it by date range, documents, or issue and name the columns wanted, or leave it broad for a general chronology of the matter. The read_mary_guide topic 'chronologies' has fuller scoping guidance and examples.
Successful completion creates a persistent chronology workspace in Mary that the team can review, filter, and export; runs can take several minutes. It does not modify the matter's source documents.
Each invocation is a non-destructive write to the authenticated user's private Mary account: it adds an assistant turn to the conversation and starts asynchronous processing. Omitting conversation_id creates a new conversation; providing it continues that conversation. reference_document_ids, when provided, limits the source documents used.
The initial response contains a run_id. assistant_wait_for_run returns the run's status and eventual result. A run may return an elicitation_request containing follow-up questions for the user. assistant_reply_to_elicitation submits the user's answers and continues the run; its elicitation_response.messageId must match the request's messageId.MaryMary TechnologyPluginrequiredOperations
- Document indexget · List the document index for a matter by matter name.
The document index is Mary's split-and-categorised list of what is
actually inside the matter's uploaded files: each source file (often
a large PDF bundle) is broken into the individual documents Mary
detected inside it — each with a title, one-line description,
document type, date, page range, source file, and relevance rating.
Use it to answer "what documents do we have?" for a matter.
This tool displays nothing by itself; it returns the index plus a
task_id. When an interactive, searchable table would help the user
inspect the result, call render_search_results with that task_id.
Skip rendering when this call is only supporting internal research,
reasoning, or another intermediate tool call. The rendered view
matches the Mary web app's Document index page.MaryMary TechnologyPluginrequiredOperations
- Draft documentdraft · Use when the user asks to draft a document — a letter of advice, case outline, letter of instruction, letter of claim, or similar — from the materials in a Mary matter. The query supplies the drafting instructions; Mary drafts best from explicit headings (e.g. 'a letter of advice with the headings: Background facts; Executive summary; Liability; Quantum; Next steps'), plus the audience and length. template_id selects one of the firm's templates (list them with get_draft_templates), while omitting template_id produces a free-form draft. The read_mary_guide topic 'drafting' has the full heading patterns and common letter types.
Successful completion creates a persistent draft in Mary — a document grounded in the matter's record with citations back to source documents. It does not modify the matter's source documents.
Each invocation is a non-destructive write to the authenticated user's private Mary account: it adds an assistant turn to the conversation and starts asynchronous processing. Omitting conversation_id creates a new conversation; providing it continues that conversation. reference_document_ids, when provided, limits the source documents used.
The initial response contains a run_id. assistant_wait_for_run returns the run's status and eventual result. A run may return an elicitation_request containing follow-up questions for the user. assistant_reply_to_elicitation submits the user's answers and continues the run; its elicitation_response.messageId must match the request's messageId.MaryMary TechnologyPluginrequiredOperations
- Draft templatesget · List the draft templates available for a matter.
Draft templates are your organisation's reusable drafting templates,
automatically scoped to the matter's practice area. Use this to answer
"which templates are available?" or to resolve a template the user names
before drafting.
Each result has a templateId and name. To write from a template, pass its
templateId to draft_document as template_id. An empty list means no
template is configured for this matter — write the draft free-form (call
draft_document without a template_id).MaryMary TechnologyPluginrequiredOperations
- Export workspaceexport · Export the complete workspace as a downloadable DOCX or XLSX file.
A workspace (previously called an artifact or task) is a generated output
such as a chronology or a financial/bank-statement analysis. Use
artifact_id from search_workspaces. This always exports the full
workspace — unlike the Mary web app's "Current view" export, no
search, filters, sorting, or row selection are applied. A fresh
server-side export is generated on every call. XLSX is the default;
DOCX produces a Word document, the usual choice for chronologies and
drafts.
The result is a temporary, signed download URL for the generated
DOCX/XLSX file — a binary document meant to reach the user as a
download link.MaryMary TechnologyPluginrequiredOperations
- Fact Explorerask · Use when the user asks a factual question about the documents in a Mary matter — 'did X ever…', 'what do the records show about…', 'summarise the key issues'. This is Mary's Fact Explorer: it reads the matter's uploaded documents and answers in plain language, citing the facts and source documents behind each point. Specific questions get better answers — name the people, dates, and topics, and say what shape the answer should take (a table, a list in date order, chosen columns). It can also produce one-off custom chronology tables scoped by date range, document, or issue. The read_mary_guide topic 'fact-explorer' has fuller phrasing guidance and question patterns.
The completed run returns a source-grounded answer with citations. It does not modify source documents or create a workspace. Fact Explorer is only available on matters created on or after 20 November 2025.
Each invocation is a non-destructive write to the authenticated user's private Mary account: it adds an assistant turn to the conversation and starts asynchronous processing. Omitting conversation_id creates a new conversation; providing it continues that conversation. reference_document_ids, when provided, limits the source documents used.
The initial response contains a run_id. assistant_wait_for_run returns the run's status and eventual result. A run may return an elicitation_request containing follow-up questions for the user. assistant_reply_to_elicitation submits the user's answers and continues the run; its elicitation_response.messageId must match the request's messageId.MaryMary TechnologyPluginrequiredOperations
- Get document index pageget · Fetch one page of the document index for the search-results app UI.
Backend tool for the widget's server-side quick search: document_id
comes from the rendered payload, so no matter re-resolution is
needed, and the structured content is the same envelope the stored
``get_document_index`` result uses (documents, total, documentId) —
no task id is minted. Not addressed to the model — it is hidden
behind ``ui.visibility: ["app"]``.MaryMary TechnologyPluginrequiredOperations
- Get file previewget · Mint a short-lived signed URL for one source document's PDF.
Backend tool for the workspace widget's PDF viewer: document_id comes
from the rendered payload, file_id from a citation or the documents
list. The link expires after about 10 minutes — the widget re-calls
this on a failed load rather than caching links. Not addressed to the
model — it is hidden behind ``ui.visibility: ["app"]``.MaryMary TechnologyPluginrequiredOperations
- Get matters pageget · Fetch one page of matching matters for the search-results app UI.
Backend tool for the widget's server-side quick search: it returns
the same payload envelope the stored ``search_matters`` result uses
(matters, totalCount, page, searchName, maryUrl) directly in the
structured content — no task id is minted. Not addressed to the
model — it is hidden behind ``ui.visibility: ["app"]``.MaryMary TechnologyPluginrequiredOperations
- Get workspaceget · Get one workspace of a matter: its details and its rows, in one call.
A workspace (previously called an artifact or task) is a generated
output such as a chronology or a financial/bank-statement analysis.
Use artifact_id from search_workspaces. This tool returns the workspace
summary, source-document usage, and review-flag counts TOGETHER WITH
the first page of matching rows — no separate details or search call
is needed.
IMPORTANT: this tool does not display anything by itself. It returns a
task_id. When an interactive view would help the user inspect the
result, call render_workspace with that task_id. Skip rendering when this
call is only supporting internal research, reasoning, or another
intermediate tool call. Table workspaces retain the interactive rows
view and details tabs; draft workspaces render as a read-only Markdown
page with clickable citations and no details tab.
Every argument beyond the ids is optional — call with none of them to
see the workspace and browse the first page of rows, discovering the
column keys (each row's `data` is keyed by column key). Each row also
includes itemId; pass it as item_id to get_audit_trail. Then narrow:
- search: free-text, case-insensitive match over the row's text columns
(e.g. event / description); not dates, numbers, filenames, citations.
- filters: a list of {field_key, op, value} rules (see ArtifactFilter),
combined with join_operator ("and" by default; "or" to widen).
- sort_by / sort_order: order by a column key, ascending or descending.
- limit / cursor: page size (max 100) and the rows nextCursor of a
prior call.
Field keys:
- Data columns use their own key (from an unfiltered call's row `data`),
e.g. a chronology commonly uses "date" and "event". Always use the
exact key returned for this workspace; do not infer a key from its
label or from another workspace.
- "citation.file_id" filters by cited source file; the value is a file
id (or list) from this tool's documents used list.
- "annotation.type" filters by review flag; the value is a flag type
(or list) from this tool's annotations, e.g. "gap".
- "review_status" filters by review state; values are "verified",
"needs_review", and "unverified" (rows never reviewed). Use the
"in" op.
Citation and annotation fields support the "eq" and "in" ops.
Examples (showing the args you pass):
- Free text:
search="wire transfer"
- One value:
filters=[{"field_key": "event_type", "op": "eq", "value": "payment"}]
- Any of several values:
filters=[{"field_key": "event_type", "op": "in",
"value": ["payment", "invoice"]}]
- Substring match:
filters=[{"field_key": "description", "op": "contains", "value": "Ltd"}]
- Date / number range:
filters=[{"field_key": "date", "op": "range",
"value": {"gte": "2026-01-01", "lte": "2026-03-31"}}]
- Rows citing a specific source file:
filters=[{"field_key": "citation.file_id", "op": "in",
"value": ["doc-005", "doc-012"]}]
- Rows carrying a specific review flag:
filters=[{"field_key": "annotation.type", "op": "eq",
"value": "contradiction"}]
- Rows not yet verified by a reviewer:
filters=[{"field_key": "review_status", "op": "in",
"value": ["needs_review", "unverified"]}]
- Widen with OR, then sort and page:
filters=[...], join_operator="or", sort_by="date",
sort_order="asc", limit=50 # then pass cursor=<nextCursor>MaryMary TechnologyPluginrequiredOperations
- Get workspace rowsget · Fetch one page of workspace rows for the workspace app UI.
Backend tool for the widget's progressive loading: document_id comes
from the rendered payload, so no matter re-resolution is needed. Not
addressed to the model — it is hidden behind ``ui.visibility: ["app"]``.MaryMary TechnologyPluginrequiredOperations
- Mary guideread · Read the built-in guide to working with Mary through these tools.
Call it without a topic for the table of contents, then with a topic
slug for that page. Consult it when unsure how to phrase a generation
query, what a Mary term means, how relevance/review works, or how to
build links into the Mary web app (topic "linking"). Content is
served by this server itself: reading it consumes no Mary credits and
touches no matter data.MaryMary TechnologyPluginrequiredOperations
- Matter summaryget · Get the contextual summary of a matter by matter name.
The matter summary is the standing description of the case in Mary —
its Overview, Key Issues, People & parties, Entities, and Additional
Notes sections. Mary scores every extracted fact against it (the
relevance ratings), so it reflects the team's current case theory.
Use it to orient on what a matter is about before deeper work such as
searching the workspace, drafting, or asking Fact Explorer. It can
only be edited in the Mary web app.
Returns the summary plus its revision number. A null summary means
none has been written yet; legacy matters may return the summary as a
single block of text instead of sections.MaryMary TechnologyPluginrequiredOperations
- Query workspacequery · Search, filter, sort, and page the rows inside one workspace of a matter.
A workspace (previously called an artifact or task) is a generated output
such as a chronology or a financial/bank-statement analysis; this tool
queries the rows inside one and returns just the matching page. Backed
by the Mary artifact query API
(POST /api/mcp/matters/{matterId}/tasks/{artifactId}/query). Use
get_workspace instead when you also want the workspace's details
(summary, source documents, review flags) alongside the rows.
IMPORTANT: this tool displays nothing by itself. It returns the data
plus a task_id. When an interactive rows table would help the user
inspect the result, call render_workspace with that task_id. Skip rendering
when this call is only supporting internal research, reasoning,
pagination, or another intermediate tool call.
Use artifact_id from search_workspaces. Every argument beyond the ids is
optional — call with none of them to browse the first page and discover
the column keys (each row's `data` is keyed by column key). Each row also
includes itemId; pass it as item_id to get_audit_trail. Then narrow:
- search: free-text, case-insensitive match over the row's text columns
(e.g. event / description); not dates, numbers, filenames, or citations.
- filters: a list of {field_key, op, value} rules (see ArtifactFilter),
combined with join_operator ("and" by default; "or" to widen).
- sort_by / sort_order: order by a column key, ascending or descending.
- limit / cursor: page size (max 100) and the `nextCursor` of a prior page.
Field keys:
- Data columns use their own key (from an unfiltered query's `data`),
e.g. a chronology commonly uses "date" and "event". Always use the
exact key returned for this workspace; do not infer a key from its
label or from another workspace.
- "citation.file_id" filters by cited source file; the value is a file id
(or list) from get_workspace (workspace.documents.used[].id).
- "annotation.type" filters by review flag; the value is a flag type (or
list) from get_workspace (workspace.annotations[].type), e.g. "gap".
- "review_status" filters by review state; values are "verified",
"needs_review", and "unverified" (rows never reviewed). Use the
"in" op.
Citation and annotation fields support the "eq" and "in" ops.
Examples (showing the args you pass):
- Free text:
search="wire transfer"
- One value:
filters=[{"field_key": "event_type", "op": "eq", "value": "payment"}]
- Any of several values:
filters=[{"field_key": "event_type", "op": "in",
"value": ["payment", "invoice"]}]
- Substring match:
filters=[{"field_key": "description", "op": "contains", "value": "Ltd"}]
- Date / number range:
filters=[{"field_key": "date", "op": "range",
"value": {"gte": "2026-01-01", "lte": "2026-03-31"}}]
- Rows citing a specific source file:
filters=[{"field_key": "citation.file_id", "op": "in",
"value": ["doc-005", "doc-012"]}]
- Rows carrying a specific review flag:
filters=[{"field_key": "annotation.type", "op": "eq",
"value": "contradiction"}]
- Rows not yet verified by a reviewer:
filters=[{"field_key": "review_status", "op": "in",
"value": ["needs_review", "unverified"]}]
- Widen with OR, then sort and page:
filters=[...], join_operator="or", sort_by="date",
sort_order="asc", limit=50 # then pass cursor=<nextCursor> for page 2MaryMary TechnologyPluginrequiredOperations
- Render search resultsrender · Display a previously fetched browse result as an interactive view.
Pass the task_id returned by search_matters, search_workspaces,
get_document_index, get_audit_trail, or get_sources; the view matches
the tool that produced it — a matter or workspace table mirroring the
Mary web app's list pages (quick search, sortable columns, status
pills, per-row deep links), the document-index table (date, title,
description, type, source file, and relevance, like Mary's Document
index page, where clicking a source file opens its PDF side-by-side),
the sources table (file name, pages, upload date, and status, like
Mary's Sources tab), or the entry-history audit timeline — with a
fullscreen control for viewing everything. Call this when the
interactive view would help the
user inspect the result. Do not call it when the data is only supporting
internal research, reasoning, pagination, ID resolution, or another
intermediate tool call. Results are kept for about an hour.MaryMary TechnologyPluginrequiredOperations
- Render workspacerender · Display a previously fetched task result as an interactive app view.
Pass the task_id returned by get_workspace or query_workspace; the
view matches the tool that produced it. A get_workspace task renders
either the established rows table with its original details tab or,
for a draft workspace, a read-only Markdown document with clickable
citation PDFs and no details tab. A query_workspace task always
renders the rows table scoped to the query. Call this renderer
when the interactive view would help the user inspect the result. Do
not call it when the data is only supporting internal research,
reasoning, pagination, or another intermediate tool call. Results are
kept for about an hour.MaryMary TechnologyPluginrequiredOperations
- Search matterssearch · Search your matters by name. Returns matching matter names and metadata.
A matter is Mary's case file: it holds the documents uploaded for a
case and everything generated from them (chronologies, analyses,
drafts). Each matter includes its name, id, firm matter ID,
contributors, creation date, and status. Leave name empty to list
your most recent matters. Results are paged: when totalCount exceeds
the matters returned, call again with page=2, 3, … and the same
name. Pass a
returned matter name to the other Mary tools (search_workspaces,
create_chronology, ask_fact_explorer, …) to work inside that matter.
This tool displays nothing by itself; it returns the data plus a
task_id. When an interactive list would help the user inspect the
result, call render_search_results with that task_id. Skip rendering
when the search is only supporting internal research, pagination, ID
resolution, or another intermediate tool call.MaryMary TechnologyPluginrequiredOperations
- Search workspacessearch · List the workspaces for a matter (chronologies, analyses, drafts).
A workspace — sometimes referred to as a task or artifact — is a
generated output inside the matter: a chronology (timeline of dated,
cited events), a bank-statement/financial analysis (transaction
table), or a draft document. Returns each workspace's name, id, type,
creator, creation date, and status. Use the returned artifact_id with
get_workspace to load any single workspace and its rows.
This tool displays nothing by itself; it returns the data plus a
task_id. When an interactive list would help the user inspect the
result, call render_search_results with that task_id. Skip rendering
when this call is only supporting internal research, ID resolution,
or another intermediate tool call.MaryMary TechnologyPluginrequiredOperations
- Set workspace item reviewset · Mark one workspace row verified, or send it back to needs-review.
Backend tool for the workspace widget's reviewed/undo control:
document_id and artifact_id come from the rendered payload, item_id
from the row. Not addressed to the model — it is hidden behind
``ui.visibility: ["app"]``.MaryMary TechnologyPluginrequiredOperations
- Sourcesget · List the source documents uploaded to a matter, by matter name.
Sources are the files the matter is built from — every chronology
entry, fact, and analysis cites back to them. Each source includes
its file name, page count, upload date, processing status, and
whether it was a manual entry (a source the user recorded without a
file, e.g. a phone call). Use it to answer "what files have we
uploaded?" for a matter; for what Mary detected *inside* those
files, use get_document_index instead. Results are paged: when
total exceeds the sources returned, call again with page=2, 3, …
and the same matter_name.
This tool displays nothing by itself; it returns the source list
plus a task_id. When an interactive, searchable table would help the
user inspect the result, call render_search_results with that
task_id. Skip rendering when this call is only supporting internal
research, reasoning, or another intermediate tool call. The rendered
view matches the Mary web app's Sources tab.MaryMary TechnologyPluginrequiredOperations
- Wait for Mary runassistant · Polls a Mary assistant run until it is terminal or a bounded timeout expires.
It takes the run_id returned by ask_fact_explorer, create_chronology,
analyze_bank_statements, or draft_document. Completed responses include the
answer, artifact ids, generated outputs, and any elicitation request; a
run still in progress is returned as running and polled again on the next
call — generation runs commonly take several minutes, so repeated
calls are normal. When the result carries an elicitation_request, the
attached Mary card walks the user through the questions, submits
their answers, and
tracks the continued run to completion itself, recording the outcome in
the model context when the user finishes.MaryMary TechnologyPluginrequiredOperations
- fetch_ensembl_sequencefetch · Fetch a gene's reference sequence from Ensembl and store it.
Returns a handle ({ref, name, length, preview, ...}). Pass the
`ref` to predict_* tools — the bases stay server-side. For
expression, use fetch_gene_for_expression instead (it prepares
the TSS-centred window that model needs).Genomic IntelligenceGenomic IntelligencePluginnoneAI
- fetch_gene_for_expressionfetch · Fetch a gene's sequence prepared for expression prediction.
Resolves the gene's TSS via Ensembl and returns the exact
TSS-centred 9,198 bp window the expression model scores, as a handle
to pass to predict_expression(sequence_ref=...). Because the window is
exactly 9,198 bp, no `tss_index` is needed on that call.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- fetch_regionfetch · Fetch a genomic region by coordinates from Ensembl and store it.
For "find the genes in chr8:127,680,000-127,800,000"-style requests:
resolves a coordinate range to reference sequence and returns a handle
({ref, name, length, ...}) to pass to find_genes / predict_* — the bases
stay server-side. Plus strand by default, which is what the gene-finder
expects. For a gene by name use fetch_ensembl_sequence; for expression
use fetch_gene_for_expression.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- find_genesfind · Find genes (transcript intervals) in a genomic region (async, ~8-25s).
Gene-finding: detects transcript boundaries (TSS + PolyA) and returns
one interval per predicted transcript — start/end, strand, a
confidence score, and predicted TSS/PolyA positions (BED-style feature
intervals, not free-text notes). Use this for "what genes are here",
"find / locate genes", or "annotate this region".
Each transcript also carries its type (mRNA/lnc_RNA) and internal
exon/intron/CDS structure in `exons`/`introns`/`cds` arrays, plus a
browser-ready GFF3 track in `data.formats.gff3`. To get each gene's
*expression* from a raw region, use find_genes_and_predict_expression
instead — expression needs a per-gene TSS window, so predict_expression
cannot run on a whole region.
Submits an async job internally. With wait=True (default), blocks and
streams progress, then returns the result {data, meta} — it never
returns a job_id on this path. (If a generous block ceiling is
exceeded it returns a timeout error, not a job handle.) With
wait=False (detached), returns {data: {job_id, status: 'submitted'}}
immediately — poll it with get_job.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- find_genes_and_predict_expressionfind · Find genes in a sequence, then predict each gene's expression (composite).
Server-side chaining in ONE call: finds genes (transcript intervals,
with their TSS) in the sequence, then predicts expression off each
discovered TSS in the given experimental context. This is the right
tool whenever you want expression for a raw region or sequence — e.g.
"find the genes in chr8:… and predict their expression in K562". You
cannot call predict_expression on a whole region, because it needs a
single per-gene 9,198 bp TSS window; this tool handles that for you.
Runs async internally at every size (the annotate stage is slow even
for small inputs), so progress always streams. With wait=True
(default), blocks and streams progress, then returns the result
{data, meta} — it never returns a job_id on this path. With wait=False
(detached), returns {data: {job_id, status: 'submitted'}} immediately —
poll it with get_job. Because it ends in expression, `description`
(cell type / assay context) is REQUIRED.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- get_jobget · Poll an async job once.
Returns the {data, meta} result if complete, a progress envelope
if still running, or an error envelope if it failed.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- list_jobslist · List the caller's recent async jobs (also available as gi://jobs/recent).Genomic IntelligenceGenomic IntelligencePluginnoneAI
- list_modelslist · List available models for a task.
Use to discover model ids before passing one as the `model`
argument to a predict tool. The same catalog is also available
as the resource `gi://models`.
Returns a FLAT object — {task, default_model, models: [...]} — not the
{data, meta} envelope the predict tools return. Each model carries a
`bio_spec`, whose useful fields are `request_max_bp` (the enforced
ceiling, 500,000 everywhere) and `context_window_bp` (what the model
reads in one step — compare your sequence length against it: a shorter
one is scored against a padded window). `trained_window_bp` is the fixed
receptive field where there is no sliding window (9,198 for
g0-expression). `request_max_bp` is the only one of the three that is a
cap; the window fields describe what the model scores, not what the
route accepts.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- load_demo_sequenceload · Load a bundled demo reference sequence and return a handle.
The server ships one curated, task-correct positive control per task
(list them via the gi://sequences resource) — e.g.
`expression_hbb_k562` is a ready-to-use K562 expression window for
predict_expression. Stores the demo and returns a handle to pass to a
predict_* tool: no Ensembl fetch, no quota. Handy for smoke-testing a
prediction end-to-end.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- predict_chromatinpredict · Chromatin annotation across 919 features (G0 DeepSEA). 200–500,000 bp.
The model reads a 1,000 bp context window; 200–999 bp is accepted and
scored against a padded window.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- predict_enhancerpredict · Predict enhancer activity (G0 DeepSTARR). 50–500,000 bp.
50 bp is the task's admission floor (the API 422s below it), not a
statement about what the model reads: enhancer models score a 249 bp
context window, so 50–248 bp is accepted and scored against a padded
window. For a meaningful call, submit at least the 249 bp context.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- predict_expressionpredict · Predict a gene's expression from a TSS-centred window.
Expression is cell-type-specific, so `description` (cell type /
assay context, e.g. 'K562 cell line') is REQUIRED — the API
rejects requests without it.
The model scores exactly 9,198 bp centred on the TSS (±4,599). Two
ways to supply that:
- A sequence of exactly 9,198 bp already centred on the TSS. No
`tss_index` needed — the midpoint is the only legal TSS.
- A longer locus, 9,198–500,000 bp, plus `tss_index`: the 0-based
offset of the TSS into it. The API cuts the window for you
(sequence[tss_index-4599 : tss_index+4599]) and never scans for a
TSS itself.
Anything under 9,198 bp is rejected, here and by the API (422) —
there is no padding or truncation fallback. `tss_index` is required
for every other length, because a locus with no offset is
indistinguishable from a mis-centred window.
An offset that is merely WRONG (e.g. counted over a wrapped FASTA's
characters, or against a chromosome coordinate instead of an offset
into THIS sequence) still succeeds and scores the wrong window —
verify meta.task_specific_counts.scored_window in the response.
Easiest paths: fetch_gene_for_expression(gene) returns a
ready-centred handle, and find_genes_and_predict_expression takes a
raw region and finds each TSS for you.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- predict_promoterpredict · Predict promoter regions (G0). 300–500,000 bp.
Returns the {data, meta} envelope: data.regions lists predicted
promoters with start/end/score.
300 bp is the task floor for every promoter model. The default
g0-promoter-2000bp scans a 2,000 bp context window, so a shorter
(but ≥300 bp) sequence is still scored — against a window padded out
to that size. Check the chosen model's bio_spec.context_window_bp via
list_models to know whether it saw real sequence or padding.Genomic IntelligenceGenomic IntelligencePluginnoneAI
- predict_splicepredict · Predict splice donor/acceptor sites (G0 BigBird). 100–500,000 bp.
The model reads a 15,000 bp context window, so anything shorter is
scored against a padded window — feed a whole transcript locus when you
can. It is also strand-specific, and the wrong strand fails silently and
plausibly — it returns sites at different positions, often still scoring
above 0.9, not the near-zero scores once documented here. Nothing in the
response flags it, so submit the transcript's own orientation
(fetch_region takes `strand`).Genomic IntelligenceGenomic IntelligencePluginnoneAI
- store_inline_sequencestore · Store a human-pasted sequence and return a handle to re-use it.
For a sequence you've already pasted into the conversation, this
gives back a short handle so you can run several tasks on it
without re-pasting the bases in each predict_* call. Note that the
full sequence still passes through the LLM on THIS call — it does
not save context on its own. For large sequences, prefer
fetch_ensembl_sequence / fetch_gene_for_expression / load_local_fasta,
which acquire the bases server-side and never round-trip them.
A line-wrapped FASTA *body* may be pasted verbatim: whitespace is
stripped before storing, so the handle's `length` counts bases and a
later `tss_index` counts into the same string the API measures. (A
FASTA `>` header line is not a sequence and is rejected by the API's
alphabet check.)Genomic IntelligenceGenomic IntelligencePluginnoneAI
- Get Matchget · Read the current redacted state of an existing Domono quick round.DomonoGhanem Artificial Intelligence TechnologyPluginnoneConsumer & Lifestyle
- Pass Turnpass · Pass the human turn only when the returned match state says can_pass is true.DomonoGhanem Artificial Intelligence TechnologyPluginnoneConsumer & Lifestyle
- Play Tileplay · Play one listed legal tile for the human seat in a Domono quick round.DomonoGhanem Artificial Intelligence TechnologyPluginnoneConsumer & Lifestyle
- Start Matchstart · Start one anonymous Egyptian dominoes round against Domo.DomonoGhanem Artificial Intelligence TechnologyPluginnoneConsumer & Lifestyle
- Search propertiesproperty · Search propertiesPKB ImmobilienPKB ImmobilienPluginnoneOperations
- export_loyalty_contactsexport · Export loyalty program contacts with unmasked phone numbers. Returns personal data. The stored consent covers the loyalty program terms, not marketing; use the consent fields to filter. Every call is recorded in the company audit log.EscapeTabEscapeTabPluginrequiredOperations
What is Tool Explorer?
Tool Explorer indexes the callable tool names and descriptions attached to public registry profiles. It is useful for seeing what agents can actually invoke, not just which profile exists.
How do category and verb filters work?
Category filters use the live registry category rollup. Verb filters use the public tool insights rollup, so the page stays backed by the same read models as the tracker charts.
Why do auth requirements matter?
Auth requirements show whether a tool is likely usable without account connection, requires authentication, is private, or is unknown in the current snapshot.