Skip to main content
Glama
kumo-ai

KumoRFM MCP Server

Official
by kumo-ai

đŸ”„ Updating graph schema…

update_graph_metadata
Idempotent

Partially update graph metadata for RFM model setup: specify primary keys, time columns, semantic types, and foreign key links. Omitted fields remain unchanged.

Instructions

Partially update the current graph metadata.

Setting up the metadata is crucial for the RFM model to work properly. In particular,

  • primary keys and time columns need to be correctly specified for each table in case they exist;

  • columns need to point to a valid semantic type that describe their semantic meaning, or None if they should be discarded;

  • links need to point to valid foreign key-primary key relationships.

Omitted fields will be untouched.

For newly added tables, it is advised to double-check semantic types and modify in a follow-up step if necessary.

Make sure that tables are correctly linked before proceeding.

Note that all operations can be performed in a batch at once, e.g., one can add new tables and directly link them to together.

Important: Before creating and updating graphs, read the documentation first at 'kumo://docs/graph-setup'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
updateYesMetadata updates to perform for a graph holding multiple tables connected via foreign key-primary key relationships.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
graphYesMetadata of a graph holding multiple tables connected via foreign key-primary key relationships.
errorsNoAny errors encountered during the update process
Behavior3/5

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

Annotations provide idempotentHint=true, and the description's 'partial update' and 'omitted fields untouched' align with this. However, the description adds little beyond annotations—no mention of destructive potential or rate limits. Since annotations cover idempotency, a 3 is appropriate.

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 bullet points and sections, front-loading the core action. It is somewhat lengthy but each sentence adds information. Could be trimmed slightly without loss, but overall well-organized.

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 (nested objects, multiple operations), the description covers all aspects: adding/updating/removing tables and links, semantic types, and references to documentation. Output schema exists, so return values need not be detailed. The description is thorough and leaves no major gaps.

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

Parameters4/5

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

Schema coverage is 100%, but the description adds value by explaining the significance of metadata (RFM model), the role of semantic types, and procedural advice (batch operations, follow-up steps). It supplements the schema's detailed property descriptions with contextual meaning.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Partially update the current graph metadata.' It lists key operations like updating primary keys, time columns, semantic types, and links. However, it does not explicitly distinguish from sibling tools like inspect_graph_metadata or materialize_graph, though the action is inherently different.

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

Usage Guidelines3/5

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

The description includes guidance: metadata is crucial for RFM model, advises double-checking semantic types, ensuring tables are linked, and references documentation. But it lacks explicit instructions on when not to use this tool or what alternatives exist (e.g., using inspect first). The advice is useful but not comprehensive.

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