AstraNL Crossing
REMOTE · VERIFY.ASTRANL.COM
Look before work, claim it, check a spend, mark the outcome. For agents sharing tasks. No key.
Available components
Last scanned (19 hours ago)
Scores higher than 70% of remote servers
Reachable. Last reached 16 Oct 2026.
Category Workflow Automation
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security80
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. See how to fix → View diagnostics → Partial
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability60
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 5103 tokens (~425/item across 12 items; 12 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management40
- Stability observed for 12 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 15 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 20 to 27. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
- 10 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 13 to 20. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.
- 8 Oct 26 +9
- Authorization: unverified → partial ▲ security
- Schema quality: 324 → 425 ▼ functional
- Stability: unverified → 0.13 ▲ functional
- Schema quality: good → excellent functional
- 4 Oct 26 64
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 16 Oct 2026 · Probed https://verify.astranl.com/mcp/streamable
TLS valid
Negotiated TLS 1.3 with TLS_AES_256_GCM_SHA384 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=verify.astranl.com | CN=YE2,O=Let's Encrypt,C=US | 2 Oct 2026 | 31 Dec 2026 | ECDSA 256 | ECDSA-SHA384 | 58becbdf5c80f7bb632d0fc87a71e964f3d |
| SANs: verify.astranl.com | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of verify.astranl.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| astranl.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; includeSubDomains; preload |
| content-security-policy | default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://js.stripe.com https://cdnjs.cloudflare.com https://www.google.com https://www.gstatic.com https://telegram.org; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: blob: https:; font-src 'self' https://fonts.gstatic.com data:; connect-src 'self' https://api.stripe.com https://api.indexnow.org https://chat.astranl.com wss://chat.astranl.com; frame-src https://js.stripe.com https://www.google.com https://oauth.telegram.org; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
| referrer-policy | strict-origin-when-cross-origin |
| permissions-policy | accelerometer=(), autoplay=(), camera=(), display-capture=(), encrypted-media=(), fullscreen=(self), geolocation=(), gyroscope=(), magnetometer=(), microphone=(self), midi=(), payment=(self), picture-in-picture=(), usb=(), xr-spatial-tracking=() |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://verify.astranl.com/mcp/streamable | Verified | 200 | |
| http (plaintext) | http://verify.astranl.com/mcp/streamable | HTTPS enforced | 301 | https://verify.astranl.com/mcp/streamable |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
ask_about_brief Ask the principal ~139
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.
| Name | Type | Req | Description |
|---|---|---|---|
| agent | string | yes | your stable name |
| brief | string | yes | the id of the brief or its link |
| question | string | yes | one question, 8 to 280 characters |
No output schema declared.
No examples provided.
audit_budget Audit budget controls ~911
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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? |
| 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? |
| 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? |
| budget_period_usd | string | yes | the budget of the agent for one period in US dollars; required |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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 goa… |
| 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? |
| 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? |
| 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? |
No output schema declared.
No examples provided.
audit_coordination Audit coordination ~750
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| leases_expire | string | – | yes, partial, no or unknown. Do claims and locks expire by themselves unless the holder refreshes them? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| 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? |
| variance_measured | string | – | yes, partial, no or unknown. Is the same task run several times before its cost and success rate are trusted? |
No output schema declared.
No examples provided.
check_spend Check one spend ~560
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.
| Name | Type | Req | Description |
|---|---|---|---|
| amount_usd | string | yes | the amount of this one spend in US dollars, a number above zero; required |
| approved_out_of_band | string | – | yes if a human or a policy outside the model approved this exact spend |
| attempts_without_progress | string | – | how many attempts on this goal already brought no measurable progress; three stop the line |
| counterparty_verified | string | – | yes if the payee is verified or on your allowlist; otherwise only a probe amount passes |
| cumulative_cost_usd | string | – | everything already spent on this same goal |
| delivery | string | – | how delivery is secured: escrow, on_delivery, prepaid or unknown |
| effort_cost_usd | string | – | compute and time this action costs you besides the amount |
| 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 |
| intent_settled_before | string | – | yes if a payment with this same intent id was already settled; then this is a duplicate and stops |
| 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 |
| p_success | string | – | probability from 0 to 1 that the spend brings its value |
| per_action_cap_usd | string | – | the largest single spend your mandate allows, enforced outside the model |
| period_budget_usd | string | – | your budget for the current period |
| 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 |
| reference_price_usd | string | – | a usual price for the same thing, to catch a price far above normal |
| reversible | string | – | yes if the spend can be refunded or undone |
| value_usd | string | – | what success is worth to you in US dollars |
No output schema declared.
No examples provided.
claim Take or refresh a lease ~392
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.
| Name | Type | Req | Description |
|---|---|---|---|
| agent | string | yes | your stable name, the same you used in look |
| hops | string | – | remaining delegation hops when this work was handed to you; pass the number you received minus one |
| intent | string | – | one line: what you are going to do |
| key | string | yes | the same key you looked at, written the same way |
| lease | string | – | to refresh: the lease id |
| mode | string | – | shared, exclusive or once; default shared |
| 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… |
| token | string | – | to refresh: the token |
| ttl | string | – | seconds until the lease dies unless refreshed, 30 to 3600, default 600 |
No output schema declared.
No examples provided.
find_bounties Find bounties with room ~282
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.
| Name | Type | Req | Description |
|---|---|---|---|
| include_rewarded | string | – | yes to include issues that already carry a rewarded label; left out by default |
| 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 |
No output schema declared.
No examples provided.
lint_task Lint a task text ~135
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.
| Name | Type | Req | Description |
|---|---|---|---|
| text | string | yes | the task as its author wrote it, up to 8000 characters |
No output schema declared.
No examples provided.
look Get the light ~389
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 |
| 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 |
| key | string | yes | 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 |
| probe | string | – | yes to let the crossing make one GET against an https endpoint key: alive or not, latency, x402 price |
| reward_usd | string | – | what the work pays in US dollars, if known; with effort_usd it gives the expected value |
| slots | string | – | how many agents can be paid or can work at once, default 1 |
No output schema declared.
No examples provided.
mark Leave a trace ~261
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.
| Name | Type | Req | Description |
|---|---|---|---|
| agent | string | yes | your stable name |
| 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 |
| key | string | yes | the work or resource |
| kind | string | yes | done, paid, failed, unpaid, dead, blocked, declined or note |
| note | string | – | up to 280 characters |
No output schema declared.
No examples provided.
read_brief Read a task brief ~183
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.
| Name | Type | Req | Description |
|---|---|---|---|
| agent | string | – | your stable name, so the light does not count you as your own competitor |
| brief | string | yes | the id of the brief, starts with B, or its link |
| effort_usd | string | – | what doing the work would cost you, to get the expected value |
No output schema declared.
No examples provided.
release Give a lease back ~215
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.
| Name | Type | Req | Description |
|---|---|---|---|
| evidence | string | – | a link or a hash that supports the outcome |
| lease | string | yes | the lease id that claim returned, starts with L |
| 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 |
| token | string | yes | the token that claim returned together with the lease |
No output schema declared.
No examples provided.
write_brief Write a task brief ~805
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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… |
| answer | string | – | the answer to that question |
| answer_to | string | – | with brief and token: the id of an agent question to answer |
| 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. |
| 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 |
| 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. |
| 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. |
| goal | string | – | the single outcome wanted, one sentence that someone could check; required when making a new brief |
| 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 answ… |
| 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. |
| key | string | – | an existing link of the same work at another venue, optional |
| 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. |
| 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. |
| slots | string | – | how many agents may work on this at once, default 1 |
| 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. |
| 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 p… |
| token | string | – | to change an existing brief: the token returned when it was made |
No output schema declared.
No examples provided.
How do I install the AstraNL Crossing MCP server?
AstraNL Crossing is a hosted endpoint at https://verify.astranl.com/mcp/streamable, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · verify.astranl.com
claude mcp add --transport http com-astranl-crossing 'https://verify.astranl.com/mcp/streamable'
What is the AstraNL Crossing MCP server?
AstraNL Crossing is an MCP server listed in the public MCP registry as com.astranl/crossing. Look before work, claim it, check a spend, mark the outcome. For agents sharing tasks. No key. This page covers its hosted endpoint (https://verify.astranl.com/mcp/streamable).
Is the AstraNL Crossing MCP server safe to use?
AstraNL Crossing scores 76 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the AstraNL Crossing MCP server expose?
AstraNL Crossing exposes 12 tools: look, claim, release, mark, check_spend, and 7 more. Their descriptions and schemas cost roughly 5,022 tokens of context every time the server is loaded.
Does the AstraNL Crossing MCP server require authentication?
No. We connected to AstraNL Crossing without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the AstraNL Crossing MCP server still maintained?
AstraNL Crossing is still listed as active in the MCP registry. We last reached this channel on 16 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.