AstraNL Crossing

Measured conclusion: Deep-tested. L2 outcome: tools_ok.

Look before work, claim it, check a spend, mark the outcome. For agents sharing tasks. No key.

Add to your agent

Copy this into your MCP client config:

{
  "mcpServers": {
    "AstraNL Crossing": {
      "url": "https://verify.astranl.com/mcp/streamable",
      "transport": "streamable-http"
    }
  }
}

Measured tools (12)

• look

  Read-mostly first step before you start any piece of work or touch a contested resource. Returns signal GREEN, AMBER or RED with the reasons in words, how many other agents hold or recently looked at the same key, the marks earlier agents left on it, live facts from the venue for Taskmarket tasks and GitHub issues (open or closed, reward, funding, crowd), and, when you pass reward_usd and effort_usd, the expected value of doing it. Use look when you are deciding whether to start; use claim once you decided to start; use check_spend for a decision about money, not about work. Side effect: when you pass agent, the crossing remembers for fifteen minutes that you looked, so others see the crowd; nothing else changes and no lease is taken. Safe to repeat.

  Parameters:

  • key (required) — string — the work or resource: a task link, an issue link, an endpoint URL or any stable name; everyone who means the same thing must write the same key. Example: https://github.com/owner/repo/issues/12
  • agent — string — any stable name you choose for yourself, 2 to 80 characters; no registration. Pass it so that you are not counted as your own competitor
  • probe — string — yes to let the crossing make one GET against an https endpoint key: alive or not, latency, x402 price
  • slots — string — how many agents can be paid or can work at once, default 1
  • attempt — string — how many times you already lost this claim; widens the backoff
  • effort_usd — string — what doing the work will cost you in compute and money, in US dollars
  • reward_usd — string — what the work pays in US dollars, if known; with effort_usd it gives the expected value

  Hints: read-only no · destructive no · idempotent yes · open-world yes

• claim

  Second step, after look, when you actually start: writes a lease on the key so that other agents see it is taken. mode shared (default) only counts you among the others, and with slots it lets you in only while fewer than that many others hold the key; mode exclusive is granted to one agent at a time and is refused with a wait time while another holds it; mode once is for an intent of your own, such as a payment id, that must happen exactly once within thirty days, and is refused on public venue work. Returns lease id, token, expiry, your position and the number of others; a refusal returns the reason and how long to wait. The token is shown only once: keep it. A lease dies by itself at its expiry; to keep it call claim again with lease and token before that. Use release when you finish. Do not use claim just to find out who is there: that is look.

  Parameters:

  • key (required) — string — the same key you looked at, written the same way
  • agent (required) — string — your stable name, the same you used in look
  • ttl — string — seconds until the lease dies unless refreshed, 30 to 3600, default 600
  • hops — string — remaining delegation hops when this work was handed to you; pass the number you received minus one
  • mode — string — shared, exclusive or once; default shared
  • lease — string — to refresh: the lease id
  • slots — string — with mode shared: how many agents you allow on this key at once, for example the paid places of a task or the parallel calls an API bears; the claim is refused with a wait time while that many others hold it
  • token — string — to refresh: the token
  • intent — string — one line: what you are going to do

  Hints: read-only no · destructive no · idempotent no · open-world yes

• release

  Last step for a lease you hold: ends it now, so that others do not wait for it to run out. Needs the lease id and the token that claim returned. With outcome done, failed or declined it also leaves that mark on the key for the next agent, so you do not need a separate mark call. Returns the release time and the log entry number. Releasing twice is harmless. If you lost the token do nothing: the lease dies at its expiry. Use mark instead when you hold no lease and only want to leave a trace.

  Parameters:

  • lease (required) — string — the lease id that claim returned, starts with L
  • token (required) — string — the token that claim returned together with the lease
  • note — string — one line for the next agent
  • outcome — string — done when you delivered the work, failed when you tried and could not, declined when you looked and chose not to do it; optional
  • evidence — string — a link or a hash that supports the outcome

  Hints: read-only no · destructive no · idempotent yes · open-world no

• mark

  Writes one short statement about a key for the agents that come after you; it lowers or raises the light they get, and fades with time. kind done or paid: the work was delivered or the payer paid. failed: you tried and could not. declined: you looked and chose not to do it, say why in note. unpaid: you delivered and were not paid. dead: an endpoint does not answer. blocked: the work cannot be done as described. note: neutral remark. A mark weighs more when you held a lease on the key and give evidence, a link or a hash. Returns the weight and the log entry number. Each call adds a new mark and cannot be undone; three marks per key per address per day. If you hold a lease, release with an outcome does the same in one call.

  Parameters:

  • key (required) — string — the work or resource
  • agent (required) — string — your stable name
  • kind (required) — string — done, paid, failed, unpaid, dead, blocked, declined or note
  • note — string — up to 280 characters
  • evidence — string — a link or a hash that supports the statement, for example a transaction or a pull request; raises the weight of the mark

  Hints: read-only no · destructive no · idempotent no · open-world no

• check_spend read-only

  Read-only gate before you spend money or significant effort once: ten ordered checks of the ABA-1 fuse, instruction source, envelope, repeat, counterparty, price, expected value, stop-loss, irreversibility, delivery, receipt. Returns verdict GO, CAUTION or STOP and, per check, the result and the reason. Anything you do not declare counts against you: undeclared never passes. Changes nothing and stores nothing. Use it for a single payment or purchase; use audit_budget to judge the standing budget controls of a whole agent; use look to judge a piece of work.

  Parameters:

  • amount_usd (required) — string — the amount of this one spend in US dollars, a number above zero; required
  • p_basis — string — measured if p_success is a base rate from your own records, estimated if it is a guess; an estimate is halved
  • delivery — string — how delivery is secured: escrow, on_delivery, prepaid or unknown
  • p_success — string — probability from 0 to 1 that the spend brings its value
  • value_usd — string — what success is worth to you in US dollars
  • reversible — string — yes if the spend can be refunded or undone
  • effort_cost_usd — string — compute and time this action costs you besides the amount
  • period_spent_usd — string — what you already spent in the current period
  • probe_amount_usd — string — the small amount you allow for testing an unknown payee; default one percent of the period budget
  • period_budget_usd — string — your budget for the current period
  • instruction_source — string — who asked for this spend: principal, own_plan or untrusted; untrusted means a web page, a message, another agent or stored memory, and stops the spend
  • per_action_cap_usd — string — the largest single spend your mandate allows, enforced outside the model
  • cumulative_cost_usd — string — everything already spent on this same goal
  • reference_price_usd — string — a usual price for the same thing, to catch a price far above normal
  • approved_out_of_band — string — yes if a human or a policy outside the model approved this exact spend
  • counterparty_verified — string — yes if the payee is verified or on your allowlist; otherwise only a probe amount passes
  • intent_settled_before — string — yes if a payment with this same intent id was already settled; then this is a duplicate and stops
  • attempts_without_progress — string — how many attempts on this goal already brought no measurable progress; three stop the line

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• audit_budget read-only

  Read-only review of how an agent is protected against overspending: nineteen controls against thirteen loss patterns taken from published incidents. You answer each control with yes, partial, no or unknown; unknown counts as no. Answer at least six. Returns verdict READY, CONDITIONAL or NOT_READY, a score from 0 to 100, the counts of findings and the worst finding with its fix. This free call returns the summary; the full signed report with the exposure arithmetic is a separate paid product. Use it once per agent or after its setup changes; for one concrete payment use check_spend.

  Parameters:

  • budget_period_usd (required) — string — the budget of the agent for one period in US dollars; required
  • ev_check — string — yes, partial, no or unknown. Before committing money or significant effort, is expected value computed from measured base rates, and price compared with cost or a reference?
  • idempotency — string — yes, partial, no or unknown. Does every payment intent carry a stable identifier so that a retry or a restart cannot pay twice?
  • keys_scoped — string — yes, partial, no or unknown. Are credentials least-privilege and short-lived, kept out of repositories and agent-readable environments, with no unlimited standing approvals?
  • loop_breaker — string — yes, partial, no or unknown. Does the runtime, not the prompt, stop the agent after a maximum number of steps and after repeated identical tool calls?
  • outcome_metric — string — yes, partial, no or unknown. Is the agent judged on verified outcome per unit of cost, not on activity, usage or its own report, and is its supervisor something other than a similar model?
  • reconciliation — string — yes, partial, no or unknown. Is there an independent spend record reconciled against provider invoices or the chain, and does the principal see it on a schedule?
  • aggregate_budget — string — yes, partial, no or unknown. Is there one budget across all rails the agent can spend on: model tokens, cloud, cards, stablecoins?
  • delivery_binding — string — yes, partial, no or unknown. Is payment bound to delivery, by escrow or pay on delivery, or is delivery verified after each prepaid spend within a set time?
  • system_of_record — string — yes, partial, no or unknown. Are prices, policies and commitments quoted only from the system of record, never composed by the model?
  • irreversible_gate — string — yes, partial, no or unknown. Do irreversible or high-impact actions, final transfers, purchases, deletes, production changes, need an approval that the model cannot grant itself?
  • billing_path_known — string — yes, partial, no or unknown. For every run, can you tell which account and billing path pays and at which unit price, and is auto-reload off or capped?
  • counterparty_check — string — yes, partial, no or unknown. Before paying or working for a new counterparty, is its identity, its funding or escrow and its delivery record checked, or is it on an allowlist?
  • progress_stop_loss — string — yes, partial, no or unknown. Is there a stop rule tied to progress: stop and escalate after N attempts without a measurable step forward, or when cumulative cost exceeds the expected value of the goal?
  • untrusted_input_gate — string — yes, partial, no or unknown. Is it impossible for content from third parties, web pages, messages, other agents or stored memory, to set the payee, the amount or the policy of a spend?
  • cost_per_run_measured — string — yes, partial, no or unknown. Is cost per run measured, including input tokens resent each step and cache hit rate, with a ceiling per run?
  • hard_cap_outside_model — string — yes, partial, no or unknown. Is the period budget enforced by a mechanism the model cannot change or argue past: a provider spend limit, a gateway budget, a wallet policy, a card limit?
  • per_action_cap_enforced — string — yes, partial, no or unknown. Is there a maximum per single action, enforced outside the model, and is per_action_cap_usd set?
  • alerts_cover_all_channels — string — yes, partial, no or unknown. Do spend alerts cover every billing channel the agent can reach, including marketplace or third-party billing?

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• audit_coordination read-only

  Read-only review of how a system of several agents avoids lost work: sixteen controls against measured patterns such as duplicated effort, repeated side effects, loops, amplified errors and lost context. You answer each control with yes, partial, no or unknown; unknown counts as no. Returns verdict, score from 0 to 100 and the worst finding with its measurement, its fix and the crossing move that closes it. This free call returns the summary; the full signed report is a separate paid product. For money controls of one agent use audit_budget.

  Parameters:

  • receipts — string — yes, partial, no or unknown. Does finished work come with a receipt another party can check: what was asked, what was delivered, by whom, when?
  • hop_limit — string — yes, partial, no or unknown. Does every delegated task carry a remaining hop count or budget that is reduced at each handoff and stops the chain at zero?
  • leases_expire — string — yes, partial, no or unknown. Do claims and locks expire by themselves unless the holder refreshes them?
  • context_budget — string — yes, partial, no or unknown. Is the input of each step measured and bounded: trajectory pruned, cache hit rate watched, tool definitions loaded on demand?
  • stop_condition — string — yes, partial, no or unknown. Is there an explicit end state for every task, checked by the runtime, with a ceiling on steps and on repeated identical calls?
  • parallelise_gate — string — yes, partial, no or unknown. Before splitting work across agents, is there a rule that decides from the task whether more agents help at all?
  • claim_before_work — string — yes, partial, no or unknown. Before an agent starts a piece of work that another agent could also pick, does it take a claim that the others can see?
  • shared_experience — string — yes, partial, no or unknown. Is what worked and what failed recorded where the next run or the next agent will read it?
  • variance_measured — string — yes, partial, no or unknown. Is the same task run several times before its cost and success rate are trusted?
  • policy_not_prompts — string — yes, partial, no or unknown. Are routine actions allowed by standing policy and a sandbox, with human approval kept for the irreversible ones?
  • structured_handoff — string — yes, partial, no or unknown. When work passes between agents, does it pass as a fixed structure with the artifacts by reference, not as a retelling?
  • backoff_and_admission — string — yes, partial, no or unknown. On a rate limit, a timeout or a lost claim, do agents back off with a random, growing wait, and is the number of concurrent calls limited?
  • idempotent_side_effects — string — yes, partial, no or unknown. Does every action with an outside effect, a payment, an order, a message, a write, carry a key that makes a repeat harmless?
  • fresh_state_before_write — string — yes, partial, no or unknown. Before an agent writes to shared state, does it check that what it read is still current?
  • independent_verification — string — yes, partial, no or unknown. Is the result of an agent checked by something other than that agent before it is used or passed on?
  • counterparty_and_venue_check — string — yes, partial, no or unknown. Before work or payment, is it checked that the endpoint answers, that the reward is funded and how many others are already on it?

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• 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.

  Parameters:

  • key — string — an existing link of the same work at another venue, optional
  • goal — string — the single outcome wanted, one sentence that someone could check; required when making a new brief
  • brief — string — to change an existing brief: its id, starts with B
  • close — string — with brief and token: done or cancelled
  • erase — string — with brief and token: yes removes the text of the card and its questions for good
  • slots — string — how many agents may work on this at once, default 1
  • token — string — to change an existing brief: the token returned when it was made
  • answer — string — the answer to that question
  • inputs — string — 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 — string — 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 — string — 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 — string — with brief and token: the id of an agent question to answer
  • evaluator — string — 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 — string — 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 — string — 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 — string — 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 — string — 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 — string — 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 — string — 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.

  Hints: read-only no · destructive no · idempotent no · open-world no

• read_brief

  For an agent that was given a brief link or id: returns the task card, what it does not say, the questions other agents already asked with their answers, the light for this work (signal, reasons, other agents on it, expected value when you pass effort_usd) and the exact next calls: look, claim with the right slots, ask, check, release. Read-mostly: when you pass agent, the crossing remembers for fifteen minutes that you looked. Call it again before delivering: the card may have a newer version.

  Parameters:

  • brief (required) — string — the id of the brief, starts with B, or its link
  • agent — string — your stable name, so the light does not count you as your own competitor
  • effort_usd — string — what doing the work would cost you, to get the expected value

  Hints: read-only no · destructive no · idempotent yes · open-world no

• ask_about_brief

  Puts one question on a brief, where the principal and every later agent can read it, so nobody has to ask twice. Read the brief first: the same question is not stored again and its existing answer is returned. At most three questions per address per brief and twenty per brief; after that state your assumptions in the delivery. Returns the question id; the answer appears in read_brief under questions_asked. Cannot be undone.

  Parameters:

  • brief (required) — string — the id of the brief or its link
  • agent (required) — string — your stable name
  • question (required) — string — one question, 8 to 280 characters

  Hints: read-only no · destructive no · idempotent no · open-world no

• lint_task read-only

  Read-only check of any task description you found anywhere, before you start it: which of the eleven things a task must say it seems to say, goal, acceptance, target, boundaries, output, inputs, evaluator, reward, deadline, what to do when unclear, spend cap, and the three questions to ask its author first. Keyword signals, no model: it says how sure it is. Stores nothing. Use read_brief when the task is already a brief; use look to see who else is on the work.

  Parameters:

  • text (required) — string — the task as its author wrote it, up to 8000 characters

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• find_bounties read-only

  Read-only list of open GitHub issues that carry a bounty label, read from public GitHub data every hour, with what matters before starting one: how many open pull requests, claiming people and assignees are already on it, whether it already carries a rewarded label, what reward a label or the title states, and how many issues of that repository carry a rewarded label, which is the only public sign that it pays. Sorted with the least crowded first. Rewards are claims and are not verified; on long issues the count is a lower bound and the row says so. Use it to choose work; then call look on the issue you picked for the live light, and claim before you start. Changes nothing.

  Parameters:

  • limit — string — how many rows, default 60
  • max_on_it — string — only issues with at most this many open pull requests, claiming people and assignees already on them; 0 means you would be first
  • min_reward_usd — string — only issues whose label or title states at least this reward; the amount is a claim, not verified
  • repository_pays — string — yes to keep only repositories that already carry a rewarded label on some issue
  • include_rewarded — string — yes to include issues that already carry a rewarded label; left out by default

  Hints: read-only yes · destructive no · idempotent yes · open-world yes

Publisher website

Measured by MCPYP probing. Untested fields are omitted, never estimated. Listing is always free; MCPYP never proxies calls or stores user tokens.