Skip to main content
Glama
kumo-ai

KumoRFM MCP Server

Official
by kumo-ai

🤖 Running predictive query…

predict
Read-onlyIdempotent

Execute predictive queries to generate model predictions for binary, multi-class, regression, or temporal link prediction tasks without retraining.

Instructions

Execute a predictive query and return model predictions.

The graph needs to be materialized and the session needs to be authenticated before the KumoRFM model can start generating predictions.

The output prediction format depends on the given task type.

Binary classification: | ENTITY | ANCHOR_TIMESTAMP | TARGET_PRED | False_PROB | True_PROB | where 'ENTITY' holds the entity ID, 'ANCHOR_TIMESTAMP' holds the anchor time of the prediction in unix format, 'TARGET_PRED' holds the final prediction based on a threshold of 0.5, and 'False_PROB' and 'True_PROB' hold the probabilities.

Multi-class classification: | ENTITY | ANCHOR_TIMESTAMP | CLASS | SCORE | PREDICTED | where 'ENTITY' holds the entity ID, 'ANCHOR_TIMESTAMP' holds the anchor time of the prediction in unix format. Each row corresponds to an (ENTITY, CLASS) pair (up to 10 classes are reported), where 'CLASS' holds the predicted value, 'SCORE' holds its probability, and 'PREDICTED' denotes whether the (ENTITY, CLASS) pair has the highest likelihood.

Regression: | ENTITY | ANCHOR_TIMESTAMP | TARGET_PRED | where 'ENTITY' holds the entity ID, 'ANCHOR_TIMESTAMP' holds the anchor time of the prediction in unix format, and 'TARGET_PRED' holds the predicted numerical value.

Temporal link prediction: | ENTITY | ANCHOR_TIMESTAMP | CLASS | SCORE | where 'ENTITY' holds the entity ID, 'ANCHOR_TIMESTAMP' holds the anchor time of the prediction in unix format. Each row corresponds to an (ENTITY, CLASS) pair, where 'CLASS' holds the recommended item and 'SCORE' holds its likelihood.

Important: Before executing or suggesting any predictive queries, read the documentation first at 'kumo://docs/predictive-query'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe predictive query string, e.g., 'PREDICT COUNT(orders.*, 0, 30, days)>0 FOR EACH users.user_id' or 'PREDICT users.age FOR EACH users.user_id'
indicesYesThe primary keys (entity indices) to generate predictions for. Up to 1000 entities are supported for an individual query. Predictions will be generated for all indices, regardless of whether they match any entity filter constraints.
anchor_timeNoThe anchor time for which we are making a prediction for the the future. If `None`, will use the maximum timestamp in the data as anchor time. If 'entity', will use the timestamp of the entity's time column as anchor time (only valid for static predictive queries for which the entity table contains a time column), which is useful to prevent future data leakage when imputing missing values on facts, e.g., predicting whether a transaction is fraudulent should happen at the point in time the transaction was created.
run_modeNoThe run mode for the query. Trades runtime with model performance. The run mode dictates how many training/in-context examples are sampled to make a prediction, i.e. 1000 for 'fast', 5000 for 'normal', and 10000 for 'best'.fast
num_neighborsNoThe number of neighbors to sample for each hop to create subgraphs. For example, `[24, 12]` samples 24 neighbors in the first hop and 12 neighbors in the second hop. If `None` (recommended), will use two-hop sampling with 32 neighbors in 'fast' mode, and 64 neighbors otherwise in each hop. Up to 6-hop subgraphs are supported. Decreasing the number of neighbors per hop can prevent oversmoothing. Increasing the number of neighbors per hop allows the model to look at a larger historical time window. Increasing the number of hops can improve performance in case important signal is far away from the entity table, but can result in massive subgraphs. We advise to let the number of neighbors gradually shrink down in later hops to prevent recursive neighbor explosion, e.g., `num_neighbors=[32, 32, 4, 4, 2, 2]`, if more hops are required.
max_pq_iterationsNoThe maximum number of iterations to perform to collect valid training/in-context examples. It is advised to increase the number of iterations in case the model fails to find the upper bound of supported training examples w.r.t. the run mode, *i.e.* 1000 for 'fast', 5000 for 'normal' and 10000 for 'best'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
predictionsNoThe predictions, where each row holds information about the entity, the anchor time, and the prediction scores
logsNoPrediction-specific log messages such as number of context examples, the underlying task type and the label distribution
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description confirms the read-only, non-destructive nature by discussing predictions and output formats. It adds value by detailing output formats per task type, which is beyond what annotations provide, and does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a clear first sentence stating purpose, followed by prerequisites and detailed output format tables. It is somewhat long but the tables are necessary for clarity and well-organized. Front-loading the purpose and prerequisite is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, 2 required, multiple task types) and the existence of an output schema, the description provides complete context: prerequisites, output formats for all task types, and a pointer to further documentation. It sets clear expectations for the user without relying solely on structured fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The tool description does not add additional meaning beyond what the schema provides; it only mentions prerequisites and output formats. Baseline 3 is appropriate when schema covers all parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Execute a predictive query and return model predictions', specifying the verb 'execute' and the resource 'predictive query' and 'model predictions'. It distinguishes from sibling tools like 'explain' or 'evaluate' by detailing output formats for different task types (binary classification, multi-class, regression, temporal link prediction), making the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states prerequisites: 'The graph needs to be materialized and the session needs to be authenticated before the KumoRFM model can start generating predictions.' It also instructs users to 'read the documentation first at kumo://docs/predictive-query' before use. While it doesn't explicitly list when not to use this tool or alternatives, the prerequisites and doc reference provide clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kumo-ai/kumo-rfm-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server