List Avaible ONNX operators for custom libraries

[JorgeMIng]

I have been using the function "onnxruntime.capi.onnxruntime_pybind11_state.get_all_operator_schema()" to retrieve all the OpSchemas of the operators. I believe the function does not extend to custom operators introduced with "register_custom_ops_library()". I have been examining the library and the code to find any information or method to get this information. Does anyone know where new operators are stored or how to access their metadata?

The information does not need to be directly a OpSchema at least the functions and then I can try to parse the information from there.

[Advait Kawale (Advait251206)]

Hi,

You’re right that onnxruntime.capi.onnxruntime_pybind11_state.get_all_operator_schema() is not a general discovery mechanism for operators registered from external custom-op libraries.

ONNX Runtime custom operators are registered through a library’s RegisterCustomOps function, which adds a custom-op domain to the session options. The registration API is designed to make operators available to a session; it does not document a public API for enumerating every registered custom operator and retrieving its full schema afterward. See the [custom operator documentation](https://onnxruntime.ai/docs/reference/operators/add-custom-op.html).

For a custom library you control, the most reliable approach is to expose or maintain your own metadata alongside RegisterCustomOps. For example, you could provide a separate exported function or JSON manifest containing each operator’s:

• domain and operator name
• input/output counts and types
• optional or variadic input/output information
• supported attributes, including types and defaults
• shape-inference information, if applicable

If you need metadata from an operator implementation at registration time, the custom-op definitions contain information such as the operator name, input/output type and count callbacks, and attribute-related callbacks. However, that information is not equivalent to a complete ONNX OpSchema, and you would still need to collect and expose it yourself.

One important distinction: ONNX Runtime’s contrib operators are built into the runtime and have separately documented schemas; external custom operators are registered by the library that implements them. See the [contrib operator documentation](https://onnxruntime.ai/docs/reference/operators/ContribOperators.html).

So, if the library is third-party and does not expose a metadata function or manifest, there may not be a supported runtime API to retrieve the full metadata. You would likely need to inspect its source or ask its maintainers to expose that information.

If this answer helped or pointed you in the right direction, I'd appreciate it if you could mark it as the accepted answer so it's easier for others with the same issue to find.

Also, if you found my contribution useful, I'd appreciate it if you could check out my GitHub profile, follow me, and star any repositories you find interesting.

GitHub: https://github.com/Advait251206

[jinwoo (dev-jinwoohong)]

The source entry point you want is CreateCustomRegistry(). In a non-minimal build it walks domain->custom_ops_, builds schemas with CreateSchema(domain->domain_, ops), and registers them in an ORT CustomRegistry. InferenceSession::AddCustomOpDomains() attaches that registry to the session.

By contrast, get_all_operator_schema() reads the global ONNX schema registry, so calling it after loading your custom-op library won't enumerate that session's custom schemas.

If you're modifying ORT, the schemas vector immediately before RegisterOpSet() is a concrete place to inspect or expose the generated metadata. That would be an internal source-build hook, not an existing Python enumeration API.

[JorgeMIng]

Yes i know, the thing those schemas are already store internally in the session, this was some months ago but i did develop a modification in ORT to add the binding which was not added.

[JorgeMIng]

I did a PR for that #25665

[JorgeMIng]

Also thanks for the feedback