Toolbelt

A collaborative substrate for your agents.

От сообществаРаботаетБез входаГлобальныйБесплатноТолько чтение

Что умеет

  • Toolbelt List Namespaces: List all namespaces the user has access to, ordered by most recent activity (descending) so the first entry is the best default pick. When to call: - The connection URL is th
  • Toolbelt Create Namespace: Create a new namespace owned by the authenticated user. Use when an agent needs a fresh workspace for ingesting documents or tables. The returned namespace_id can be passed
  • Toolbelt Share: Generate a shareable download/view link for an asset in the namespace. Use this when the user asks to "share", "export", "send a link to", or "make downloadable" any data or document i

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

A collaborative substrate for your agents. Your data. Your agents. One shared brain.

Toolbelt is a collaborative substrate over your data. Discover documents, structured data, events, entities, and relationships across agents and sessions. Better answers. Fewer tokens. Curated context, not raw access.

Three things make it different

  • Knowledge extraction. Upload any document — entities and relationships extracted automatically, queryable immediately.
  • Hybrid retrieval. Ask questions that span structured tables, documents, and relationships in a single call. No stitching databases together. Orchestrates semantic, structured, and hybrid retrieval.
  • Shared workspaces. Share the URL and any agent can query the same workspace — like a shared Google Doc for your data.

Quick start

Free anonymous account auto-provisions on first connect — no signup required. Connect via the MCP URL with a bearer token from https://app.toolbelt.ai/api/onboard.

Or install the skill directly:

```bash npx @toolbeltai/skills install ```

Links

Список инструментов сервера (30)

Технические названия из tools/list. Нужны только разработчикам.

toolbelt_list_namespacesList all namespaces the user has access to, ordered by most recent activity (descending) so the first entry is the best default pick. When to call: - The connection URL is the bare /mcp form (no namespace embedded) and you need a namespace_id to pass to other tools. - The user explicitly asks to see or switch namespaces. Don't call it on every tool invocation — cache the result for the conversation. If the connection URL embeds a namespace (/ns/{namespace_id}/mcp), you already have the id in context and don't need this tool. Returns: List of dicts: { "namespace_id": "uuid-string", "name": "Display Name", "description": "…", "last_activity_at": "2026-04-22T12:34:56Z" | null }
toolbelt_create_namespaceCreate a new namespace owned by the authenticated user. Use when an agent needs a fresh workspace for ingesting documents or tables. The returned namespace_id can be passed to toolbelt_save, toolbelt_register_asset, toolbelt_connect, and other namespace-scoped tools. Requires an account-level MCP connection (bare /mcp URL). Refuses if called from a namespace-scoped or token-scoped connection. Most callers should pass only `name`. Model and strategy fields fall back to system defaults at creation time; once created, the namespace owns its configuration. Args: name: Display name, 1 to 100 chars. Required. description: Optional description, up to 1000 chars. llm_id: UUID of a specific LLM model. Omit for system default. embedding_id: UUID of a specific embedding model. Omit for default. sql_context_names: Optional Kinetica SQL contexts to attach. text_to_sql_strategy: 'native' or 'llm'. Atlas default is 'llm'. Returns: { "namespace_id": "<uuid>", "name": "...", "description": "..." | None } Note: KG initialization runs asynchronously after this call returns. Operations that depend on the KG (graph queries, entity extraction) may briefly fail until init completes; poll toolbelt_context or toolbelt_jobs if you need to gate on readiness.
toolbelt_shareGenerate a shareable download/view link for an asset in the namespace. Use this when the user asks to "share", "export", "send a link to", or "make downloadable" any data or document in their namespace. Requires an asset_id: 1. To share an existing asset (table or document already in the namespace): call toolbelt_context(namespace_id) to list assets with their IDs, then pass the matching ID here. 2. To share query results or newly generated content: first call toolbelt_save() to persist the data (returns an asset_id), then call toolbelt_share() with that asset_id. For relational assets the data is automatically exported to a downloadable file (CSV/Parquet). For document assets a direct download link is returned. Args: namespace_id: The UUID of the namespace (get from toolbelt_list_namespaces) asset_id: The UUID of the asset to share. Get this from toolbelt_context (existing assets) or from the result of toolbelt_save (newly saved data). expiresInDays: Number of days until the link expires (1-365, default 7) Returns: A formatted string with the share URL, expiration date, asset type, and row count (for relational assets).
toolbelt_saveSave an asset to a user's namespace. For document assets: Uploads files (PDF, TXT, etc.) to KIFS storage. For relational assets: Ingests tabular data (JSON array or CSV) into a Kinetica table, or uploads a local file (CSV, Parquet, etc.) via file_path. For short prose findings, decisions, or observations worth keeping on the namespace timeline, use toolbelt_record instead — that's a memory write, not an asset write. Args: asset_type: Type of asset - "document" for files, "relational" for tabular data. The type is also inferred from the file extension: csv/json/jsonl/avro/parquet are always saved as relational; all other extensions are saved as document. If the provided asset_type conflicts with the file extension, the extension wins. name: Asset name (becomes table name for relational assets) content: For documents: plain text content (e.g. a report you generated). For remote file bytes, pass file_url instead. For relational: JSON array string or CSV string. Omit when file_url or file_path is provided. namespace_id: Target namespace UUID (optional if using scoped URL) description: Optional description of the asset file_name: Required for documents - original filename with extension (e.g., "report.pdf") file_url: For documents only - a publicly accessible URL to a file (PDF, etc.). The server fetches and stores the file from this URL; pass it unmodified rather than downloading it first. Requires file_name. file_path: For relational only - absolute path to a local file (CSV, Parquet, etc.) to upload directly. Mutually exclusive with content. data_format: For relational only (inline content) - data format: "json" (default) or "csv" content_encoding: For documents only - "text" (default) for plain text content (server encodes automatically), or "base64" if content is already base64-encoded (only needed for binary files passed inline) Returns: SaveToolbeltResult with id, name, type, and resultContext describing the saved asset.
toolbelt_sqlExecute a read-only SQL SELECT against a namespace's GPU-accelerated database (Kinetica). Suitable for analytical questions where the schema is known. Writes (INSERT/UPDATE/DELETE/DDL) are rejected by a safety guard and the query is scoped to tables in the namespace. Supports standard SQL, geospatial functions (ST_*), time-series aggregation, window functions, and JOINs across large tables. Call toolbelt_context first to retrieve table and column names. Kinetica spatial SQL — important dialect notes (NOT PostGIS): - DISTANCE / RADIUS queries: the solution parameter is MANDATORY for spherical (meters). Use: ST_DWITHIN(geom1, geom2, meters, 1) STXY_DWITHIN(lon, lat, geom, meters, 1) The trailing `, 1` selects the spherical solution. If you OMIT it, the distance argument is interpreted as planar DEGREES, not meters — an 8046-meter radius then matches every row on Earth and silently returns global aggregates with no error. - Convert miles → meters: meters = miles * 1609.344. - ST_DISTANCE takes exactly 3 args: ST_DISTANCE(geom1, geom2, solution). - For point-in-polygon over a column, prefer STXY_INTERSECTS(lon, lat, polygon_wkt) = 1. - NO ST_SetSRID, NO ST_Transform — Kinetica handles SRID natively. For other shapes of question: - timeline / event lookups: toolbelt_timeline - entity profile / cross-document lookup: toolbelt_entity - free-text document search: toolbelt_ask or toolbelt_vectors - recording a finding: toolbelt_record SQL reference: https://docs.kinetica.com/7.2/sql/ Args: namespace_id: The UUID of the namespace to target. query: SQL SELECT to execute. Returns: Dict with success, data, columns, row_count, and execution_time_ms. On dialect-violation (e.g. missing solution param) the call returns success=False with an `error` message explaining the fix — re-issue with the correction, do not retry as-is.
toolbelt_listList assets (uploaded documents and tables) in a namespace. Use when: the user is asking what data, documents, or tables exist in a namespace. Returns asset metadata only (status, row counts, column lists) — not full schemas. For schemas + sample data + the information needed to write SQL, use toolbelt_context. For other shapes of question: - timeline / recorded events: toolbelt_timeline - entity profile / cross-document connections: toolbelt_entity - recording an observation: toolbelt_record Args: namespace_id: The UUID of the namespace to target Returns: Dict containing assets list (capped at 500) with type, status, and table info
toolbelt_askBest entry point for any question. Fast for simple exploration ("what is X", "tell me about Y" — uses vector retrieval directly, skips planner). Uses full plan-execute for analytical or relational questions. Deep retrieval across SQL, documents, and knowledge graph — one call replaces multiple toolbelt_sql + toolbelt_vectors + toolbelt_graph calls. Analyzes your question, generates the right queries (SQL for data, vector search for documents, Cypher for entity relationships), runs them all in parallel, and returns structured results. Use this when: - You need data from multiple sources (e.g. "top exposures AND related risk docs") - You're not sure which tool to call (this figures it out) - You want to save round-trips (1 call instead of 3) Use toolbelt_sql directly when you already have the exact SQL query. For other shapes of question: - "When did X happen", "history of Y", "events involving Z", "what changed between A and B", "show recent decisions/observations": use toolbelt_timeline (chronological events, faster). - "Who is X", "what do we know about X", "show X across all docs", "X's relationships and history": use toolbelt_entity (one call returns entity + source docs + relationships + timeline). - "Record / remember / save this finding": use toolbelt_record (timeline write, not retrieval). Args: question: Natural language question to answer namespace_id: Target namespace UUID (from toolbelt_list_namespaces or /ns/{id}/mcp scoped URL) Returns: Dict with answer (text summary), sources (structured data from each retrieval path), strategy used, SQL query if generated, and timing.
toolbelt_contextGet the full semantic context for a namespace — call this FIRST before using toolbelt_sql or toolbelt_vectors. Returns table schemas (with column names and types), autonomous context (DDLs, sample data, column constraints), SQL examples, domain vocabulary, vector collections, and embedding config. Use this to write SQL queries or choose vector collections. The autonomous_context field contains DDLs, column types, sample rows, and distinct values for relational tables. Column names returned here are authoritative — Kinetica rejects queries that reference columns not listed. Results are cached (5 min TTL) for fast repeated access. Args: namespace_id: The UUID of the namespace (get this from toolbelt_list_namespaces) Returns: Dict with custom_contexts (user-authored namespace directives, highest priority — read first), knowledge (governed business facts — approved definitions/rules; treat as authoritative), autonomous_context, table_schemas, relevant_tables, sql_examples, domain_terms, collections, embedding_config, vector_specs, relationships, domain_summary, dialect_summary, suggested_prompts.
toolbelt_vectorsSearch documents and knowledge bases using semantic similarity. For most questions, prefer toolbelt_ask — it uses vector retrieval directly for simple exploration questions (same speed as this tool) and adds SQL/graph routing automatically when the question is analytical or relational. Use toolbelt_vectors when you specifically want vector-only retrieval with no routing logic, e.g., batch retrieval or when you've already decided vector is the right tool. Embeddings are handled automatically — each namespace has a configured embedding model. Just pass your question as natural language text. All vector collections in the namespace are searched in parallel. Args: namespace_id: The UUID of the namespace to search question: Natural language question or search query Returns: Dict with results (list of content chunks with scores) and metadata.
toolbelt_describeGet detailed schema and sample data for a specific table. Returns column names, types, sample values, and row count. Useful for deep-diving into a table before writing complex SQL. Args: namespace_id: The UUID of the namespace table_name: The name of the table to describe Returns: Dict with table_name, columns (with types), sample_data, and row_count.
toolbelt_graphGraph and network analysis: multi-hop traversals, graph algorithms, path solvers. Advanced surface — accepts Kinetica Cypher queries and graph-solver algorithm invocations. For other shapes of question: - relationships for a named entity: toolbelt_entity - relationships described in prose ("how is X related to Y"): toolbelt_ask Suited to: - explicit multi-hop traversal ("entities connected to X via Y to Z") - graph algorithms (page rank, centrality, all paths, shortest path on a known-healthy KG) - a specific path between two named nodes when search alone is insufficient (operation="solve", solver="SHORTEST_PATH") Cypher reference: https://docs.kinetica.com/7.2/graph_solver/network_graph_solver/ Graph solver reference: https://docs.kinetica.com/7.2/graph_solver/ Operations: - "describe": List available graphs, their structure, and Cypher/PGQL syntax rules. Useful before constructing a Cypher query (operation="query"). A basic SHORTEST_PATH between two named entities does not require describe. - "query": Execute a Kinetica Cypher query against a named graph. Cypher starts with "GRAPH graph_name /* KI_HINT_MERGE_GRAPH_INPUTS */ MATCH ...". For aggregations (COUNT, GROUP BY), toolbelt_sql with GRAPH_TABLE() is the more appropriate surface. - "solve": Run a graph algorithm. Supported solvers: SHORTEST_PATH, PAGE_RANK, CLOSENESS, STATS_ALL, INVERSE_SHORTEST_PATH, PROBABILITY_RANK, MULTIPLE_ROUTING, CENTRALITY, ALLPATHS, BACKHAUL_ROUTING Note: graph_name format depends on operation: - For "solve": UNQUOTED `schema.name` (e.g. "toolbelt_user_demo.abc12345_kg") - For "query": QUOTED `"schema"."name"` (e.g. '"toolbelt_user_demo"."abc12345_kg"') Solve params: source_nodes: SQL SELECT returning NODE column (required for most solvers) destination_nodes: SQL SELECT returning NODE column (for path solvers) Other params become OPTIONS KV_PAIRS (e.g. uniform_weights, max_solution_radius) Note: for solve on KG (knowledge graph) entities, nodes are hash IDs rather than entity names. Look up the hash from the nodes table by name: source_nodes: "(SELECT "node" AS NODE FROM "<schema>"."_kg_<nsId8>_nodes" WHERE LOWER("name") LIKE '%entity name%')" Get the exact schema and table names from operation="describe". Other node formats: - Geospatial graphs: use WKT points, e.g. source_nodes: "(SELECT NODE_WKTPOINT AS NODE FROM graph_table_nodes WHERE NODE_ID = 123)" - For empty source (PAGE_RANK, STATS_ALL): use "(SELECT '' AS NODE)" Solve examples: KG shortest path between two entities: solver="SHORTEST_PATH", params={ "source_nodes": "(SELECT "node" AS NODE FROM "toolbelt_user_demo"."_kg_abc12345_nodes" WHERE LOWER("name") LIKE '%alice%')", "destination_nodes": "(SELECT "node" AS NODE FROM "toolbelt_user_demo"."_kg_abc12345_nodes" WHERE LOWER("name") LIKE '%bob%')", "uniform_weights": "1" } If COST is null and PATH is null on every result row, the two entities are not connected in this graph. Page rank: solver="PAGE_RANK", params={"source_nodes": "(SELECT '' AS NODE)"} Stats: solver="STATS_ALL", params={"source_nodes": "(SELECT '' AS NODE)"} Reachability: solver="INVERSE_SHORTEST_PATH", params={"source_nodes": "(SELECT ... AS NODE)", "max_solution_radius": "500"} Args: namespace_id: The UUID of the namespace operation: One of "query", "solve", "describe" graph_name: Name of the graph (required for query/solve) query: Kinetica Cypher query string (required for "query" operation) solver: Solver type (required for "solve") params: Solver parameters (source_nodes, destination_nodes, and options) Returns: Dict with results from the graph operation.
toolbelt_jobsList jobs for a namespace. Shows ingestion, embedding, KG rebuild progress, and job chains. Job types: - ingest: Parallel. Parses documents or loads CSV data. Chains to 'semantic' for docs. - semantic: Serial per namespace. Embeds chunks + extracts KG entities from parsed manifests. - kg-rebuild: Serial per namespace. Drops and rebuilds the entire Knowledge Graph. Job chain: When a document is uploaded, an 'ingest' job runs first (parse + store manifest), then automatically creates a 'semantic' job (embed + extract). The semantic job's correlationId links back to the parent ingest job. Args: namespace_id: The namespace UUID to list jobs for status: Optional filter — 'pending', 'running', 'completed', 'failed', or '' for all Returns: dict with 'jobs' list, each containing: id, jobType, status, progress (with message, percentage, completedSteps, totalSteps), error, assetId, correlationId (parent job for chains), createdAt, startedAt, completedAt
toolbelt_connectRegister an external data source with Kinetica and create a queryable asset in one call. DEPRECATED — prefer the explicit two-step flow: 1. toolbelt_list_data_sources / toolbelt_create_data_source — manage the account-level connection (credential + DATA SOURCE). 2. toolbelt_register_asset — bind a queryable asset in a namespace using the data source from step 1. Kept for backward compatibility and one-shot convenience. The new tools give the agent explicit control over whether a data source is created, reused, or only an asset is being added. For Kafka sources, executes: CREATE TABLE (column definitions) → CREATE DATA SOURCE → LOAD DATA INTO (JSON format) For JDBC/S3 sources, executes: CREATE CREDENTIAL → CREATE DATA SOURCE → CREATE EXTERNAL TABLE DDL Credentials are owned by Kinetica, not stored in Toolbelt. The table appears in toolbelt_context and is queryable via toolbelt_sql after registration. Args: source_type: Type of external source — jdbc_postgres, jdbc_mysql, s3, kafka, or jdbc_generic location: JDBC URL (e.g. "jdbc:postgresql://host:5432/db"), S3 bucket URI (e.g. "s3://my-bucket"), or Kafka broker URI (e.g. "KAFKA://host:9092") external_table_name: For JDBC — remote table name used in REMOTE QUERY. For S3 — file path within the bucket (e.g. "release/2024-07-22.0/theme=places/"). For Kafka — topic name. asset_name: Display name for the asset (also used to derive Kinetica object names) namespace_id: Target namespace UUID (optional if using scoped URL) description: Optional asset description table_mode: JDBC/S3 only — controls external table mode: 'logical' — federated; queries pass through to the remote source at query time. 'materialized' — data is copied into Kinetica and can be refreshed. Omit for default (one-shot ingest at creation time). data_source_name: Tier 1 — if the DATA SOURCE already exists in Kinetica, pass its name here to skip credential/datasource DDL. jdbc_username: Database username (Tier 3 inline — omit to use secure elicitation) jdbc_password: Database password (Tier 3 inline — omit to use secure elicitation) aws_access_key_id: AWS access key (Tier 3 inline) aws_secret_access_key: AWS secret key (Tier 3 inline) aws_region: AWS region (e.g. us-east-1) kafka_column_definitions: Required for Kafka — SQL column definitions for the target table (e.g. "id INTEGER, name VARCHAR(256), ts TIMESTAMP"). Kinetica cannot infer a Kafka topic schema automatically. kafka_subscribe: Kafka only — True for continuous streaming (SUBSCRIBE = TRUE), False for one-shot load of current messages (default: False). extra_options: Additional driver options as key-value pairs CREDENTIAL HANDLING (three tiers): 1. Pass data_source_name if the DATA SOURCE already exists — no credentials needed. 2. Omit all credential params — you will be prompted via the client UI (most secure for interactive use; credentials bypass the AI context entirely). 3. Pass inline credential params — used to build CREATE CREDENTIAL DDL, then discarded. Not stored in Toolbelt. Returns: Dict with assetId, dataSourceName, externalTableName, ddlExecuted (redacted), status, and message.
toolbelt_list_data_sourcesList all account-level data sources registered to the authenticated user. Data sources are account-scoped, not namespace-scoped — once registered, a data source can be used to create assets in any of your namespaces. Use this to: - Discover existing data sources before deciding whether to create a new one - Find the data_source_id needed by toolbelt_register_asset - Audit what external connections (S3 buckets, Postgres DBs, Kafka brokers) are wired up Returns: List of data source records. Each contains: - id: Postgres UUID (use this with toolbelt_register_asset) - name: Display name - sourceType: jdbc_postgres | jdbc_mysql | s3 | gcs | kafka | jdbc_generic - location: JDBC URL, s3://bucket, or kafka://broker - kineticaDataSourceName: The underlying Kinetica DATA SOURCE name - lastTestedAt, lastTestOk: Most recent connection test result - createdAt
toolbelt_create_data_sourceRegister a new account-level data source (credential + connection target). This creates the connection only — it does NOT create any queryable table or asset. To make data queryable in a namespace, follow up with toolbelt_register_asset using the returned data_source_id. ─── WHICH TOOL DO I WANT? ─────────────────────────────────────────────── The user said... "upload this CSV" / "let me query this file I have" → NOT this tool. Use toolbelt_save (relational mode). The file is uploaded into Kinetica's KIFS and becomes a native table that Kinetica owns. No external connection involved. The user said... "connect to my S3 bucket" / "register our Postgres" / "wire up the Kafka broker" → THIS tool, by itself. Creates the connection; no asset yet. The user said... "create an asset from the CSVs in this S3 bucket" / "make the orders table from prod-pg queryable here" → THIS tool (if the DS doesn't exist yet) THEN toolbelt_register_asset. Or just toolbelt_register_asset if the DS already exists — call toolbelt_list_data_sources first to check. Rule of thumb: if the data lives ELSEWHERE and Kinetica should reach out to it, use this tool. If the user is handing you a file to upload, use toolbelt_save. ───────────────────────────────────────────────────────────────────────── Use this tool when: - You have a fresh external source (S3 bucket, JDBC database, Kafka broker) that has never been registered before. - You want the credential stored in Kinetica so future asset creation in any namespace can reuse it without re-entering secrets. Not the right tool when: - A data source for the same target already exists (call toolbelt_list_data_sources first to check). - The goal is to make a specific table/file/topic queryable from an already-registered source — use toolbelt_register_asset directly with data_source_id. - The user is uploading a file (CSV, PDF, etc.) — use toolbelt_save. Args: name: Human-readable name (e.g. "prod-warehouse-pg", "events-bucket-us-east") source_type: Type of external source location: JDBC URL (jdbc:postgresql://host:5432/db), S3 bucket URI (s3://my-bucket), GCS bucket URI (gs://my-bucket), Kafka broker URI (KAFKA://host:9092), or a Neo4j Bolt URI (neo4j+s://<id>.databases.neo4j.io for AuraDB, or bolt://host:7687 for self-managed) jdbc_username / jdbc_password: JDBC credentials (Tier 2 inline) aws_access_key_id / aws_secret_access_key / aws_region: S3 credentials gcs_access_key_id / gcs_secret_access_key: GCS credentials neo4j_username / neo4j_password / neo4j_database: Neo4j / AuraDB credentials. The password is stored ENCRYPTED (atlas connects to Neo4j at query time; it is not baked into Kinetica). For a Neo4j source, follow up with toolbelt_register_asset to attach the graph to a namespace, after which toolbelt_graph (operation='query') runs full standard Cypher against it. mcp_query_tool / mcp_schema_tool / mcp_authorization: for source_type='mcp' — connect any external system that exposes its own MCP server (location = its MCP URL). `mcp_query_tool` is the read-query tool to route under toolbelt_graph (e.g. 'read_neo4j_cypher'); `mcp_schema_tool` returns its schema; the Authorization header is stored ENCRYPTED. Toolbelt routes queries to it UNDER the existing tools — no new agent tools are added. extra_options: Additional driver options as key-value pairs CREDENTIAL HANDLING (two tiers): 1. Omit all credential params — you will be prompted via MCP elicitation (credentials bypass the AI context entirely; most secure). 2. Pass inline credential params — used to build CREATE CREDENTIAL DDL on Kinetica, then discarded. Not stored in Toolbelt's Postgres. Returns: Dict with: - id: Postgres UUID — pass this to toolbelt_register_asset - name, sourceType, location - kineticaDataSourceName: Underlying Kinetica DATA SOURCE name - kineticaCredentialName: Underlying Kinetica CREDENTIAL name - createdAt
toolbelt_register_assetBind an external table or topic to a namespace as a queryable asset, using a pre-registered data source. This is the second half of the connect flow. The data source (credential + connection target) must already exist — call toolbelt_list_data_sources to find one, or toolbelt_create_data_source to register a new one. ─── WHICH TOOL DO I WANT? ─────────────────────────────────────────────── The user said... "upload this CSV and let me query it" → NOT this tool. Use toolbelt_save (relational mode). The file becomes a native Kinetica table that Kinetica owns. No data source involved. The user said... "make the orders table from our Postgres queryable" / "register the parquet files in s3://bucket/events/" → THIS tool. Data stays in the external system; Kinetica reads it via the data source. The user said... "snapshot the S3 CSVs into Kinetica so queries are fast" → THIS tool with table_mode="materialized". One-shot copy into Kinetica, refreshable later. Rule of thumb: this tool exposes data that lives ELSEWHERE through a pre-registered connection. If the user is handing you a file to upload, use toolbelt_save. ───────────────────────────────────────────────────────────────────────── What this tool does (depending on the data source's source_type): - JDBC / S3 / GCS: CREATE EXTERNAL TABLE against the existing DATA SOURCE - Kafka: CREATE TABLE (column definitions) → LOAD DATA INTO from the topic Plus: registers the table as an Asset in the namespace so it appears in toolbelt_context and is queryable via toolbelt_sql. No credentials are needed here — they're owned by the underlying data source. Args: data_source_id: Postgres UUID of the data source (from toolbelt_list_data_sources or toolbelt_create_data_source) asset_name: Display name for the asset (also used to derive Kinetica object names) external_table_name: For JDBC — remote table name (e.g. "public.orders"). For S3/GCS — file path within the bucket (e.g. "release/2024-07-22/theme=places/"). For Kafka — topic name. namespace_id: Target namespace UUID (optional if using scoped URL) description: Optional asset description table_mode: JDBC/S3/GCS only — external table mode: 'logical' — federated; queries pass through at query time. 'materialized' — data is copied into Kinetica, refreshable. Omit for default (one-shot ingest at creation). kafka_column_definitions: Required for Kafka — SQL column definitions for the target table (e.g. "id INTEGER, name VARCHAR(256), ts TIMESTAMP"). Kinetica cannot infer Kafka topic schemas. kafka_subscribe: Kafka only — True for continuous streaming (SUBSCRIBE = TRUE), False for one-shot load (default). Returns: Dict with assetId, dataSourceName (Kinetica), externalTableName, ddlExecuted (redacted), status, message.
toolbelt_register_tableRegister a table that ALREADY EXISTS in the connected Kinetica cluster into a namespace, making it queryable via toolbelt_sql — the brownfield path (point Toolbelt at data already in Kinetica). ─── WHICH TOOL DO I WANT? ─────────────────────────────────────────────── The user said... "make our existing Kinetica table aiops.snow_incidents queryable in this workspace" / "we already have these tables loaded in Kinetica, add them here" → THIS tool. The table already lives in the connected Kinetica cluster: no data source, no upload, no copy. The user said... "make the orders table from our Postgres queryable" / "register the parquet in s3://bucket/..." → NOT this tool. Use toolbelt_register_asset — the data lives in an EXTERNAL system and needs a data source (toolbelt_create_data_source). The user said... "upload this CSV and let me query it" → NOT this tool. Use toolbelt_save (relational) — Kinetica creates and owns a new table from the file. ───────────────────────────────────────────────────────────────────────── No ingest job runs and no data moves — this records that the existing table belongs to the namespace, so toolbelt_sql allows it and the crawler folds its schema into context. Toolbelt never DROPs a table it did not create. Args: kinetica_table: Fully-qualified existing table, e.g. "aiops.snow_incidents". namespace_id: Target namespace UUID (optional if using a scoped URL). name: Display name for the asset (defaults to the table's name). description: Optional description. Returns: Dict with the created asset.
toolbelt_usageReturn the current user's API usage metrics and quota limits. Intended for direct usage questions from the user — e.g. "how many API calls do I have left?", "what is my storage usage?", "show me my usage metrics" — rather than as a routine step in other workflows. Returns a dict with: account_tier: str — user's plan tier (anonymous, verified, pro, team) api_calls_used: int — API calls consumed in the current billing period api_calls_limit: int | None — monthly cap (None = unlimited) storage_used_bytes: int — storage consumed in bytes storage_limit_bytes: int | None — storage cap in bytes (None = unlimited) total_assets: int — total number of assets owned by the user reset_at: str — ISO 8601 datetime when the billing period resets
toolbelt_recordRecord something on this namespace's timeline. Typical call sites: - User expresses a judgment / decision worth preserving (event_type='decision'). E.g. "the BGC Hub fiber is fragile", "we're pausing the migration until next sprint". - Investigation surfaced a non-obvious finding — an unusual data point, a computed result, a state assessment (event_type='observation'). E.g. "Q3 churn jumped 30% after the EU pricing change on Aug 14". - Recording a real-world dated occurrence (event_type='event'). Not the right tool for: - Routine lookups (entity profiles, schema queries) — those are retrievable any time. - Persisting documents, files, datasets — use toolbelt_save. - Running queries or fetching data — use toolbelt_sql or toolbelt_ask. Heuristic: would a teammate joining this namespace in a week want to know this fact? If yes, recording is appropriate. This is for short, reusable findings — not bulk data. Keep `content` under a few hundred words. event_type convention (free string, not enforced): 'event' | 'observation' | 'decision' | 'note' Args: content: Short prose (markdown OK). The thing worth remembering. namespace_id: Target namespace UUID. Optional if URL is scoped. event_type: One of the conventional values above. Defaults to 'note'. occurred_at: ISO 8601 timestamp for when this happened in the world. Defaults to now() if omitted. occurred_at_precision: 'day' | 'month' | 'year' if the date is fuzzy. entity_name: Optional entity this is about (enables timeline filtering by entity later). entity_type: Optional entity type (e.g. 'person', 'organization'). source_asset_id: Optional asset UUID this was derived from. extra: Optional structured payload (JSON object). Returns: The created event row, or {"skipped": true, "reason": "events_disabled"} if the namespace has events disabled.
toolbelt_list_public_assetsBrowse the Public Assets catalog — datasets any Toolbelt user can read without owning them. Two sections: - `curated`: Toolbelt-vetted Gold Catalog entries (license-cleared, attribution recorded). - `community`: User-shared assets, not vetted. Use when: the user asks "what public datasets are available?" or is exploring before adding data to a namespace. To use one of these in a namespace, call `toolbelt_add_public_asset` with the id of the catalog entry. That registers a local reference; after that the asset appears in `toolbelt_list` and `toolbelt_context` for the namespace and can be queried via `toolbelt_sql`. For other shapes of question: - listing what's in a specific namespace: toolbelt_list - publishing your own asset: handled via the Atlas UI "Make public" toggle, not this tool Args: filter: 'all' (default), 'curated', or 'community' Returns: Dict with two keys: { "curated": [...], "community": [...] } Each entry has id, name, description, ownerNamespaceName, shareableReason, sharedAt, curated.
toolbelt_add_public_assetAdd a Public Asset to a namespace so it can be queried in this namespace's context. No data is copied — this creates a local reference to the same Kinetica table. Use when: the user wants to use a dataset they discovered via `toolbelt_list_public_assets`. After adding, the asset shows up in `toolbelt_list(namespace_id)` and is automatically included in `toolbelt_context(namespace_id)` so SQL generation will see its schema. Idempotent — calling twice with the same (namespace_id, public_asset_id) returns the existing local row, no duplicate. Args: namespace_id: UUID of the namespace to add into. The namespace needs to be owned by the caller — public assets cannot be added to a namespace owned by someone else. public_asset_id: UUID of the source Public Asset, from `toolbelt_list_public_assets`. Returns: The newly created (or pre-existing) asset row in the namespace.
toolbelt_timelineRetrieve events from this namespace's timeline. Typical call sites: - 'when did X happen', 'history of Y', 'events involving Z' - 'what changed between A and B', 'show recent decisions' - Surfacing what previous agents recorded before re-deriving. Not the right tool for: - Free-text search across documents — use toolbelt_ask or toolbelt_vectors. - Structured aggregations — use toolbelt_sql. Returns events newest-first by occurred_at (with NULLs last). Each row carries `source` so you can tell agent observations from auto-extracted facts and discount low-confidence rows. Args: namespace_id: Target namespace UUID. Optional if URL is scoped. entity: Filter by entity name (case-insensitive substring match). event_type: Filter by type ('event' | 'observation' | 'decision' | 'note'). source: Filter by provenance ('gliner' | 'agent:claude' | 'user' | ...). since: ISO 8601 — only events with occurred_at >= since. When omitted (and `until` also omitted) the call defaults to the last 30 days; pass an explicit older value to see further back. until: ISO 8601 — only events with occurred_at <= until. limit: Max rows. Default 100, max 1000. Returns: List of event rows. Empty list if events are disabled for the namespace.
toolbelt_entityMemex-style profile of an entity in this namespace: KG node row, every document that mentions it, every relationship in/out, and every timeline event involving it — in one call. Friendly wrapper over the knowledge graph: pass an entity name, get its relationships back. No Cypher generation needed — server handles the graph query. Use this for "show me what's connected to X" instead of toolbelt_graph (which requires writing Cypher). Typical call sites (single-entity questions): - 'tell me everything about X' / 'who is X' / 'what do we know about X' - 'show X's history' / 'what docs mention X' - A single call here replaces repeated toolbelt_ask/toolbelt_sql calls that gather context on one entity. For other shapes of question: - 'relationship between X and Y' / 'how is X connected to Y': use toolbelt_ask with both names in one query (e.g. "Acme Globex"); documents that mention both describe the relationship in prose. - Free-text document search: toolbelt_ask. - Multi-hop graph traversal: toolbelt_graph. - Recording new findings about the entity: toolbelt_record. Args: name: Entity name (case-insensitive; alias-aware). namespace_id: Target namespace UUID. Optional if URL is scoped. relationships_limit: Max relationships in each direction (default 50). events_limit: Max timeline events to include (default 50). Returns: { entity: { name, type, aliases, confidence, found }, source_documents: [{ asset_id, name, type, mention_count, evidence_snippets: [str], # actual text passages from this # doc that mention the entity — # quote these in your answer # instead of inferring relationships # from co-mention alone. }], relationships: { outgoing: [{ target, label, evidence, confidence, asset_ids }], incoming: [{ source, label, evidence, confidence, asset_ids }], }, timeline: [{ id, event_type, occurred_at, recorded_at, source, content, confidence }], } entity.found is false if no KG node matched; timeline still returned. Supporting evidence is in `evidence_snippets` and `source_documents`. Co-mention of two entities in the same document is not on its own evidence of ownership, employment, or affiliation; the toolbelt-answer-discipline skill covers how to handle this.
toolbelt_kg_ontologyView the knowledge-graph ontology for a namespace — the set of entity types and relation types the extractor looks for. Read-only. Call this before editing (toolbelt_kg_ontology_set) so you modify the real list instead of guessing it. For other shapes of question: querying the graph (toolbelt_graph), looking up one entity's relationships (toolbelt_entity), or running SQL (toolbelt_sql). This tool reads the extraction *schema* only, not graph data. Args: namespace_id: Target namespace UUID. Optional if the URL is scoped. Returns: {persisted, editable, reservedLayers, domain, entityTypes, edgeTypes, entityThreshold, relationThreshold}
toolbelt_kg_ontology_setReplace the editable knowledge-graph ontology for a namespace. This is a write: the types set here are fed to the zero-shot extractor on the next ingest / KG rebuild. Owner-only. Send the FULL desired list of entity_types and edge_types — this REPLACES, it does not merge, so carry over the existing types you want to keep (call toolbelt_kg_ontology first to see the current list). Reserved (layer-1) types are owned by the platform and preserved automatically. Each type is an object: {"name": "customer", "layer": 2, "description": "A client account or company we do work for"} - name: the type label (lowercase, short). - layer: 0 for a universal default, 2 for a domain type you add. - description (entity types): a one-line definition — the single biggest accuracy lever for the extractor. Relation (edge) types don't need one. Two optional tuning dials (both 0-1) apply to GLiNER extraction: entity_threshold (default 0.4) and relation_threshold (default 0.5). Leave them unset to keep the current/default values. After a set, NEW documents use the new ontology immediately; to re-extract existing documents, trigger a KG rebuild. Args: namespace_id: Target namespace UUID. Optional if the URL is scoped. entity_types: full list of entity-type objects (required). edge_types: full list of relation-type objects. domain: optional short domain label (e.g. "field_service"). entity_threshold: 0-1 entity confidence cutoff. relation_threshold: 0-1 relation confidence cutoff. Returns: {success, domain, entityTypes: <count>, edgeTypes: <count>, entityThreshold, relationThreshold}
toolbelt_lessonList a namespace's ACTIVE lessons (the durable, human-approved guidance that coaches agents), plus a count of drafts awaiting approval. Read-only. You usually don't need this — relevant lessons are auto-attached as `guidance` on tool results. Use it to review what's active before proposing a new lesson (toolbelt_lesson_propose), to avoid duplicates. For other shapes of question: one-off facts or events (use toolbelt_record → the timeline), or editing extraction types (toolbelt_kg_ontology). Lessons are reusable behavioral guidance, not data. Args: namespace_id: Target namespace UUID. Optional if the URL is scoped. Returns: {active: [...], activeCount, draftCount}
toolbelt_lesson_proposePropose a new LESSON for a namespace. It is saved as a DRAFT and does NOT coach anyone until the namespace owner approves it in Atlas — you are a scribe, not an unreviewed author. Only propose a lesson the USER has confirmed is a real, reusable rule ("always X", "never Y here"). A good lesson is specific and reusable: title: "Confirm the site suburb before dispatching" trigger: "assigning or routing a technician to a job" what_to_do: "Verify the job's suburb against the customer's site record before assigning the nearest technician." what_to_avoid: "Dispatching on the customer's billing suburb." Args: namespace_id: Target namespace UUID. Optional if the URL is scoped. title: short name of the lesson (required). trigger: when this lesson applies — the situation to match (required). what_to_do: the guidance to follow (required). what_to_avoid: the anti-pattern to avoid (optional). Returns: {proposed: true, status: "draft", lesson: {...}, note: ...}
toolbelt_knowledgeRead the namespace's governed KNOWLEDGE MODEL — approved business facts: terms/definitions, ownership, business units, rules, and how they bind to tables and documents. This is ratified truth (or drafts awaiting review), with provenance on every fact. format="mermaid" returns a diagram any client can render — governed (human-ratified) facts, machine-derived cache facts, and table nodes are styled DISTINCTLY so it is obvious what is decided vs inferred. DO NOT use for: - changing what GLiNER extracts from documents → toolbelt_kg_ontology_set - traversing extracted document entities → toolbelt_graph / toolbelt_entity - proposing a new fact or correction → toolbelt_knowledge_propose Args: namespace_id: Target namespace UUID. Optional if the URL is scoped. format: "json" (default) or "mermaid" (renderable diagram). status: filter — draft | active | stale | archived. type: filter nodes by type (term, business_unit, table, ...). q: substring search over names/definitions. Returns: {nodes, edges} or {mermaid, node_count, edge_count}. A "not enabled" error means this install has no knowledge model license — the feature is off, not broken.
toolbelt_knowledge_proposePropose a KNOWLEDGE FACT for the namespace's governed model. It is saved as a DRAFT and is invisible to every agent until the namespace owner ratifies it in Atlas — you are a scribe, not an unreviewed author. Use when the USER states a business truth in conversation: a definition ("revenue means Completed jobs only"), ownership ("Field Ops owns the jobs table"), a rule, or a correction to a wrong extracted edge. Three kinds: - kind="node": a concept/term. Requires name + type (term | business_unit | process | kpi | ...); definition strongly recommended; alt_labels for synonyms. - kind="edge": a relationship. Requires from_name, to_name, label (owns | resolves_to | feeds | describes | means | part_of | ...). Endpoints are resolved by name; unknown names become draft nodes. - kind="correction": fix a WRONG edge in the extracted document graph. Requires node1, node2 (entity names as shown by toolbelt_graph), action ("suppress" or "replace"), and replacement_label when replacing. DO NOT use for: - one-off observations/events → toolbelt_record - behavioral guidance ("always do X when Y") → toolbelt_lesson_propose - changing extraction vocabulary → toolbelt_kg_ontology_set Returns: {proposed: true, status: "draft", ...} — remind the user the owner must approve it in Atlas before agents see it.
toolbelt_accept_shareAccept a namespace share invitation by its share ID. The user (or another agent acting for them) was sent a link like `https://.../share-namespace/<share_id>`. Calling this with that share_id adds the shared namespaces to the authenticated user's Toolbelt account — afterwards they appear in toolbelt_list_namespaces and the Atlas UI. Idempotent: calling twice is safe and returns success the second time. Args: share_id: The UUID at the end of the share URL. Returns: A formatted string describing which namespaces were added and with what access level.
Toolbelt: подключить к Claude, ChatGPT, Cursor · Connectors.fun