Add Limitless Library with native MCP installation metadata

[jeremydixon22]

Adds Limitless Library, an alpha Python CLI and stdio MCP server, to Development & Workflow and adds a native MCP representation to the catalog generator. Descriptions explicitly prefixed with MCP server: produce platform: mcp, ecosystems: [mcp], and an installation_url linking to the project README. Both generated feeds preserve that documentation link without inventing a client-plugin manifest URL. Existing client-plugin installation links are retained when the same repository also exposes MCP tools.

Validation: 11 generator tests pass, including native metadata in both feeds, upstream-unavailable generation, mixed client-plugin/MCP support, and unchanged manifest discovery for unmarked entries. Full generation against the live Codex and Grok upstream feeds succeeds and produces 752 entries in each export; Limitless appears exactly once in each with native MCP metadata and the installation-documentation link. Alphabetical and live contribution/discovery checks pass. The artifact workflow now runs the generator tests; its fork run awaits maintainer approval and generated feed files remain workflow-owned. Existing unverified-manifest warnings for other repositories are outside this change; this is not a claim that every catalog installation link has been verified.

Kantorcodes confirmed that the 81/100 score meets the threshold, the nonzero scanner exit is advisory, and source-owned scanner CI is optional. Current CONTRIBUTING.md, workflows, and published checks still enforce no critical/high findings. Two existing contribution-check tests also fail while expecting advisory scans to succeed; those files are identical to upstream main 80858bc. This proposal leaves scan policy unchanged and makes no passing-gate claim. Related policy discussion: #426. Independently checked the latest published action v1.2.780: its verified, provenance-checked scanner 3.37.0 also returns 81/100 with the same two high fixture findings on unchanged public source 3681451. Updating the action pin alone does not resolve this gate.

This is a discovery listing and installation-documentation representation, not an adoption, endorsement, or automatic installer.

[github-actions]

@jeremydixon22, the required source scan must pass before merge.

The centralized source scan returned: failure. A passing scan (score at least 80 with no critical or high findings) is required before merge. Review the rule-level findings and rerun the scan.

Scanner CI in the source repository is optional. The centralized scan must pass; review its findings and rerun the contribution check.

Push the correction and this comment will update on the next check. Contribution requirements. Latest sweep.

[jeremydixon22]

I reproduced the centralized failure with the exact pinned action (caba2e96aa8ad2feb6cf6fca52442b52e22e779f) and its plugin-scanner==3.0.123 wheel against public source commit 3681451a66874bc21e7a411a529a3e036b87208e: score 81/100, two high findings, and one medium lockfile warning.

Both high findings are synthetic fixture tokens, used with in-memory transports:

• tests/test_publication.py:222: anonymous-session-token, accepted only by the fake PublicationWorkflowTransport in that test.
• tests/test_service_connector.py:517: test-access-token-value, used with the fake StreamingArtifactTransport and in redaction assertions.

This appears to be the test-fixture false-positive case already tracked in hol-guard #3153; #3260 proposes a bounded scanner correction. I have kept the test assertions intact. The required passing scan remains the merge gate; no suppression or exception is requested. Once the upstream correction is qualified and used by the catalog scan, this submission can be rescanned.

[kantorcodes]

The latest centralized score is 81/100, so the 80-point threshold is met; its nonzero scanner result is advisory and source-owned scanner CI is optional. The default branch at https://github.com/Univeracity/limitlesslibrary has no manifest path recognized by the catalog generator, so the generated install link would fall back to a missing .codex-plugin/plugin.json. Please add a supported manifest or propose a native install representation the catalog can generate, then rerun the artifact check and request review.

[jeremydixon22]

@kantorcodes, the native MCP representation is ready for review. All 11 generator tests pass, and full local generation against the live Codex and Grok upstream feeds succeeds, with Limitless appearing once in each export and linking correctly to installation instructions. Could you review the approach and approve the pending artifact workflow?

The centralized scanner still flags the two synthetic test fixtures; an isolated reproduction with published action v1.2.780 and scanner 3.37.0 returns the same 81/100 score and two high findings. Could you clarify how the failing automated gate should be handled given your advisory guidance, also reflected in #614? The source tests and scanner thresholds remain unchanged.