Short answer
Submit through the public Aescut submission flow and come prepared with the real source of truth: repository URL, install method, maintainer identity, permissions, and enough documentation for an auditor to understand what the tool actually does.
The more structured the metadata is, the faster and more credibly the tool can be reviewed.
Recommended path
- 01
Start with the public submission path
Use the Aescut submission form or the public registry contribution path if you are contributing through GitHub.
- 02
Provide the source of truth
Include the canonical repository, installation method, documentation, and any release or package registry links.
- 03
Disclose permissions and auth expectations honestly
Auditors can usually find missing details anyway, and the review will move faster if the maintainer does not force that rediscovery from scratch.
What a good submission includes
- Repository URL and, ideally, a package or release URL.
- Whether the entry is a skill, an MCP server, or both.
- Install metadata that a host can execute or inspect safely.
- Required environment variables and which ones are secret.
- Enough documentation to explain the intended use case and trust boundaries.
What slows review down
Anonymous maintainers, missing licenses, unclear install steps, generated code with no provenance, and tools that claim to be "read-only" while hiding write-capable actions all slow review or push the risk tier upward.
Sources and further reading
Related questions
Security And Trust
How does Aescut review skills and MCP servers?
Aescut’s review pipeline, what gets pinned, and how human review and automation fit together.
Security And Trust
What do the risk levels mean?
How to interpret Aescut’s risk levels, trusted maintainers, and stale reviews without oversimplifying them.
Data And API
Can I use the registry data in my own project?
Licensing, APIs, feeds, and practical ways to build on Aescut without guessing.