Skip to main content
Glama
rawtreedb

RawTree MCP Server

Official
by rawtreedb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Insert From URL

insert-from-url

Fetch a public JSON or JSONL file URL and load its rows directly into a RawTree table, waiting for the import to finish.

Instructions

Purpose: Ask RawTree to ingest JSON/JSONL data from a public URL into a table. Waits for the import to complete.

NOT for: Private files on your machine or authenticated URLs. Normalize or transform data before making it available at the public URL.

Returns: The completed import result as JSON: inserted is the row count, or null when unavailable.

When to use:

  • User has a public JSON or JSONL file URL

  • You need RawTree to fetch and ingest the file directly

  • The data is too large or inconvenient to paste into the MCP call

Workflow: Confirm the URL is public → call insert-from-url → use list-logs and run-query to verify.

Key trigger phrases: "ingest this URL", "load JSONL from", "import from public file"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesPublic URL containing data RawTree can fetch.
tableYesTarget table name.
clusterNoRawTree cluster to use for this operation.
databaseNoOptional RawTree database override. RawTree uses the default database when omitted.
organizationNoRawTree organization containing the target cluster.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.2
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / cluster
      Added value: +{
+  "description": "RawTree cluster to use for this operation.",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / database
      Added value: +{
+  "description": "Optional RawTree database override. RawTree uses the default database when omitted.",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / organization
      Added value: +{
+  "description": "RawTree organization containing the target cluster.",
+  "minLength": 1,
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that the call is blocking ('Waits for the import to complete'), the public-URL requirement, and the return shape (inserted row count or null). It does not cover error behavior, permissions/auth for RawTree itself, or whether existing rows are affected, leaving some behavioral gaps.

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

Conciseness5/5

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

Front-loaded with Purpose, then scoping, returns, and workflow in clearly labeled sections. Each block earns its place and nothing is redundant padding; trigger phrases aid selection without bloating the text.

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

Completeness4/5

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

For an ingestion tool with no output schema and no annotations, the description is largely complete: it explains what happens (blocking import), what is returned, and the preconditions. It could go further on error handling and authentication, but nothing critical for correct invocation is missing.

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 five parameters including url, table, cluster, database, and organization. The description adds only the 'public URL' constraint, which the schema also states, so it does not meaningfully extend parameter meaning beyond structured data. Baseline 3 applies.

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?

States a specific verb (ingest JSON/JSONL from a public URL) and resource (into a table), and explicitly scopes it against alternatives by declaring what it is NOT for (private/authenticated URLs). An agent can distinguish it from insert-json without opening either schema.

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

Usage Guidelines5/5

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

Provides an explicit 'When to use' list, a 'NOT for' exclusion, and a workflow (confirm URL is public → call → verify with list-logs/run-query). It even hints at the sibling alternative by contrasting with data 'too large or inconvenient to paste into the MCP call.'

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

Deploy Server

Other Tools