The short answer is no. But there's a good reason why you'd never want to do this:
Method sensors define rules which are implemented by the agent. If the agent has to capture the method argument at runtime, then it's already incurred the cost of capturing. Then you're proposing that it further uses conditional logic to determine if it should do what it already did, namely capture method arguments. The conditional logic further adds to the work done by the agent.
Instead of the above approach, the Dynatrace agent captures the method behavioral data, including method arguments if specified, then simply gets that data off the monitored host. This minimizes the amount of work (which translates into overhead) performed by the agent and actually provides richer (every user, user transaction, every time) data for less overhead.
One thing you can do is define sensors, measures and associated BTs to define that set of purepaths which only contain method invocations with certain method argument values. So the filtering you're referring to is actually better done on the DT Server, rather than in the agent.
Hope this detail helps explain the benefits of the architecture and philosophy of optimal usage patterns.