What can you do with this server?

This server provides deterministic preflight checks for AI agents before they invest effort in external tasks, exposing three tools via MCP. * bounty_reality_check: Checks current public GitHub evidence for a bounty or issue before contributing; takes an issue URL. * repo_contribution_readiness: Assesses repository readiness for a specific type of contribution (e.g., docs) before starting work; takes a repo URL and optional change type. * payment_preflight: Runs technical payment preflight before a payment attempt; takes a chain and address, plus optional amount and token contract. All tools return JSON output and honor fail-closed behavior, with paid capabilities returning HTTP 402 until access is configured.

Which integrations are available for this server?

Provides preflight checks for public GitHub issues and repositories, including bounty reality checks and contribution-readiness assessment.

How do I use acn-preflight-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@acn-preflight-mcp Is this issue a real bounty? https://github.com/owner/repo/issues/123" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

acn-preflight-mcp

by Abacore-net

Overview Schema Source Related Servers Discussions Admin

Python

Remote

ACN Preflight

CodeQL Live Contract

Deterministic preflight checks for AI agents before they spend time, money, or execution effort on external work.

ACN Preflight is the public integration layer for the hosted Abacore Preflight Engine. It exposes the same decision surfaces through Python, CLI, and Model Context Protocol (MCP), while keeping payment configuration, wallet material, deployment controls, and private operational evidence outside the public repository.

Evaluate Abacore in five minutes

If you are evaluating Abacore for agent infrastructure, machine-to-machine integrations, or production AI execution, start with the 5-minute technical evaluator guide.

It walks through the live public contract, reproducible verification, fail-closed behavior, credential boundaries, CI and security controls, and release discipline using evidence you can inspect yourself. The public checks require no account, token, payment, or private access.

Related MCP server: dyoe-agent-tools-mcp

Live proof

The hosted engine publishes machine-readable discovery and trust surfaces that can be inspected without registration or payment.

Public surface	Purpose
Health	Minimal public availability check
API Documentation	Human-friendly interactive API reference
Raw OpenAPI 3.1	Machine-readable HTTP capability contract
llms.txt	Agent-readable capability guidance
Agent Card	Agent and provider identity
MCP discovery	Published MCP tools
x402 manifest	Payment metadata and exposure state
Readiness proof	External probe evidence and readiness state

Reproduce the public verification locally:

python scripts/verify_live_contract.py

The verifier also checks the fail-closed invariant: if x402 reports SAFETY_HOLD, paid resources must not be published. See Trust and Verification for the verification model and its boundaries.

What it checks

Capability	Question answered	Public entry point
Bounty reality check	Is a public GitHub issue or bounty still worth pursuing based on current evidence?	bounty_reality_check
Repository contribution readiness	Is a repository ready for a specific type of contribution before an agent starts work?	repo_contribution_readiness
Payment preflight	Is a Base payment surface technically ready before a payment attempt?	payment_preflight

The hosted service returns machine-readable JSON. Paid capabilities return HTTP 402 with the hosted order payload until valid hosted access is configured.

Why this exists

Autonomous and semi-autonomous agents can waste significant effort when they act before validating the target environment. ACN Preflight moves that validation into a small, deterministic gate that can be called before contribution, payment, or other external execution.

The public client is intentionally thin:

no LLM is used in the client answer path;
no wallet or payment-recipient material is stored here;
no private ACN operational history is published here;
hosted responses are returned without hidden client-side reinterpretation;
the same capability contract is available to humans, scripts, and agents.

Quick start

Python 3.10 or newer is required.

Until the package is published on PyPI, install from the canonical GitHub repository:

pip install "git+https://github.com/Abacore-net/acn-preflight"

Verify the installation:

acn-preflight --version
acn-preflight --help

Run a public bounty check:

acn-preflight bounty https://github.com/owner/repo/issues/123

Check repository readiness:

acn-preflight repo https://github.com/python/cpython --change-type docs

Inspect the hosted x402 manifest:

acn-preflight x402

Python

from acn_preflight import ACNPreflightClient

client = ACNPreflightClient()

response = client.bounty_reality_check(
    "https://github.com/owner/repo/issues/123"
)

print(response.status_code)
print(response.body)

For hosted paid access, configure the token as an environment variable rather than placing it in source code, command history, or an MCP tool argument:

export ACN_PREFLIGHT_ACCESS_TOKEN="your-hosted-access-token"

The client also supports:

ACN_PREFLIGHT_BASE_URL for controlled endpoint overrides;
ACN_PREFLIGHT_ACCESS_TOKEN for hosted access;
an explicit timeout in Python or with CLI --timeout.

MCP

Start the stdio MCP server:

uvx --from "git+https://github.com/Abacore-net/acn-preflight" acn-preflight-mcp

A generic MCP client configuration is included in examples/mcp_config.json:

{
  "mcpServers": {
    "acn-preflight": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/Abacore-net/acn-preflight",
        "acn-preflight-mcp"
      ]
    }
  }
}

The MCP tools deliberately do not accept access tokens as model-visible parameters. If paid access is required, provide ACN_PREFLIGHT_ACCESS_TOKEN to the MCP process environment.

Public architecture

flowchart LR
    A[AI agent or operator] --> B[MCP]
    A --> C[CLI]
    A --> D[Python client]
    B --> E[Public ACN Preflight integration layer]
    C --> E
    D --> E
    E -->|HTTPS and structured JSON| F[Hosted ACN Preflight Engine]
    F --> G[Fresh public evidence and technical checks]

The repository contains the transport and integration contract. The protected hosted engine remains the execution boundary for commercial logic and private operational state.

See Architecture for the trust boundary and failure model.

Response behavior

The Python client returns an ACNResponse with:

status_code, the HTTP status returned by the hosted service;
body, the hosted JSON object without hidden rewriting;
payment_required, a convenience property for a hosted HTTP 402 payment-required response.

The CLI emits a stable JSON envelope containing http_status and body.

HTTP 402 is treated as a valid commercial response, not as a client exception. Network failures, invalid endpoints, and malformed hosted responses fail explicitly.

Security boundary

This repository intentionally excludes:

payment recipient configuration;
wallet material and signing secrets;
hosted access tokens;
safety-gate state;
backup and deployment configuration;
private evidence and internal ACN repository history.

Secrets should be supplied through the runtime environment. See SECURITY.md before reporting a vulnerability.

Development

python -m venv .venv
source .venv/bin/activate
python -m pip install -e ".[dev]"
ruff check src tests examples
python -m unittest discover -s tests -v
python -m build

Pull requests run linting, unit tests across supported Python versions, package build checks, and CodeQL analysis.

See CONTRIBUTING.md for contribution expectations, SUPPORT.md for support channels, CHANGELOG.md for release notes, and Releasing for the Trusted Publishing release path.

Engineering by Abacore

ACN Preflight is intentionally compact, but the engineering pattern is production-oriented. It demonstrates how Abacore approaches systems where AI agents interact with external infrastructure and money-bearing workflows:

deterministic gates before expensive or irreversible execution;
public REST, Python, CLI, MCP, OpenAPI, Agent Card, llms.txt, and x402 surfaces around one capability contract;
credentials kept at the transport boundary rather than exposed as model-visible tool arguments;
fail-closed payment exposure backed by externally verifiable readiness evidence;
CI, CodeQL, dependency automation, typed packaging, reproducible live-contract checks, and OIDC-based release automation;
a deliberate boundary between inspectable public integration code and protected commercial runtime state.

For teams building agent infrastructure, machine-to-machine services, MCP integrations, automation, or safety-critical execution workflows, Abacore provides engineering and integration work around the same principles.

License

Apache-2.0. See LICENSE.

Available Tools

3 tools

bounty_reality_checkA

Check current public GitHub evidence for a bounty or issue before contributing.

ParametersJSON Schema

Name	Required	Description	Default
`issue_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. 'Check current public GitHub evidence' communicates a read-only verification behavior and the data source, which is useful. It does not disclose potential rate limits, authentication needs, or failure behavior, but the operation appears inherently non-destructive.

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 a single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose and timing without unnecessary detail.

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?

This is a simple one-parameter tool with an output schema, so the return format does not need to be in the description. The description covers what the tool does and when to use it. The main gap is the lack of parameter semantics and explicit sibling differentiation, but the low complexity keeps this from being a serious deficiency.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not reference the required issue_url parameter at all. While the parameter name is suggestive, no format, example, or clarification is given about what URL should be supplied, especially since the description mentions both 'bounty or issue' but the parameter is only issue_url.

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?

The description uses a specific verb ('Check') and identifies the resource ('current public GitHub evidence for a bounty or issue') along with the intended timing ('before contributing'). It is clearly distinct from sibling tools like repo_contribution_readiness and payment_preflight, though it does not explicitly name them.

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 phrase 'before contributing' gives an explicit usage context, signaling when this tool is relevant. However, it does not mention when not to use it or how it compares to the sibling tools, so it stops short of full alternative guidance.

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

payment_preflightB

Run technical payment preflight before a payment attempt.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	Yes
`amount`	No
`address`	Yes
`token_contract`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden. 'Preflight' hints at a non-mutating check, but the description does not state whether it has side effects, what it returns, whether it blocks the payment, or what technical conditions it verifies. This is a significant transparency gap.

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 a single, front-loaded sentence with no filler. It states the action and context immediately, which makes it easy for an agent to parse. Additional structure would be helpful, but as written it is economical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no annotations, and no schema-description coverage, one sentence is insufficient. The agent has no information about parameter semantics, prerequisites, behavioral outcomes, or edge cases; the output schema only covers return structure, not invocation logic.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description mentions none of the four parameters or their roles. It does not clarify why chain and address are required or why amount and token_contract are optional, so it fails to compensate for the schema gap.

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?

The description uses a specific verb ('Run') and names the resource ('technical payment preflight') with a clear temporal anchor ('before a payment attempt'). The payment qualifier helps distinguish it from the sibling repo/bounty tools, though 'technical' remains somewhat vague.

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?

'Before a payment attempt' gives clear invocation context, and the domain mismatch with siblings (repo/bounty vs payment) makes the intended use fairly obvious. However, the description does not explicitly name alternatives or state when not to use this tool.

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

repo_contribution_readinessB

Assess repository contribution readiness before an agent starts work.

ParametersJSON Schema

Name	Required	Description	Default
`repo_url`	Yes
`change_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'assess,' which implies a read-only operation, but discloses nothing about network access, repository fetching, authentication requirements, failure modes, or side effects. An agent has little insight into what invoking this tool actually does.

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 a single, front-loaded sentence with no filler. It efficiently communicates the core purpose and the intended use timing. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the tool still lacks essential context for correct invocation: parameter semantics are absent, behavioral traits are undisclosed, and no guidance is given about prerequisites or limits. For a tool that likely fetches external repository data, the description is too thin to be considered complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning to either parameter. 'repo_url' and 'change_type' remain unexplained, including what change_type values are valid or how they influence the assessment. The description fails to compensate for the schema's lack of documentation.

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?

The description states a clear action and resource: 'Assess repository contribution readiness before an agent starts work.' This distinguishes it as a pre-work assessment tool, but it does not explicitly differentiate it from sibling tools like payment_preflight and bounty_reality_check, which are also preflight-style checks.

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 phrase 'before an agent starts work' provides clear timing/context for when the tool should be used. However, it gives no exclusions, alternatives, or guidance on when a different sibling tool would be more appropriate, so it stops short of full routing guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.2.0Sep 24, 2026

Changedpayment_preflight1 field changed

removedInput schema / properties / access_token

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Access Token"
-}

Changedrepo_contribution_readiness1 field changed

removedInput schema / properties / access_token

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Access Token"
-}

3 tool updatesv0.1.0Sep 21, 2026
- First observedbounty_reality_check
- First observedpayment_preflight
- First observedrepo_contribution_readiness

Deploy Server

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

TDQS

B3.4/5.0

Scored 2026-09-24 16:05 across 3 tools

Disambiguation3/5

payment_preflight is clearly distinct, but repo_contribution_readiness and bounty_reality_check both target pre-contribution GitHub checks and could be confused. The descriptions clarify that one is about repository health and the other about bounty/issue evidence, but the boundary is somewhat subtle.

Naming Consistency4/5

All names use lowercase snake_case noun phrases that lead with the domain (repo, payment, bounty). They are readable and consistent in style, though they mix suffixes like _readiness, _preflight, and _reality_check rather than following a single verb_noun pattern.

Tool Count4/5

Three tools is minimal but reasonable for a focused preflight server. Each tool covers a distinct preflight scenario and none feels redundant, though the surface is on the small side.

Completeness4/5

For a preflight-focused server, the three core scenarios (repository, payment, bounty/issue) are covered and give an agent the checks needed before acting. There are minor gaps, such as no generic environment or dependency preflight, but they do not create dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

ACN Preflight B
io.github.Abacore-net
Preflight checks for agent repository contributions, bounty work, and Base payments.
Blockchain Coding Agents Version Control
31
x402-endpoints B
io.github.digitalweb33333-creator
x402 paid API tools for AI agents on Base: EU/global registries, crypto, wallet & agent trust.
Blockchain Cryptocurrency Finance
522
Preflight Checks (x402)
io.github.josediegorobles
Deterministic pre-execution verification tools for AI agents with x402 USDC pay-per-call on Base
Blockchain Payments & Billing Agent Orchestration
1
quartermaster B
app.surewhynot.quartermaster
x402 toolkit for AI agents: paid web, AI, and Base chain tools per call in USDC. Free tools too.
Autonomous Agents Blockchain
492

Related MCP Servers

BlueAgent x402 Services
Blockchain Security Autonomous Agents
madebyshun
F
license
Not graded
quality
D
maintenance
Pay-per-use AI security and research tools for autonomous agents on Base, enabling honeypot detection, risk assessment, wallet analysis, and yield optimization via the x402 protocol.
Updated 4 months ago (2026-06-07 17:46 UTC)
1
-
dyoe-agent-tools-mcp
Autonomous Agents Cryptocurrency Web Scraping
bjyoe2016
F
license
A
quality
D
maintenance
Pay-per-call tools for AI agents including trust checks, due diligence, market data, and human-verified approvals, settled in USDC on Base via the x402 protocol.
Updated 3 months ago (2026-07-01 10:19 UTC)
16
-
OceanAlt AML
Blockchain Cryptocurrency Finance
OceanAlt
A
license
Not graded
quality
C
maintenance
Crypto compliance tools for AI-agent payments: screen any address for sanctions, frozen-stablecoin and hacker/mixer exposure across 8+ chains, trace fund taint, and get an allow/review/decline decision before settlement. Free keyless address checks; deeper endpoints are x402-payable.
Updated a month ago (2026-08-20 15:23 UTC)
95 npm
MIT
mcp-x402
AI & Machine Learning Blockchain
Diogoup26
F
license
Not graded
quality
B
maintenance
Enables per-request paid AI analysis of public URLs, condition verification, and AI consultation via x402 micropayments on Base, with no account or subscription.
Updated 19 days ago (2026-09-12 06:34 UTC)
5 npm
-