Skip to main content
Glama

Measure a dataset URL (free, books nothing)

describeDataset
Read-onlyIdempotent

Measure a public https dataset URL and return its exact sizeBytes, sha256 and contentType, plus suggestedEntry — a filled-in element of the spec's datasets[] array you can paste straight in. Call it before submitJob whenever you want datasets[] to stage and verify a file: sizeBytes and sha256 are REQUIRED on every entry, and this is how you get them without pulling the data down to your own machine first. We read the URL from our side, stream it through a hash and keep no copy. Free, books nothing, and it never reads the caller's filesystem. https only, and only addresses on the public internet: a loopback, private, link-local or otherwise reserved host is refused, and so is a redirect that leads to one. There is an upper size limit and a limit on how often one session may call it; both refusals say so plainly. You do NOT need this when your command downloads its own data with curl or wget — datasets[] is the verified-staging path, and only that path needs a hash declared up front.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesPublic https URL of the dataset file. Symbioza fetches it from its own side — your own machine is never on the data path, and a URL that needs a credential to read should be a signed URL with the shortest expiry that covers staging — once submitted it is stored with the job spec in clear and included in our backups.
authKeyNoUsually omit this. The customer door — the OAuth-signed-in HTTPS connector at https://symbioza.dev/mcp — authenticates the session itself, so no key is passed per call. Only a self-hosted or test transport passes a key here.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoMachine-readable refusal code: unauthorized, invalid_spec, budget_too_low, insufficient_balance, access_required, secret_conflict, no_compute, unavailable, refused
actionNoThe one next step: authenticate, fix_spec, raise_budget, add_funds, claim_credit, add_access, relax_spec_or_retry, retry_later, contact_support
reasonNoWhy, in a customer-safe sentence
sha256No
rejectedNoPresent and true when the call was refused; nothing was booked or charged
sizeBytesNo
contentTypeNo
suggestedEntryNoA datasets[] element for the spec, ready to paste
supportedImagesNoOn an unverified-image refusal: the images the door accepts

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / action / description
      Previous value: -"The one next step: authenticate, fix_spec, raise_budget, add_funds, claim_credit, relax_spec_or_retry, retry_later, contact_support"New value: +"The one next step: authenticate, fix_spec, raise_budget, add_funds, claim_credit, add_access, relax_spec_or_retry, retry_later, contact_support"
    • changedOutput schema / properties / code / description
      Previous value: -"Machine-readable refusal code: unauthorized, invalid_spec, budget_too_low, insufficient_balance, no_compute, unavailable, refused"New value: +"Machine-readable refusal code: unauthorized, invalid_spec, budget_too_low, insufficient_balance, access_required, secret_conflict, no_compute, unavailable, refused"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, yet the description adds substantial context beyond them: server-side streaming with no retained copy, no caller filesystem access, https-only with loopback/private/link-local/reserved hosts and redirects refused, plus size and rate limits whose refusals are self-explanatory. This is genuinely useful operational detail.

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?

It is long but front-loaded with the core purpose and returns, and nearly every sentence carries a distinct rule (safety, limits, exclusion). The density is high, though a couple of clauses (backups/clear-storage asides) could be trimmed.

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?

Output schema exists so return values needn't be detailed, yet they are summarized; the invocation preconditions, safety profile, and the alternate non-hashing path are all covered. Nothing needed to call it correctly is missing.

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% and the schema descriptions are already rich (signed-URL guidance, when to omit authKey). The description still adds meaning about the url parameter's constraints — public-internet-only, https-only, refusal semantics — which is not in the schema itself.

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 title and first sentence state a specific verb (measure) and resource (a public https dataset URL) and enumerate the exact returns (sizeBytes, sha256, contentType, suggestedEntry). It is immediately distinguishable from siblings like submitJob and estimateExecution.

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?

It names the trigger condition (call before submitJob whenever datasets[] must stage and verify a file) and an explicit exclusion ('You do NOT need this when your command downloads its own data with curl or wget'). That is textbook when/when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.