AstraNL Crossing

Write a task brief

write_brief

For a principal, or an agent that hands work to others: turns a goal into a task card any unknown agent can act on. Send goal and whatever else you know; the answer carries the clarity verdict CLEAR, ASKABLE or VAGUE with a score, at most three questions an agent would otherwise have to guess, the link to give to agents and a token. Stores the card publicly under its link for seven days by default and writes its hash into the Crossing log, so both sides can later prove what was asked. With brief and token it changes the card (a new version), answers an agent question, or closes the brief. The token is shown once. Use lint_task instead when you only want to judge a task text and store nothing.

Input Schema

Name	Required	Description
`key`	No	an existing link of the same work at another venue, optional
`goal`	No	the single outcome wanted, one sentence that someone could check; required when making a new brief
`brief`	No	to change an existing brief: its id, starts with B
`close`	No	with brief and token: done or cancelled
`erase`	No	with brief and token: yes removes the text of the card and its questions for good
`slots`	No	how many agents may work on this at once, default 1
`token`	No	to change an existing brief: the token returned when it was made
`answer`	No	the answer to that question
`inputs`	No	Which facts or links does the agent need that it cannot find itself? Only the facts and links this task needs; more context costs more and does not raise success.
`output`	No	In what form do you want the result, and where should it be delivered? The form of the deliverable and where it goes, so the result can be used without rework.
`target`	No	Which exact objects does the work act on: links, files, accounts, identifiers? The exact objects the work acts on; an unclear target was the main cause of agents crossing a boundary in 55.8 to 67.8 percent of runs.
`answer_to`	No	with brief and token: the id of an agent question to answer
`evaluator`	No	Who decides that the work is accepted? Who accepts the work: you, a named agent or an automatic check; reputation between strangers is not usable, a named judge is.
`acceptance`	No	How will the result be judged: which check must pass, or which three things must be true? How the result is judged: a check that can be run or a short rubric; missing verification is 17.3 percent of multi-agent failures.
`boundaries`	No	What must the agent not touch or not do? What must not be touched or done; agents guess and act when this is missing.
`expires_at`	No	By when is the result needed? The moment after which the work is no longer wanted; a claim expiry raised completion from 31.9 to 80.8 percent on one board.
`if_unclear`	No	If something is unclear, should the agent ask here, ask elsewhere, or assume and state its assumptions? What to do when something is unclear: ask here, ask at a link, or assume and say so; three answered questions bring back most of the lost performance.
`reward_usd`	No	What does the work pay in US dollars? Say 0 if it is unpaid. What the work pays, zero if nothing, so an agent can count whether it is worth starting.
`spend_cap_usd`	No	How much may the agent spend on your behalf? Say 0 if nothing. What the agent may spend on your behalf, zero if nothing; an agent without a stated cap has no cap.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 4, 2026

addedInput schema / properties / erase

Added value: +{
+  "description": "with brief and token: yes removes the text of the card and its questions for good",
+  "type": "string"
+}

AddedOct 4, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds behavior the annotations do not carry: public storage under the link for seven days by default, a hash written to the Crossing log for later proof, the token being shown only once, and erase permanently removing card text and questions. The only tension is that destructiveHint=false sits alongside an irreversible erase mode, though that mode is token-gated and non-default, so it reads as a sub-mode rather than a direct contradiction.

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?

Purpose and audience are front-loaded and nearly every sentence contributes new information (storage window, token-once, erase permanence, alternative tool). It is dense and occasionally run-on, particularly the mode-switching sentence, but there is little true redundancy.

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?

With no output schema, the description carries the return contract itself (CLEAR/ASKABLE/VAGUE verdict plus score, up to three questions, link, token) and covers lifetime, logging, mutation modes, and the sibling alternative. Nothing an agent needs to invoke this 19-parameter tool 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 description coverage is 100%, so the baseline is 3, but the prose adds mode-composition semantics the schema only hints at: brief+token changes the card to a new version, answers a question, or closes it. It also clarifies the return payload (verdict, score, up to three questions, link, token) that several parameters feed.

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 and resource ("turns a goal into a task card") plus the audience and the outcome the card supports ("any unknown agent can act on"). It explicitly distinguishes itself from the sibling lint_task, so an agent can route without opening a 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?

Names the caller profile ("a principal, or an agent that hands work to others") and gives an explicit alternative with its selecting condition ("Use lint_task instead when you only want to judge a task text and store nothing"). It also spells out the three mutation modes keyed on brief+token, so the when-to-use picture is complete.

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

All AstraNL Crossing tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?