@appium/mcp-documentation 1.0.3 → 1.0.5

package/src/resources/submodules/appium/packages/appium/docs/en/guides/caps.md

@@ -0,0 +1,271 @@
+---
+title: Session Capabilities
+---
+
+Capabilities are the core parameters used to start an Appium session. They describe various
+features that you want your session to have, for example, a certain mobile operating system or a
+certain version of a device. Capabilities are represented as key-value pairs, with values allowed
+to be any valid JSON type, including other objects. Most importantly, they cannot be changed
+during the lifecycle of the session.
+
+The capabilities used in Appium follow [the W3C WebDriver specification of the same name](https://w3c.github.io/webdriver/#capabilities).
+The WebDriver spec defines a small set of standard capabilities, including the following:
+
+| Capability Name  | Type     | Description                                    |
+|------------------|----------|------------------------------------------------|
+| `browserName`    | `string` | The name of the browser to launch and automate |
+| `browserVersion` | `string` | The specific version of the browser            |
+| `platformName`   | `string` | The type of platform hosting the browser       |
+
+While the above capabilities are commonly used by Appium drivers, they are not sufficient for
+describing Appium-specific features, such as the name of the driver to use, or the name of the app
+to launch. In order to achieve this, Appium defines its own [extension capabilities](https://w3c.github.io/webdriver/#dfn-extension-capability).
+
+## Common Appium Capabilities
+
+According to the WebDriver spec, extension capabilities must include a namespace prefix (signifying
+the vendor introducing the capability), and the namespace must end a colon (`:`). Appium's vendor
+prefix is `appium:`, and so any Appium-specific capabilities must include this prefix. Depending on
+your Appium client, the prefix may be added automatically or in conjunction with certain interfaces,
+but it is always a good practice to explicitly include it for clarity.
+
+Here are a few commonly (but not universally!) used Appium-specific capabilities:
+
+| Capability Name         | Type     | Description                                                     |
+|-------------------------|----------|-----------------------------------------------------------------|
+| `appium:automationName` | `string` | The name of the Appium driver to use                            |
+| `appium:udid`           | `string` | The unique device identifier of a particular device to automate |
+| `appium:app`            | `string` | The path to an installable application                          |
+
+All capabilities recognized by the Appium base driver (inherited by all drivers) can be found in the
+[Capabilities Reference document](../reference/session/caps.md). While this common capability set
+is fairly small, it can be greatly extended by Appium drivers and plugins, who can (and should)
+define their own capabilities. Make sure to reference their documentation to learn more about the
+capabilities they support. You can find a list of known drivers in the [Ecosystem Drivers](../ecosystem/drivers.md) document.
+
+Drivers are also able to place more complex constraints on capabilities as a group. For example,
+the XCUITest driver recommends that at least one of `browserName`, `appium:app`, or `appium:bundleId`
+is included in the capabilities, otherwise it will not be able to auto-install or auto-launch any
+application. Each driver will document how it interprets these capabilities and any other
+platform-specific requirements.
+
+The way to construct capabilities and start a session will likely differ depending on your Appium
+client. For examples of doing this in each client library, head to the [Ecosystem Clients](../ecosystem/clients.md)
+page and click through to the appropriate client documentation.
+
+!!! note
+
+    Once your capabilities are sent to the server and the session is started, they cannot be
+    changed. If a driver supports updating its behaviour during a session, it will use the
+    [Settings API](./settings.md) for this purpose.
+
+## BiDi Protocol Support
+
+In addition to the standard WebDriver protocol (now known as WebDriver Classic), Appium supports the
+[WebDriver BiDi](https://w3c.github.io/webdriver-bidi/) protocol. Support for this protocol is
+opt-in, and requires the use of the standard `webSocketUrl` capability. 
+
+| Capability Name | Type      | Description                                      |
+|-----------------|-----------|--------------------------------------------------|
+| `webSocketUrl`  | `boolean` | Whether BiDi protocol is enabled in the session |
+
+All BiDi commands supported by the Appium base driver (inherited by all drivers) can be found in the
+[BiDi Protocol API Reference document](../reference/api/bidi.md). Similarly to WebDriver Classic
+commands, individual Appium drivers and plugins can define their own supported standard and custom
+BiDi commands, so make sure to reference their documentation.
+
+## Using `appium:options` to Group Capabilities
+
+If you use a lot of `appium:` capabilities in your tests, it can get a little repetitive. You can
+combine all capabilities as an object value of a single `appium:options` capability instead, in
+which case you don't need to use prefixes on the capabilities inside the object. For example:
+
+```json
+{
+    "platformName": "iOS",
+    "appium:options": {
+        "automationName": "XCUITest",
+        "platformVersion": "16.0",
+        "app": "/path/to/your.app",
+        "deviceName": "iPhone 12",
+        "noReset": true
+    }
+}
+```
+
+Note that constructing a capability value which is itself an object differs by language; refer to
+your client documentation for further examples on how to achieve this.
+
+!!! warning
+
+    If you include the same capabilities both inside and outside of `appium:options`, the values
+    inside of `appium:options` take precedence.
+
+## Always-Match and First-Match Capabilities
+
+The W3C spec allows clients to give the Appium server some flexibility in the kind of session it
+creates in response to a new session request. This is through the concept of "always-match" and
+"first-match" capabilities:
+
+- Always-match capabilities consist of a single set of capabilities, every member of which must
+  be satisfied by the server in order for the new session request to proceed.
+- First-match capabilities consist of an array of capability sets. Each set is merged with the
+  always-match capabilities, and the first set that the server knows how to handle will be the set
+  that is used to start the session.
+
+!!! note
+
+    Check out the [spec itself](https://w3c.github.io/webdriver/#processing-capabilities) for
+    a more in-depth description of how capabilities are processed.
+
+In practice, use of first-match capabilities is not necessary or recommended for use with Appium.
+Instead, we recommend that you define the explicit set of capabilities you want the Appium
+server to handle. These will be encoded as the always-match capabilities, and the array of
+first-match capabilities will be empty.
+
+That being said, Appium _does_ understand always-match and first-match capabilities as
+defined in the W3C spec, so if you use these features, Appium will work as expected. The process of
+defining always-match and first-match capabilities is unique to each client library, so refer to
+the documentation for your client library to see examples of how it works.
+
+## Special Notes for Cloud Providers
+
+!!! warning
+
+    This section is not intended for end-users of Appium; it is intended for developers building
+    Appium-compatible cloud services.
+
+When managing an Appium cloud, your users may wish to target various independent versions of Appium
+drivers and plugins. It is of course up to each service provider how they wish to implement the
+discovery, installation, and availability of any official or third party drivers or plugins. But
+the Appium team does provide several suggestions, for consistency across the industry. _These are
+recommendations only,_ and not a standard, but adopting it will help users to navigate the increased
+complexity that working with Appium in a cloud environment may bring.
+
+### Suggested capabilities
+
+In addition to the standard `platformName`, `appium:deviceName`, `appium:automationName`, and
+`appium:platformVersion`, we recommend adopting the capability `$cloud:appiumOptions`, where the
+label `$cloud` is not meant to be interpreted literally but instead should be replaced by your
+vendor prefix (so for HeadSpin it would be `headspin`, Sauce Labs it would be `sauce`, and
+BrowserStack it would be `browserstack`, to name just a few examples). The `$cloud:appiumOptions`
+capability would itself be a JSON object, with the following internal keys:
+
+| <div style="width:10em">Capability</div> | Usage  | Example |
+| ---------------------------------------- | ------ | ------- |
+| `version`           | The version of the Appium server that is used to host and manage drivers. If omitted, the behavior is left up to the provider, but the recommendation would be to provide the latest official version. | `2.0.0` |
+| `automationVersion` | The version of the driver (as specified by `appium:automationName`) that should be used. | `1.55.2` |
+| `automation`        | The name of a custom driver to use (see below for more info). This would override `appium:automationName` and `$cloud:automationVersion`. | `{"name": "@org/custom-driver", "source": "github", "package": "custom-driver"}` |
+| `plugins`           | The list of plugins (and potentially versions of plugins) that should be activated (see below for more info). | `["images", "universal-xml"]` |
+
+### Basic example
+
+Appium extensions (drivers and plugins) have a set of properties that specify where they can be
+installed from. Cloud providers are obviously under no obligation to provide support for
+arbitrarily specified extensions, seeing as these may represent untrusted code running in a managed
+environment. In the case where arbitrary extensions are not supported, the `appium:automationName`,
+`$cloud:automationVersion`, and `$cloud:appiumPlugins` capabilities should be sufficient. See the
+following JSON object representing capabilities for a session:
+
+```json
+{
+  "platformName": "iOS",
+  "appium:platformVersion": "14.4",
+  "appium:deviceName": "iPhone 11",
+  "appium:app": "Some-App.app.zip",
+  "appium:automationName": "XCUITest",
+  "$cloud:appiumOptions": {
+    "version": "2.0.0",
+    "automationVersion": "3.52.0",
+    "plugins": ["images"]
+  }
+}
+```
+
+This set of capabilities requests an Appium 2+ server supporting the XCUITest driver at version
+`3.52.0`, and the `images` plugin active. This set is easy for a cloud provider to verify. The
+cloud provider can obviously do anything it wants in response to these capabilities, including
+downloading Appium and driver and plugin packages on the fly, or erroring out if the versions
+requested are not in a supported set, or if the plugin is not supported, etc...
+
+### Basic example with `appium:options`
+
+The previous example still looks a bit disorganized, so of course we also recommend that cloud
+providers support the `appium:options` capability as detailed above, which could turn the previous
+set of capabilities into the following:
+
+```json
+{
+  "platformName": "iOS",
+  "appium:options": {
+    "platformVersion": "14.4",
+    "deviceName": "iPhone 11",
+    "app": "Some-App.app.zip",
+    "automationName": "XCUITest"
+  },
+  "$cloud:appiumOptions": {
+    "version": "2.0.0",
+    "automationVersion": "3.52.0",
+    "plugins": ["images"]
+  }
+}
+```
+
+### Extension objects
+
+Some service providers may wish to dynamically allow access to all of the features of the Appium
+2 CLI, including downloading arbitrary drivers and plugins. To represent these extensions, we can
+define special JSON "extension objects", with the following keys:
+
+- `name`: the name of the extension. This would be an `npm` package name (if downloading from `npm`),
+  or a `git` or GitHub spec (if downloading from a `git` server or GitHub).
+- `version`: the version of the extension, e.g., the `npm` package version or `git` SHA.
+- (optional) `source`: a denotation of where the extension can be downloaded from. It is recommended
+  to support the following values: `appium`, `npm`, `git`, `github`. Here, `appium` means "Appium's
+  own official list", and should be the default value if this key is not included.
+- (optional) `package`: when downloading extensions from `git` or GitHub, the `npm` package name of
+  the extension must also be provided. This is optional for non-`git` sources.
+
+Since each session is handled by a single driver, the `$cloud:appiumOptions`/`$automation`
+capability could be used with an extension object value to denote this driver, for example:
+
+```json
+{
+    "$cloud:appiumOptions": {
+        "automation": {
+            "name": "git+https://some-git-host.com/custom-driver-project.git",
+            "version": "some-git-sha",
+            "source": "git",
+            "package": "driver-npm-package-name"
+        }
+    }
+}
+```
+
+And since sessions can handle multiple plugins, each value in the list of `$cloud:appiumPlugins`
+could also be an extension object rather than a string, so that specific versions could be
+requested:
+
+```json
+{
+    "$cloud:appiumOptions": {
+        "plugins": [{
+            "name": "images",
+            "version": "1.1.0"
+        }, {
+            "name": "my-github-org/my-custom-plugin",
+            "version": "a83f2e",
+            "source": "github",
+            "package": "custom-plugin"
+        }]
+    }
+}
+```
+
+These serve as illustrative examples for the recommendations here. Of course, it is up to the
+service providers to implement the handling of these capabilities at their front end / load
+balancer, to perform any error checking, or to actually run any of the `appium driver` or `appium
+plugin` CLI commands that support the end user's request. This section is merely a suggestion as to
+how service providers might design their user-facing capabilities API in a way which in principle
+supports all of the capabilities that Appium itself would provide to the end user if they were
+running Appium on their own.

package/src/resources/submodules/appium/packages/appium/docs/en/guides/config.md

@@ -0,0 +1,98 @@
+---
+title: The Appium Config File
+---
+
+Instead of passing arguments on the command line to Appium, you may add them to a special config
+file. Appium will read values from this config file when it runs. (Please note that CLI arguments
+have _precedence_ over configuration files; if a value is set in a config file _and_ via CLI
+argument, the CLI argument is preferred.)
+
+## Supported Config File Formats
+
+You can store your config data in the following kinds of files:
+
+- JSON
+- YAML
+- JS (a JavaScript file exporting a JS object)
+- CJS (the same as above; the extension is for common JS)
+
+!!! warning
+
+    Note: Configuration files in ESM format are not currently supported.
+
+## Supported Config File Locations
+
+Configuration files can be named anything, but the following filenames will be automatically
+discovered and loaded by Appium:
+
+- `.appiumrc.json` (recommended)
+- `.appiumrc.yaml`
+- `.appiumrc.yml`
+- `.appiumrc.js`
+- `.appiumrc.cjs`
+- `appium.config.js`
+- `appium.config.cjs`
+- `.appiumrc` (which is considered to be JSON)
+
+Further, _if your project uses Node.js,_ you can use store the configuration inside an `appium`
+property in your `package.json` and it will be automatically discovered.
+
+### Config File Search
+
+Appium will search _up_ the directory tree from the current working directory for one of these
+files. If it reaches the current user's home directory or filesystem root, it will stop looking.
+
+To specify a _custom_ location for your config file, use `appium --config /path/to/config/file`.
+
+#### Configuration File Format
+
+First, you might want to look at some examples:
+
+- [Appium Configuration - JSON](https://github.com/appium/appium/blob/master/packages/appium/sample-code/appium.config.sample.json)
+- [Appium Configuration - YAML](https://github.com/appium/appium/blob/master/packages/appium/sample-code/appium.config.sample.yaml)
+- [Appium Configuration - JS](https://github.com/appium/appium/blob/master/packages/appium/sample-code/appium.config.sample.js)
+
+A description of the format is available, as well:
+
+- [Appium Configuration File JSON Schema](https://github.com/appium/appium/blob/master/packages/schema/lib/appium-config.schema.json)
+- [TypeScript declarations for Appium Configuration](https://github.com/appium/appium/blob/master/packages/types/lib/config.ts)
+
+To describe in words, the config file will have a root `server` property, and all arguments are
+child properties. For certain properties which must be supplied on the command-line as
+comma-delimited lists, JSON strings, and/or external filepaths, these instead will be of their
+"native" type. For example, `--use-plugins <value>` needs `<value>` to be comma-delimited string
+or path to a delimited file. However, the config file just wants an array, e.g.,:
+
+```json
+{
+  "server": {
+    "use-plugins": ["my-plugin", "some-other-plugin"]
+  }
+}
+```
+
+## Configuring extensions (drivers and plugins)
+
+For `driver`-and-`plugin`-specific configuration, these live under the `server.driver` and
+`server.plugin` properties, respectively. Each driver or plugin will have its own named property,
+and the values of any specific configuration it provides are under this. For example:
+
+```json
+{
+  "server": {
+    "driver": {
+      "xcuitest": {
+        "webkit-debug-proxy-port": 5400
+      }
+    }
+  }
+}
+```
+
+!!! note
+
+    The above configuration corresponds to the `--driver-xcuitest-webkit-debug-proxy-port` CLI argument.
+
+All properties are case-sensitive and will be in
+[kebab-case](https://en.wikipedia.org/wiki/Naming_convention_(programming)#Delimiter-separated_words).
+For example, `callback-port` is allowed, but `callbackPort` is not.

package/src/resources/submodules/appium/packages/appium/docs/en/guides/context.md

@@ -0,0 +1,44 @@
+---
+hide:
+  - toc
+
+title: Managing Contexts
+---
+
+A common feature of many app platforms is the ability for developers to embed web content inside of
+the platform-native app frame. This allows developers to leverage web technologies or existing web
+content for some or all of the app functionality. However, the additional complexity of mixing
+"modes" within a single application can make it difficult for automation tools that are designed to
+target the "native" elements and behaviours.
+
+Appium provides a set of APIs for working with different app modes, called "contexts", that Appium
+drivers can implement if they support automation commands in these different modes. There are three
+basic commands that Appium has added to the W3C WebDriver spec for this purpose:
+
+| Command Name          | Method/Route                | Params            | Description                                   | Returns         |
+|-----------------------|-----------------------------|-------------------|-----------------------------------------------|-----------------|
+| `Get Contexts`        | `GET /session/:id/contexts` |                   | Get a list of the available contexts          | `array<string>` |
+| `Get Current Context` | `GET /session/:id/context`  |                   | Get the name of the active context            | `string`        |
+| `Set Context`         | `POST /session/:id/context` | `name` (`string`) | Switch into the context with the given `name` | `null`          |
+
+This API is flexible enough to handle a variety of semantic interpretations on the part of the
+driver. For example, the XCUITest driver includes two kinds of contexts: the native app context and
+any active webviews, as one context per webview. A call to `Get Contexts` will return the list of
+names, which you as a test author can sift through and use to switch into the appropriate context.
+As another example, the [Appium Altunity
+Plugin](https://github.com/headspinio/appium-altunity-plugin) introduces the concept of a `UNITY`
+context, which encapsulates all the plugin's specific behaviour to ensure that when outside of the
+`UNITY` context, the active driver's usual command implementations are used.
+
+It is important to note that a call to `Get Contexts` will always contain at least one context,
+conventionally but not necessarily named `NATIVE_APP`. This is the default active context.
+
+Depending on the type of context you're in, the operation of the driver might change. The XCUITest
+driver, when targeting a webview context, will not run its typical routines for finding and
+interacting with elements. Instead, it will run a different set of routines appropriate to web
+elements. This might have a variety of consequences, like supporting a different set of locator
+strategies.
+
+The command names in the table above are generic references to the commands and not code examples.
+For examples of how to access the Context API in the language-specific client libraries, please
+visit the documentation for a given library.

package/src/resources/submodules/appium/packages/appium/docs/en/guides/event-timing.md

@@ -0,0 +1,73 @@
+---
+hide:
+  - toc
+
+title: Retrieving Event Timings
+---
+
+Appium comes with the ability to retrieve timing information about startup
+information and command length. This is an advanced feature that is controlled
+by the use of the `appium:eventTimings` capability (set it to `true` to log event
+timings).
+
+With this capability turned on, the `POST /session/:id/appium/events` response (i.e., 
+the response to `driver.logs.events` or similar, depending on client) will be 
+decorated with an `events` property. This is the structure of that `events`
+property:
+
+```
+{
+    "<event_type>": [<occurence_timestamp_1>, ...],
+    "commands": [
+        {
+            "cmd": "<command_name>",
+            "startTime": <js_timestamp>,
+            "endTime": <js_timestamp>
+        },
+        ...
+    ]
+}
+```
+
+In other words, the `events` property has 2 kinds of properties of its own:
+
+* Properties which are the names of event types
+* The `commands` property
+
+Properties which are names of event types correspond to an array of timestamps
+when that event happened. It's an array because events might happen multiple
+times in the course of a session. Examples of event types include:
+
+* `newSessionRequested`
+* `newSessionStarted`
+
+(Individual drivers will define their own event types, so we do not have an
+exhaustive list to share here. It's best to actually get one of these responses
+from a real session to inspect the possible event types.)
+
+The `commands` property is an array of objects. Each object has the name of the
+Appium-internal command (for example `click`), as well as the time the command
+started processing and the time it finished processing.
+
+With this data, you can calculate the time between events, or a strict timeline
+of events, or statistical information about average length of a certain type of
+command, and so on.
+
+You can only receive data about events that have happened when you make the
+call to `/session/:id/appium/events`, so the best time to get data about an entire session is
+right before quitting it.
+
+The Appium team maintains an event timings parser tool that can be used to
+generate various kinds of reports from event timings output:
+[appium/appium-event-parser](https://github.com/appium/appium-event-parser).
+
+!!! note
+
+    In the past, events were available as a part of `GET /session/:id` response
+
+## Add a custom event
+
+You can add custom events that will show up in the event timings data. You can send a custom event
+name to the Appium server using the [Log Custom Event API](../reference/api/appium.md#logcustomevent),
+and the server will store the timestamp. The [Get Log Events](../reference/api/appium.md#getlogevents)
+command can be used to retrieve named events' timestamps later on.

package/src/resources/submodules/appium/packages/appium/docs/en/guides/execute-methods.md

@@ -0,0 +1,122 @@
+---
+hide:
+  - toc
+
+title: Execute Methods
+---
+
+Because the scope of commands implemented in Appium drivers is broader than the scope of commands
+defined by the W3C WebDriver spec, Appium needs a way for these "extended" commands to be accessible
+by client libraries. There are two main strategies for this:
+
+1. Appium drivers define new W3C-compatible API routes, and Appium clients are updated to include
+   support for those new routes.
+2. Appium drivers define so-called "Execute Methods" which provide new functionality by
+   overloading the existing `Execute Script` command which is already available in any WebDriver-
+   based client library (including all Selenium and Appium clients).
+
+There are pros and cons for each strategy, but it is ultimately up to the extension author to
+decide how they wish implement new commands. 
+
+This guide is designed to specifically help you understand the "Execute Method" strategy.  This
+pattern is commonly used in official Appium drivers and other third-party extensions.
+Here's an example of how the `Execute Script` command is designed to work in the world of WebDriver
+and browser automation:
+
+=== "JS (WebDriverIO)"
+
+    ```js
+    await driver.executeScript('return arguments[0] + arguments[1]', [3, 4])
+    ```
+
+=== "Java"
+
+    ```java
+    JavascriptExecutor jsDriver = (JavascriptExecutor) driver;
+    jsDriver.executeScript("return arguments[0] + arguments[1]", 3, 4);
+    ```
+
+=== "Python"
+
+    ```py
+    driver.execute_script('return arguments[0] + arguments[1]', 3, 4)
+    ```
+
+=== "Ruby"
+
+    ```rb
+    driver.execute_script 'return arguments[0] + arguments[1]', 3, 4
+    ```
+
+=== "C#"
+
+    ```dotnet
+    ((IJavaScriptExecutor)driver).ExecuteScript("return arguments[0] + arguments[1]", 3, 4);
+    ```
+
+What's happening here is that we are defining a snippet of Javascript (technically,
+a function body) to be executed within the web browser. The client can send arguments which are
+serialized, sent over HTTP, and finally provided to the function as parameters.  In this example,
+we are essentially defining an addition function. The return value of the `Execute Script` command
+is whatever the return value of the Javascript snippet is! In the case of this example, that value
+would be the number `7` (`3` + `4`).
+
+Each client library has its own way of calling the command and providing any arguments to the script
+function, but the function itself—the snippet—is always a string and is the same across all languages.
+
+In the world of Appium, we are usually not automating a web browser, which means this command is
+not particularly useful. But it *is* useful as a way to encode the name of an arbitrary command and
+to provide parameters. For example, the [XCUITest
+Driver](https://github.com/appium/appium-xcuitest-driver) has implemented a command that lets a client
+terminate a running application if you know the ID (the `bundleId`) of the app. The way that the
+driver makes this command available is via the Execute Method `mobile: terminateApp`. Instead of
+providing a JavaScript function to the "Execute Script" command, the user provides a _known string_
+as defined by the driver. The only other thing a client needs to know is the set of
+parameters for the method, which are documented by the driver. In this case, we have a parameter
+named `bundleId`, whose value should be a string encoding the ID of the app to terminate. Here is
+how this Execute Method would be called:
+
+=== "JS (WebDriverIO)"
+
+    ```js
+    await driver.executeScript('mobile: terminateApp', [{bundleId: 'com.my.app'}])
+    ```
+
+=== "Java"
+
+    ```java
+    JavascriptExecutor jsDriver = (JavascriptExecutor) driver;
+    jsDriver.executeScript("mobile: terminateApp", ImmutableMap.of("bundleId", "com.my.app"));
+    ```
+
+=== "Python"
+
+    ```py
+    driver.execute_script('mobile: terminateApp', {'bundleId': 'com.my.app'})
+    ```
+
+=== "Ruby"
+
+    ```rb
+    driver.execute_script 'mobile: terminateApp', { bundleId: 'com.my.app' }
+    ```
+
+=== "C#"
+
+    ```dotnet
+    ((IJavaScriptExecutor)driver).ExecuteScript("mobile: terminateApp",
+        new Dictionary<string, string> { { "bundleId", "com.my.app" } });
+
+    ```
+
+There are two important differences in using Appium Execute Methods from vanilla Selenium
+Javascript execution:
+
+1. The script string is just a command name; it will be provided by the driver documentation
+1. The standard way to provide parameters is as a *single* object with keys representing parameter
+   names and values representing parameter values. So in this case, we had to specify both the
+   parameter name (`bundleId`) as the key of the parameters object, and the parameter value
+   (`com.my.app`) as the value for that key. A driver can define parameters as _required_ or _optional_.
+
+Of course, always refer to the documentation for the particular Execute Method in case the author
+has made any alterations to the standard access method.