BadArgumentsMissing
BadMethod calls
BadArgumentsMissing means your Call supplied fewer inputArguments than the method declares. OPC UA methods are positional and strict: every declared input must be present, in order, with no omissions and no reliance on defaults. Read the method's InputArguments property to get the exact list before calling.
What you actually see
A method that works from UaExpert's Call dialog fails from your own client with this code, and adding a placeholder argument changes the error rather than fixing it.
Why it happens
- Optional-looking arguments are not optionalOPC UA has no concept of a defaulted method argument. Every entry in the method's InputArguments property must be supplied on every call. An argument that your documentation describes as optional still needs a value, even if that value is meaningless.
- The argument list was read from the type, not the instanceInputArguments is a Property of the Method node. If you read it from the type's method declaration and the instance's method was overridden or belongs to a newer model version, your count can be short by one.
- A null or empty Variant collapsed the arrayClient libraries that skip null entries when serialising a list will send fewer arguments than you intended. The server counts what arrived, not what you wrote, so a null in the middle of the list looks like a missing argument.
- Model version mismatch after a firmware upgradeCompanion-spec methods gain arguments across versions. A client built against an earlier version of a model sends the old argument count to a server that now implements the newer signature, and the newer mandatory argument is missing.
- Structure argument sent as separate scalarsWhen an input argument is a Structure, it counts as one argument. Flattening it into its member values sends the wrong number of arguments; when the flattened count is lower than declared you get this code rather than a type error.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Read the method's InputArguments propertyBrowse the Method node for its HasProperty reference to InputArguments and read the value: an array of Argument structures giving Name, DataType, ValueRank and Description for each input, in order. That array is the contract.
- Send exactly that count, in that orderBuild your inputArguments array by iterating the Argument array so the length always matches. Never construct the list from hardcoded literals, which is what drifts when the server model is updated.
- Supply explicit values for arguments you do not care aboutUse a zero, an empty string or an empty array of the declared DataType rather than a null Variant. The value must be present and typed; the server is entitled to reject a null where a scalar is declared.
- Inspect inputArgumentResults on the responseCallMethodResult carries a per-argument status array alongside the overall statusCode. Once the count is right, that array tells you which specific argument is wrong, which is far more useful than the single service status.
- Regenerate client bindings after a model upgradeIf the server's companion-spec version changed, re-read the argument definitions and update your call sites. Pin the model version you tested against and treat an argument-count change as a breaking interface change.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | The Call dialog is generated from InputArguments, so it shows you the authoritative name, type and order of every input. Use it as the reference when writing the call in code. |
| node-opcua | session.getArgumentDefinition(methodId) returns the input and output Argument arrays. Build inputArguments from it and set both dataType and value on every entry; a missing dataType is a frequent cause of a silently dropped argument. |
| asyncua (Python) | call_method passes positional Python values and infers Variant types. Where inference is ambiguous wrap the value in ua.Variant with the declared VariantType so nothing is dropped or mistyped. |
| UA-.NETStandard (C#) | session.Call takes a params object array, so an argument omitted at the call site compiles fine. Read the Argument array once and assert the length in a wrapper before every call. |
| open62541 (C) | UA_Client_call takes an inputSize and an input array; an inputSize that does not match the method declaration is exactly this code. Keep the size and the array construction in one place. |
What it looks like in the log
Call ns=4;i=7112 -> BadArgumentsMissing (sent 2 inputArguments, method declares 3)
InputArguments: [JobId:String, Quantity:UInt32, Comment:String]Confirm the fix
Call succeeds with a Good CallMethodResult statusCode and every entry of inputArgumentResults Good. Re-read InputArguments after any server upgrade and confirm the declared count still matches what your client sends.
Stop it happening again
Generate the argument list from the server's own InputArguments property at runtime, or from the pinned model version at build time, and assert the count in a single call wrapper. Never write positional literals into call sites scattered through a codebase.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.