AstraNL local proof NL

create_task

Ask AstraNL to find and coordinate a verified executor for a physical task in the Netherlands. Returns an ingress receipt at once and a case once planning found a path; the client pays the executor directly; AstraNL holds no money. Fee: submitting costs nothing; AstraNL charges 1 percent of the transaction only when it coordinated a completed paid task, nothing else.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "need": "<need>"
    },
    "name": "create_task"
  }
}

Input Schema

Name	Required	Description
`need`	Yes	what must happen, in plain words
`proof`	No	what evidence closes the task, agreed before work starts
`deadline`	No	by when; ISO date or plain words
`location`	No	city or address in the Netherlands
`synthetic`	No	true marks a test that must never be counted or executed
`budget_cents`	No	budget in euro cents
`reply_channel`	No	email or https URL where AstraNL may answer you

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 10, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Adds substantial context beyond annotations: asynchronous return (receipt now, case after planning), direct client-to-executor payment, AstraNL holding no funds, and a 1% success-only fee. Does not cover non-idempotency or duplicate submission handling, which the annotations flag as relevant.

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?

Two tight sentences, front-loaded with what the tool does, then the returns and the fee model. The fee sentence is long but carries decision-relevant information, so little is wasted.

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?

With no output schema, the description does explain the two-stage return and the money flow, which are the highest-risk unknowns for an open-world, non-read-only tool. It stops short of describing what the receipt/case contain or timeouts, so not fully complete.

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 explains all seven fields including need, proof, deadline and synthetic. The description adds no parameter-level guidance, which is the expected baseline here.

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?

States a specific verb and resource: 'find and coordinate a verified executor for a physical task in the Netherlands.' An agent can tell this is the initiation tool distinct from check_task/get_evidence, though no sibling is named explicitly.

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?

Implies this is the entry point by describing the immediate ingress receipt and later case, but never states when to use it versus check_task or get_evidence, nor any preconditions for submitting.

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

All AstraNL local proof NL 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?