Singularity Layer MCP

request_dataset_payment

Step 1 of buying a training dataset: submit the job and get back an x402 payment challenge with the exact price. Nothing is charged and nothing is generated yet. Pass the SAME arguments to create_dataset_with_payment: the server binds the payment to this exact job and refuses a mismatch.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Name for the dataset
`rules`	No	House rules the assistant must NEVER break, e.g. "Never promise a refund". Without them the model invents its own policy, differently each time
`verify`	No	Check every row with a second model and regenerate any that break the rules. ON by default, priced separately ($0.10 per 100 managed, $0.03 per 100 grid where the grid checks its own work so nothing leaves the network). false = skip checking, pay generation only
`modelId`	No	Exact managed model from list_dataset_pricing (decides the tier and price)
`network`	No	Chain you will pay on (default base)
`gridModel`	No	Model on the decentralized encrypted grid: cheaper, slower, data never leaves the network
`modelTier`	No	Managed model speed/quality tier. Omit when using gridModel
`targetRows`	Yes	How many examples to generate (50-2000). Price scales with this
`webhookUrl`	No	Public HTTPS URL to notify when the dataset is ready; the POST is signed
`description`	Yes	What the model being trained should do, in one plain sentence
`seedExamples`	Yes	5 to 20 example conversations showing the behaviour you want
`systemPrompt`	No	Standing instruction every generated example should follow

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 3, 2026

addedInput schema / properties / verify

Added value: +{
+  "description": "Check every row with a second model and regenerate any that break the rules. ON by default, priced separately ($0.10 per 100 managed, $0.03 per 100 grid where the grid checks its own work so nothing leaves the network). false = skip checking, pay generation only",
+  "type": "boolean"
+}

Changed1 schema field changedSep 2, 2026

addedInput schema / properties / rules

Added value: +{
+  "description": "House rules the assistant must NEVER break, e.g. \"Never promise a refund\". Without them the model invents its own policy, differently each time",
+  "items": {
+    "maxLength": 200,
+    "type": "string"
+  },
+  "maxItems": 12,
+  "type": "array"
+}

AddedAug 31, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It does this well by stating 'Nothing is charged and nothing is generated yet' and 'the server binds the payment to this exact job and refuses a mismatch.' These are consequential side-effect and consistency behaviors an agent must know. It could add more (e.g., challenge expiration, response shape), but the key behavioral risks are disclosed.

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?

The description is compact, front-loaded, and every sentence adds value. The first sentence states the tool's exact role and immediate output; the second conveys the no-side-effect guarantee and the critical argument-matching requirement. There is no redundant restatement of the tool name or schema fields.

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?

Given no output schema and no annotations, the description does a solid job of covering the full workflow: it explains what the call returns, what it does not do, and what the agent must do next. It omits minor operational details like challenge expiration or polling follow-up, but those are less essential for correct invocation and are likely handled by a later status-check sibling.

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 description need not repeat individual parameter meanings. The description adds useful cross-tool guidance by emphasizing that the same arguments must be passed to create_dataset_with_payment, but it does not enrich the meaning of any specific parameter beyond what the schema already states. This matches the baseline for high schema coverage.

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 opens with a specific verb and resource: 'Step 1 of buying a training dataset: submit the job and get back an x402 payment challenge.' It clearly distinguishes this from related payment-request tools by naming the dataset-purchase workflow and the sibling create_dataset_with_payment. An agent can determine exactly what this tool does and how it differs from neighboring request_*_payment tools.

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 frames when to use it ('Step 1 of buying a training dataset') and names the follow-up tool: 'Pass the SAME arguments to create_dataset_with_payment.' This gives clear workflow context and an alternative. It doesn't spell out exclusions or preconditions such as consulting list_dataset_pricing first, but the schema's modelId description covers that, so the guidance is strong overall.

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

All Singularity Layer MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?