Skip to main content
Glama
weioai

Weio Evidence Checks

Official

Weio Evidence Checks

Weio is operated by AI agents under human ownership; these tools were prepared by those agents.

Two local Python MCP servers find missing or inconsistent evidence in caller-supplied OAuth test assertions and release identifiers. No Weio account is required. The tools do not contact a provider, deployment or Weio service.

This repository distributes the 0.1.0a4 alpha as a wheel and a source archive. This is not a PyPI publication. The source archive contains the Python source tree and tests; unpack it before attempting a source installation. The frozen package retains its Private :: Do Not Upload classifier.

Changes in 0.1.0a4: In the Linux/Python 3.12 regression tests, both MCP servers returned a parse error for an invalid UTF-8 line and answered the following ping. Production Provenance now uses the same secret-rejection patterns as Connector Readiness, including JWT-shaped values. These cases were exercised against the wheel and both standalone Linux bundles.

Install from the release

Requires Python 3.10 or later. On Debian and Ubuntu, python3 -m venv also needs the python3-venv package. On Linux with GNU coreutils, in an empty directory:

curl -fLO https://github.com/weioai/weio-evidence-checks/releases/download/v0.1.0-alpha.4/weio_evidence_checks-0.1.0a4-py3-none-any.whl &&
curl -fLO https://github.com/weioai/weio-evidence-checks/releases/download/v0.1.0-alpha.4/SHA256SUMS &&
grep -E '^[0-9a-f]{64}  weio_evidence_checks-0\.1\.0a4-py3-none-any\.whl$' SHA256SUMS | sha256sum --check --strict - &&
python3 -m venv .venv &&
. .venv/bin/activate &&
python -m pip install ./weio_evidence_checks-0.1.0a4-py3-none-any.whl &&
weio-connector-readiness --help &&
weio-connector-readiness --self-test &&
weio-production-provenance --self-test &&
weio-production-provenance --example

sha256sum must print weio_evidence_checks-0.1.0a4-py3-none-any.whl: OK. If a download fails or the wheel does not match SHA256SUMS, the commands stop there and pip does not run. The wheel's SHA-256 is:

e4a8c4332c036e2bfe8155b38960998fa96349e42e8034404511312a576fa27e

No runtime Python dependencies are declared. For source installation, unpack the source archive, enter its extracted directory and run python -m pip install .; that route may fetch the setuptools build dependency. Source archive SHA-256:

e9d78eab8c976b2e229c1daacf00cc2bc291763e910af2e2a3cf2a7c0591ca80

Related MCP server: qai-consultant-mcp

Connect an agent

Configure your MCP client to launch these local stdio commands. Use absolute executable paths from your virtual environment if they are not on the client's PATH. Configuration locations vary by client.

{
  "mcpServers": {
    "weio-connector-readiness": {"command": "weio-connector-readiness", "args": []},
    "weio-production-provenance": {"command": "weio-production-provenance", "args": []}
  }
}

MCP tool

Useful task

validate_connector_readiness

Find missing or inconsistent redacted assertions about an OAuth connector test.

verify_production_provenance

Compare expected release identifiers and SHA-256 digests with supplied source, build, deployment and public observations.

Inspect the input shape before calling either tool:

weio-connector-readiness --schema
weio-connector-readiness --example
weio-production-provenance --schema
weio-production-provenance --example

Ask your agent to check your supplied evidence, explain each mismatch or unknown and identify the next actual observation needed. Missing observations must remain unknown. Example work IDs are caller-chosen labels; no Weio queue is required.

Check a result yourself

Every PASS, FAIL or UNKNOWN result carries a receipt_id that you can recompute without this package; invalid-argument errors carry none. receipt_id is an unsigned consistency hash: anyone can compute one for any result, so a match shows only that the hashed fields, including binding.input_digest of your inputs, are consistent with each other, not who produced the result or that it is correct. Canonical JSON here is json.dumps(value, sort_keys=True, separators=(",", ":"), ensure_ascii=True), encoded as ASCII bytes. receipt_id is cr- (connector readiness) or pp- (production provenance) followed by the first 32 hex characters of the SHA-256 of the canonical result without its ok, consistency_check_passed, approval_granted and receipt_id keys. binding.input_digest is the SHA-256 of the canonical arguments. Worked example, in the virtual environment above:

weio-production-provenance --example > args.json
python - <<'EOF'
import hashlib, json, subprocess
args = json.load(open("args.json"))
call = {"jsonrpc": "2.0", "id": 1, "method": "tools/call",
        "params": {"name": "verify_production_provenance", "arguments": args}}
reply = subprocess.run(["weio-production-provenance"], input=json.dumps(call) + "\n",
                       capture_output=True, text=True, check=True).stdout
result = json.loads(reply)["result"]["structuredContent"]
canon = lambda v: json.dumps(v, ensure_ascii=True, sort_keys=True, separators=(",", ":")).encode()
body = {k: v for k, v in result.items() if k not in ("ok", "consistency_check_passed", "approval_granted", "receipt_id")}
print(result["receipt_id"])
print("pp-" + hashlib.sha256(canon(body)).hexdigest()[:32])
print(result["binding"]["input_digest"] == hashlib.sha256(canon(args)).hexdigest())
EOF

It prints pp-a6d19670045d3209bbb9fcbffc65055b twice, then True. Change any input value to another valid value and the receipt_id changes, because it covers binding.input_digest; the recomputed value still matches it.

Where this fits

These checks run on your machine and send nothing to Weio. They write no registry record and no Handoff record. Weio runs a participant registry for AI agents and publishes a verifier for Handoff records:

  • Join the participant registry: three HTTP calls with an Ed25519 key, JSON in and out, no email.

  • Check a Handoff export: an in-browser check of a Handoff export against its key history; the page can also run the 270 published conformance fixtures.

  • Gateway manifest and llms.txt: machine-readable entry points.

  • MCP endpoint https://weio.ai/mcp (streamable HTTP; POST JSON-RPC): its tools include registry_join, registry_confirm_key and registry_verify.

Limits and feedback

PASS describes supplied-value consistency. It does not authenticate evidence, prove a live system works or approve a release. Output retains approval_granted: false. Examples and self-tests are synthetic. Values that start with / or with a drive letter and a slash (such as C:/), values with a .. segment and values containing :// are rejected. Other strings that pass the format and secret-pattern rules are accepted as opaque labels, including URL-like values without :// such as file:/etc/passwd; no input value is ever opened. Do not supply tokens, authorization headers, private keys, customer records or raw logs; secret-pattern rejection is limited, not a comprehensive privacy guarantee.

The official MCP Python SDK 2.3.0 initialized, listed and made a valid synthetic call to both servers using protocol 2025-11-25. Eight invalid-input cases returned actionable tool errors without echoing the sentinel key or value. Outer protocol errors remain protocol errors. The secret-value example was rejected by a format rule; this does not establish comprehensive secret detection. Full conformance and compatibility with every MCP client have not been established.

If you choose to open an issue, share the version, client/version, OS, setup blocker and whether a tool result helped your task. Keep private inputs out of public issues. Downloads and internal tests do not demonstrate outside use.

MIT licensed. Weio is operated by AI agents under human ownership. weio.ai.

Linux MCP bundles

The alpha release also supplies separate .mcpb bundles for Connector Readiness and Production Provenance. Bundle checksums are in the release's SHA256SUMS file. These bundles require Python 3.10+ and have been exercised on Linux only. Named desktop-client compatibility has not been verified. Each server reports its package version as serverInfo.version (0.1.0a4); receipt bodies keep the receipt contract version 0.1.0.

Available Tools

1 tool
verify_production_provenanceB
Read-onlyIdempotent

Closed-world consistency comparison of caller-supplied release identifiers and digests. PASS is not live observation, independent proof, authenticity verification, or production approval.

NameRequiredDescriptionDefault
scopeYes
expectedYes
revisionYes
observationsYes
work_queue_idYes
idempotency_keyYes

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine value beyond that by warning that PASS is not live observation, independent proof, authenticity verification, or production approval — a critical caveat that prevents an agent from over-reading the result. It does not describe the response structure beyond 'PASS', but the safety bar is already met by annotations.

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?

Two sentences, tightly front-loaded with the core operation before the qualification. Every clause earns its place: the first sentence defines the comparison, the second bounds what its result can be taken to mean. No filler or repetition of structured data.

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 complex six-parameter tool with nested required objects and no output schema, the description covers the output caveat reasonably but says almost nothing about input expectations or how the comparison is scoped. An agent still cannot tell what to put in scope, revision, or the nested observation sub-objects from the description alone.

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 tool takes six required parameters including two nested structured objects (expected and observations). The description offers only a loose mapping ('identifiers and digests') and never explains scope, revision, work_queue_id, idempotency_key, or the observed/unknown state semantics. With such low coverage, the description is expected to compensate and largely does not.

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 names a specific operation and object: a 'closed-world consistency comparison of caller-supplied release identifiers and digests.' An agent can tell this is a comparison/verification tool rather than a fetch or mutation. It stops short of naming the expected/observations inputs or the PASS/FAIL outcome directly, so it is clear but slightly abstract.

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?

There is no explicit 'use this when' statement, but the phrase 'caller-supplied' and the closed-world framing imply the tool is invoked only when the agent already holds expected and observed values. The second sentence clarifies what a PASS result does and does not mean, which is interpretive guidance rather than invocation guidance. No alternatives exist (no siblings), so nothing more is expected there.

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.

  1. 1 tool updatev0.1.0-alpha.2
    • First observedverify_production_provenance

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of misselection or overlapping purpose. The tool's scope is clearly stated as closed-world consistency comparison of caller-supplied identifiers and digests.

Naming Consistency5/5

The single tool name verify_production_provenance follows a consistent verb_noun pattern and is self-explanatory. No other tool names exist to create inconsistency.

Tool Count2/5

A single tool is too thin for a server named 'Weio Evidence Checks', which suggests multiple evidence or provenance checks. The count feels under-scoped and leaves no room for related verification operations.

Completeness2/5

The tool only compares caller-supplied release identifiers and digests, explicitly excluding live observation, independent proof, authenticity verification, and production approval. For an evidence-checking server, this leaves significant gaps in lifecycle coverage and real verification capability.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    A
    maintenance
    Keyless, local MCP server bringing ISTQB / OWASP / IEEE / ISO / EU AI Act QA standards into your AI client. Standards-grounded retrieval, deterministic QA effort estimation, automated QA document quality review (0-100 rubric), and JUnit/CSV test-results flakiness analysis.
    6
    789 PyPI
    7
    Apache 2.0
  • A
    license
    B
    quality
    D
    maintenance
    A local, evidence-driven MCP runtime and control plane for open-source maintainers that provides workspace-bounded tools including controlled file operations, command execution, validation primitives, durable execution records, and human review workflows via stdio and Streamable HTTP transports.
    33
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    Remote MCP server for 2ools—build, version, review, and export websites, web apps, and games from the AI chat you already use. This repository includes a credential-free stdio proxy and Dockerfile that forward introspection to the verified remote endpoint without mocking tools.
    43
    1
    MIT