Android Management API
Server Details
Remote enterprise management of Android devices and apps
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose targeting specific resources (applications, devices, enterprises, policies, web apps) and actions (get vs. list). There is no overlap or ambiguity between tools, making it easy for an agent to select the correct one based on the desired resource and operation.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., get_application, list_devices). The verbs 'get' and 'list' are used predictably for single-item retrieval and collection listing respectively, providing a uniform and readable naming convention throughout.
With 9 tools, the count is well-scoped for an enterprise management API, covering core resources. It is slightly under for a full CRUD surface (e.g., missing create/update/delete operations), but reasonable for a read-focused server, as each tool earns its place in providing essential retrieval and listing functions.
The tool set is severely incomplete for an enterprise management domain, as it only includes get and list operations. There are significant gaps in CRUD coverage, with no create, update, or delete tools for any resource (e.g., devices, policies), which will likely cause agent failures when full lifecycle management is required.
Available Tools
9 toolsget_applicationARead-onlyIdempotentInspect
Gets application details for a given enterprise and application ID. Requires the resource name in the format: enterprises/{enterpriseId}/applications/{applicationId}.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of the application in the form `enterprises/{enterpriseId}/applications/{package_name}`. | |
| languageCode | No | The preferred language for localized application info, as a BCP47 tag (e.g. "en-US", "de"). If not specified the default language of the application will be used. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The name of the app in the form enterprises/{enterprise}/applications/{package_name}. |
| title | No | The title of the app. Localized. |
| author | No | The name of the author of the apps (for example, the app developer). |
| iconUrl | No | A link to an image that can be used as an icon for the app. This image is suitable for use up to a pixel size of 512 x 512. |
| category | No | The app category (e.g. RACING, SOCIAL, etc.) |
| features | No | Noteworthy features (if any) of this app. |
| appTracks | No | Application tracks visible to the enterprise. |
| appPricing | No | Whether this app is free, free with in-app purchases, or paid. If the pricing is unspecified, this means the app is not generally available anymore (even though it might still be available to people who own it). |
| updateTime | No | Output only. The approximate time (within 7 days) the app was last published. |
| appVersions | No | Versions currently available for this app. |
| description | No | The localized promotional description, if available. |
| permissions | No | The permissions required by the app. |
| playStoreUrl | No | A link to the (consumer) Google Play details page for the app. |
| smallIconUrl | No | A link to a smaller image that can be used as an icon for the app. This image is suitable for use up to a pixel size of 128 x 128. |
| contentRating | No | The content rating for this app. |
| recentChanges | No | A localised description of the recent changes made to the app. |
| screenshotUrls | No | A list of screenshot links representing the app. |
| fullDescription | No | Full app description, if available. |
| managedProperties | No | The set of managed properties available to be pre-configured for the app. |
| availableCountries | No | The countries which this app is available in as per ISO 3166-1 alpha-2. |
| distributionChannel | No | How and to whom the package is made available. |
| minAndroidSdkVersion | No | The minimum Android SDK necessary to run the app. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds value by specifying the resource name format constraint, which is crucial for correct invocation. It does not add information about error conditions, rate limits, or side effects, but the annotations cover the primary safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences: the first states purpose, the second states the critical format requirement. There is no redundant or wasted language; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive annotations, the description appropriately avoids duplicating return value or safety documentation. However, it fails to clarify that parameters are optional (context signals indicate 0 required parameters) despite using the word 'Requires' for the resource name, and does not mention error handling or default behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description reinforces the format requirement for the 'name' parameter but uses slightly different terminology ('applicationId' in description vs 'package_name' in schema). It does not add substantial semantic detail beyond what the schema already provides for the optional 'languageCode' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Gets application details' with specific scope (enterprise and application ID). It distinguishes from sibling 'get_' tools (get_device, get_enterprise, etc.) by specifying the 'application' resource. However, it lacks explicit differentiation from potential 'list' operations (e.g., vs list_web_apps) regarding singleton vs. collection retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the critical format requirement for the resource name ('enterprises/{enterpriseId}/applications/{applicationId}'), which acts as an implicit usage constraint. However, it lacks explicit guidance on when to use this tool versus alternatives, or prerequisites like permission requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_deviceARead-onlyIdempotentInspect
Gets device details for a given enterprise and device ID. Requires the resource name in the format: enterprises/{enterpriseId}/devices/{deviceId}.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of the device in the form `enterprises/{enterpriseId}/devices/{deviceId}`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The name of the device in the form `enterprises/{enterpriseId}/devices/{deviceId}`. |
| user | No | The user who owns the device. |
| state | No | The state to be applied to the device. This field can be modified by a patch request. Note that when calling `enterprises.devices.patch`, `ACTIVE` and `DISABLED` are the only allowable values. To enter the device into a `DELETED` state, call [`enterprises.devices.delete`](/android/management/reference/rest/v1/enterprises.devices/delete). |
| apiLevel | No | The API level of the Android platform version running on the device. |
| displays | No | Detailed information about displays on the device. This information is only available if `displayInfoEnabled` is true in the device's policy. |
| userName | No | The resource name of the user that owns this device in the form `enterprises/{enterpriseId}/users/{userId}`. |
| ownership | No | Ownership of the managed device. |
| memoryInfo | No | Memory information: contains information about device memory and storage. |
| policyName | No | The name of the policy applied to the device, in the form `enterprises/{enterpriseId}/policies/{policyId}`. If not specified, the `policy_name` for the device's user is applied. This field can be modified by a patch request. You can specify only the `policyId` when calling `enterprises.devices.patch`, as long as the `policyId` doesn’t contain any slashes. The rest of the policy name is inferred. |
| networkInfo | No | Device network information. This information is only available if `networkInfoEnabled` is true in the device's policy. |
| appliedState | No | The state currently applied to the device. |
| hardwareInfo | No | Detailed information about the device hardware. |
| memoryEvents | No | Events related to memory and storage measurements in chronological order. This information is only available if `memoryInfoEnabled` is true in the device's policy. Events are retained for a certain period of time and old events are deleted. |
| softwareInfo | No | Detailed information about the device software. This information is only available if `softwareInfoEnabled` is true in the device's policy. |
| deviceSettings | No | Device settings information. This information is only available if `deviceSettingsEnabled` is true in the device's policy. |
| disabledReason | No | If the device state is `DISABLED`, an optional message that is displayed on the device indicating the reason the device is disabled. This field can be modified by a patch request. |
| enrollmentTime | No | The time of device enrollment. |
| managementMode | No | The type of management mode Android Device Policy takes on the device. This influences which policy settings are supported. |
| policyCompliant | No | Whether the device is compliant with its policy. |
| securityPosture | No | Device's security posture value that reflects how secure the device is. |
| dpcMigrationInfo | No | Output only. Information related to whether this device was migrated from being managed by another Device Policy Controller (DPC). |
| systemProperties | No | Map of selected system properties name and value related to the device. This information is only available if `systemPropertiesEnabled` is true in the device's policy. |
| appliedPolicyName | No | The name of the policy currently applied to the device. |
| applicationReports | No | Reports for apps installed on the device. This information is only available when `application_reports_enabled` is true in the device's policy. |
| lastPolicySyncTime | No | The last time the device fetched its policy. |
| enrollmentTokenData | No | If the device was enrolled with an enrollment token with additional data provided, this field contains that data. |
| enrollmentTokenName | No | If the device was enrolled with an enrollment token, this field contains the name of the token. |
| previousDeviceNames | No | If the same physical device has been enrolled multiple times, this field contains its previous device names. The serial number is used as the unique identifier to determine if the same physical device has enrolled previously. The names are in chronological order. |
| appliedPolicyVersion | No | The version of the policy currently applied to the device. |
| lastStatusReportTime | No | The last time the device sent a status report. |
| nonComplianceDetails | No | Details about policy settings that the device is not compliant with. |
| hardwareStatusSamples | No | Hardware status samples in chronological order. This information is only available if `hardwareStatusEnabled` is true in the device's policy. |
| powerManagementEvents | No | Power management events on the device in chronological order. This information is only available if `powerManagementEventsEnabled` is true in the device's policy. |
| commonCriteriaModeInfo | No | Information about Common Criteria Mode—security standards defined in the [Common Criteria for Information Technology Security Evaluation](https://www.commoncriteriaportal.org/) (CC). This information is only available if statusReportingSettings.commonCriteriaModeEnabled is `true` in the device's policy the device is company-owned. |
| defaultApplicationInfo | No | Output only. The default application information for the `DefaultApplicationType`. This information is only available if `defaultApplicationInfoReportingEnabled` is true in the device's policy. Available on Android 16 and above. All app types are reported on fully managed devices. `DEFAULT_BROWSER`, `DEFAULT_CALL_REDIRECTION`, `DEFAULT_CALL_SCREENING` and `DEFAULT_DIALER` types are reported for the work profiles on company-owned devices with a work profile and personally-owned devices. `DEFAULT_WALLET` is also reported for company-owned devices with a work profile, but will only include work profile information. |
| appliedPasswordPolicies | No | The password requirements currently applied to the device. * This field exists because the applied requirements may be slightly different from those specified in `passwordPolicies` in some cases. * Note that this field does not provide information about password compliance. For non-compliance information, see `nonComplianceDetails`. * `NonComplianceDetail.fieldPath`, is set based on `passwordPolicies`, not based on this field. |
| lastPolicyComplianceReportTime | No | Deprecated. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/destructive hints. Description adds the input format constraint ('Requires the resource name in the format...') but does not disclose additional behavioral traits like error conditions, rate limits, or what 'details' encompass.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficiently structured sentences with critical information front-loaded. Minor deduction for redundancy with schema description regarding the name format, though this repetition serves as emphasis for a critical path parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-parameter read operation where output schema exists (obviating the need to describe return values). Could enhance by noting what device properties are included in the response, but sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description repeats the schema's format specification ('enterprises/{enterpriseId}/devices/{deviceId}') without adding semantic depth like example values, validation rules, or acquisition methods for the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb ('Gets') and resource ('device details') and clearly targets a single device vs. siblings like list_devices. Explicitly mentions 'enterprise and device ID' to scope the operation precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context through the resource name format requirement (suggesting use when you have a specific device ID), but does not explicitly contrast with list_devices or state when to prefer this over other get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_enterpriseARead-onlyIdempotentInspect
Gets an enterprise for a given enterprise ID. Requires the enterprise ID in the name field (e.g., enterprises/{enterpriseId}).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of the enterprise in the form `enterprises/{enterpriseId}`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| logo | No | An image displayed as a logo during device provisioning. Supported types are: image/bmp, image/gif, image/x-ico, image/jpeg, image/png, image/webp, image/vnd.wap.wbmp, image/x-adobe-dng. |
| name | No | The name of the enterprise which is generated by the server during creation, in the form `enterprises/{enterpriseId}`. |
| contactInfo | No | The enterprise contact info of an EMM-managed enterprise. |
| pubsubTopic | No | The topic which Pub/Sub notifications are published to, in the form `projects/{project}/topics/{topic}`. This field is only required if [Pub/Sub notifications are enabled](/android/management/notifications). |
| primaryColor | No | A color in RGB format that indicates the predominant color to display in the device management app UI. The color components are stored as follows: `(red << 16) | (green << 8) | blue`, where the value of each component is between 0 and 255, inclusive. |
| signinDetails | No | Sign-in details of the enterprise. |
| enterpriseType | No | Output only. The type of the enterprise. |
| termsAndConditions | No | Terms and conditions that must be accepted when provisioning a device for this enterprise. A page of terms is generated for each value in this list. |
| enterpriseDisplayName | No | The name of the enterprise displayed to users. This field has a maximum length of 100 characters. |
| appAutoApprovalEnabled | No | Deprecated and unused. |
| managedGoogleDomainType | No | Output only. The type of managed Google domain. |
| enabledNotificationTypes | No | The types of Google Pub/Sub notifications enabled for the enterprise. |
| googleAuthenticationSettings | No | Settings for Google-provided user authentication. |
| managedGooglePlayAccountsEnterpriseType | No | Output only. The type of a managed Google Play Accounts enterprise. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it 'Requires the enterprise ID', which clarifies mandatory input but doesn't disclose additional behavioral traits like caching, rate limits, or side effects. With annotations handling the safety context, this meets the baseline expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states purpose, the second specifies the critical parameter format. Every word earns its place and the most important information (the resource being retrieved) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with 100% schema coverage, present annotations, and an output schema (per context signals), the description provides sufficient context. It doesn't need to explain return values since the output schema handles that, and the single parameter is adequately documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents the 'name' parameter format ('enterprises/{enterpriseId}'). The description essentially restates this requirement ('Requires the enterprise ID in the name field') without adding semantic meaning like validation rules or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Gets an enterprise' with a specific 'enterprise ID', distinguishing it from sibling list operations (list_enterprises) and other get_* tools for different resources (get_device, get_policy). The verb is specific and the resource is clearly identified, though it doesn't explicitly contrast with the list alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a given enterprise ID' implies usage when a specific identifier is known, implicitly distinguishing it from list_enterprises. However, there is no explicit guidance on when to use this versus the list alternative, nor any mention of prerequisites or error conditions (e.g., enterprise not found).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_policyBRead-onlyIdempotentInspect
Gets a policy for a given enterprise and policy ID. Requires the resource name in the format: enterprises/{enterpriseId}/policies/{policyId}.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of the policy in the form `enterprises/{enterpriseId}/policies/{policyId}`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The name of the policy in the form `enterprises/{enterpriseId}/policies/{policyId}`. |
| version | No | The version of the policy. This is a read-only field. The version is incremented each time the policy is updated. |
| usageLog | No | Configuration of device activity logging. |
| funDisabled | No | Whether the user is allowed to have fun. Controls whether the Easter egg game in Settings is disabled. |
| smsDisabled | No | Whether sending and receiving SMS messages is disabled. |
| appFunctions | No | Optional. Controls whether apps on the device for fully managed devices or in the work profile for devices with work profiles are allowed to expose app functions. |
| applications | No | Policy applied to apps. This can have at most 3,000 elements. |
| cameraAccess | No | Controls the use of the camera and whether the user has access to the camera access toggle. |
| locationMode | No | The degree of location detection enabled. |
| setupActions | No | Action to take during the setup process. At most one action may be specified. |
| systemUpdate | No | The system update policy, which controls how OS updates are applied. If the update type is `WINDOWED`, the update window will automatically apply to Play app updates as well. **Note:** [Google Play system updates](https://source.android.com/docs/core/ota/modular-system) (also called Mainline updates) are automatically downloaded and require a device reboot to be installed. Refer to the mainline section in [Manage system updates](https://developer.android.com/work/dpc/system-updates#mainline) for further details. |
| playStoreMode | No | This mode controls which apps are available to the user in the Play Store and the behavior on the device when apps are removed from the policy. |
| wipeDataFlags | No | Optional. Wipe flags to indicate what data is wiped when a device or profile wipe is triggered due to any reason (for example, non-compliance). This does not apply to the `enterprises.devices.delete` method. . This list must not have duplicates. |
| autofillPolicy | No | Optional. The policy for the autofill service. |
| cameraDisabled | No | If `camera_access` is set to any value other than `CAMERA_ACCESS_UNSPECIFIED`, this has no effect. Otherwise this field controls whether cameras are disabled: If true, all cameras are disabled, otherwise they are available. For fully managed devices this field applies for all apps on the device. For work profiles, this field applies only to apps in the work profile, and the camera access of apps outside the work profile is unaffected. |
| frpAdminEmails | No | Email addresses of device administrators for factory reset protection. When the device is factory reset, it will require one of these admins to log in with the Google account email and password to unlock the device. If no admins are specified, the device won't provide factory reset protection. |
| printingPolicy | No | Optional. Controls whether printing is allowed. This is supported on devices running Android 9 and above. . |
| addUserDisabled | No | Whether adding new users and profiles is disabled. For devices where `managementMode` is `DEVICE_OWNER` this field is ignored and the user is never allowed to add or remove users. |
| complianceRules | No | Rules declaring which mitigating actions to take when a device is not compliant with its policy. When the conditions for multiple rules are satisfied, all of the mitigating actions for the rules are taken. There is a maximum limit of 100 rules. Use policy enforcement rules instead. |
| displaySettings | No | Optional. Controls for the display settings. |
| minimumApiLevel | No | The minimum allowed Android API level. |
| autoTimeRequired | No | Whether auto time is required, which prevents the user from manually setting the date and time. If [`autoDateAndTimeZone`](/android/management/reference/rest/v1/enterprises.policies#autodateandtimezone) is set, this field is ignored. |
| deviceRadioState | No | Covers controls for radio state such as Wi-Fi, bluetooth, and more. |
| encryptionPolicy | No | Whether encryption is enabled |
| keyguardDisabled | No | If true, this disables the [Lock Screen](https://source.android.com/docs/core/display/multi_display/lock-screen) for primary and/or secondary displays. This policy is supported only in dedicated device management mode. |
| microphoneAccess | No | Controls the use of the microphone and whether the user has access to the microphone access toggle. This applies only on fully managed devices. |
| passwordPolicies | No | Password requirement policies. Different policies can be set for work profile or fully managed devices by setting the `password_scope` field in the policy. |
| permissionGrants | No | Explicit permission or group grants or denials for all apps. These values override the `default_permission_policy`. |
| safeBootDisabled | No | Whether rebooting the device into safe boot is disabled. |
| bluetoothDisabled | No | Whether bluetooth is disabled. Prefer this setting over `bluetooth_config_disabled` because `bluetooth_config_disabled` can be bypassed by the user. |
| maximumTimeToLock | No | Maximum time in milliseconds for user activity until the device locks. A value of 0 means there is no restriction. |
| statusBarDisabled | No | Whether the status bar is disabled. This disables notifications, quick settings, and other screen overlays that allow escape from full-screen mode. DEPRECATED. To disable the status bar on a kiosk device, use [InstallType](/android/management/reference/rest/v1/enterprises.policies#installtype) `KIOSK` or `kioskCustomLauncherEnabled`. |
| vpnConfigDisabled | No | Whether configuring VPN is disabled. |
| alwaysOnVpnPackage | No | Configuration for an always-on VPN connection. Use with `vpn_config_disabled` to prevent modification of this setting. |
| kioskCustomization | No | Settings controlling the behavior of a device in kiosk mode. To enable kiosk mode, set `kioskCustomLauncherEnabled` to `true` or specify an app in the policy with `installType` `KIOSK`. |
| longSupportMessage | No | A message displayed to the user in the device administators settings screen. |
| removeUserDisabled | No | Whether removing other users is disabled. |
| stayOnPluggedModes | No | The battery plugged in modes for which the device stays on. When using this setting, it is recommended to clear `maximum_time_to_lock` so that the device doesn't lock itself while it stays on. |
| wifiConfigDisabled | No | Whether configuring Wi-Fi networks is disabled. Supported on fully managed devices and work profiles on company-owned devices. For fully managed devices, setting this to true removes all configured networks and retains only the networks configured using `openNetworkConfiguration`. For work profiles on company-owned devices, existing configured networks are not affected and the user is not allowed to add, remove, or modify Wi-Fi networks. If `configureWifi` is set to anything other than `CONFIGURE_WIFI_UNSPECIFIED`, this setting is ignored. **Note:** If a network connection can't be made at boot time and configuring Wi-Fi is disabled then network escape hatch will be shown in order to refresh the device policy (see `networkEscapeHatchEnabled`). |
| appAutoUpdatePolicy | No | Recommended alternative: `autoUpdateMode` which is set per app, provides greater flexibility around update frequency. When `autoUpdateMode` is set to `AUTO_UPDATE_POSTPONED` or `AUTO_UPDATE_HIGH_PRIORITY`, this field has no effect. The app auto update policy, which controls when automatic app updates can be applied. |
| assistContentPolicy | No | Optional. Controls whether [AssistContent](https://developer.android.com/reference/android/app/assist/AssistContent) is allowed to be sent to a privileged app such as an assistant app. AssistContent includes screenshots and information about an app, such as package name. This is supported on Android 15 and above. |
| autoDateAndTimeZone | No | Whether auto date, time, and time zone are enabled on a company-owned device. If this is set, then [`autoTimeRequired`](/android/management/reference/rest/v1/enterprises.policies#autoTimeRequired) is ignored. |
| dataRoamingDisabled | No | Whether roaming data services are disabled. |
| installAppsDisabled | No | Whether user installation of apps is disabled. |
| setUserIconDisabled | No | Whether changing the user icon is disabled. This applies only on devices running Android 7 and above. |
| shortSupportMessage | No | A message displayed to the user in the settings screen wherever functionality has been disabled by the admin. If the message is longer than 200 characters it may be truncated. |
| adjustVolumeDisabled | No | Whether adjusting the master volume is disabled. Also mutes the device. The setting has effect only on fully managed devices. |
| crossProfilePolicies | No | Cross-profile policies applied on the device. |
| factoryResetDisabled | No | Whether factory resetting from settings is disabled. |
| networkResetDisabled | No | Whether resetting network settings is disabled. This applies only on fully managed devices. A `NonComplianceDetail` with `MANAGEMENT_MODE` is reported for other management modes. |
| outgoingBeamDisabled | No | Whether using NFC to beam data from apps is disabled. |
| passwordRequirements | No | Password requirements. The field `password_requirements.require_password_unlock` must not be set. DEPRECATED - Use `passwordPolicies`. **Note:** Complexity-based values of `PasswordQuality`, that is, `COMPLEXITY_LOW`, `COMPLEXITY_MEDIUM`, and `COMPLEXITY_HIGH`, cannot be used here. `unified_lock_settings` cannot be used here. |
| setWallpaperDisabled | No | Whether changing the wallpaper is disabled. |
| choosePrivateKeyRules | No | Rules for determining apps' access to private keys. See `ChoosePrivateKeyRule` for details. This must be empty if any application has `CERT_SELECTION` delegation scope. |
| createWindowsDisabled | No | Whether creating windows besides app windows is disabled. |
| outgoingCallsDisabled | No | Whether outgoing calls are disabled. |
| permittedInputMethods | No | If present, only the input methods provided by packages in this list are permitted. If this field is present, but the list is empty, then only system input methods are permitted. |
| personalUsagePolicies | No | Policies managing personal usage on a company-owned device. |
| screenCaptureDisabled | No | Whether screen capture is disabled. This also blocks [Circle to Search](https://support.google.com/android/answer/14508957). |
| shareLocationDisabled | No | Whether location sharing is disabled. |
| uninstallAppsDisabled | No | Whether user uninstallation of applications is disabled. This prevents apps from being uninstalled, even those removed using `applications` |
| usbMassStorageEnabled | No | Whether USB storage is enabled. Deprecated. |
| modifyAccountsDisabled | No | Whether adding or removing accounts is disabled. |
| policyEnforcementRules | No | Rules that define the behavior when a particular policy can not be applied on device |
| recommendedGlobalProxy | No | The network-independent global HTTP proxy. Typically proxies should be configured per-network in `open_network_configuration`. However for unusual configurations like general internal filtering a global HTTP proxy may be useful. If the proxy is not accessible, network access may break. The global proxy is only a recommendation and some apps may ignore it. |
| workAccountSetupConfig | No | Optional. Controls the work account setup configuration, such as details of whether a Google authenticated account is required. |
| bluetoothConfigDisabled | No | Whether configuring bluetooth is disabled. |
| defaultPermissionPolicy | No | The default permission policy for runtime permission requests. |
| ensureVerifyAppsEnabled | No | Whether app verification is force-enabled. |
| oncCertificateProviders | No | This feature is not generally available. |
| statusReportingSettings | No | Status reporting settings |
| tetheringConfigDisabled | No | Whether configuring tethering and portable hotspots is disabled. If `tetheringSettings` is set to anything other than `TETHERING_SETTINGS_UNSPECIFIED`, this setting is ignored. |
| usbFileTransferDisabled | No | Whether transferring files over USB is disabled. This is supported only on company-owned devices. |
| blockApplicationsEnabled | No | This field has no effect. |
| debuggingFeaturesAllowed | No | Whether the user is allowed to enable debugging features. |
| keyguardDisabledFeatures | No | Disabled keyguard customizations, such as widgets. |
| openNetworkConfiguration | No | Network configuration for the device. See [configure networks](/android/management/configure-networks) for more information. |
| skipFirstUseHintsEnabled | No | Flag to skip hints on the first use. Enterprise admin can enable the system recommendation for apps to skip their user tutorial and other introductory hints on first start-up. |
| unmuteMicrophoneDisabled | No | If `microphone_access` is set to any value other than `MICROPHONE_ACCESS_UNSPECIFIED`, this has no effect. Otherwise this field controls whether microphones are disabled: If true, all microphones are disabled, otherwise they are available. This is available only on fully managed devices. |
| advancedSecurityOverrides | No | Advanced security settings. In most cases, setting these is not needed. |
| androidDevicePolicyTracks | No | This setting is not supported. Any value is ignored. |
| credentialsConfigDisabled | No | Whether configuring user credentials is disabled. |
| deviceOwnerLockScreenInfo | No | The device owner information to be shown on the lock screen. |
| networkEscapeHatchEnabled | No | Whether the network escape hatch is enabled. If a network connection can't be made at boot time, the escape hatch prompts the user to temporarily connect to a network in order to refresh the device policy. After applying policy, the temporary network will be forgotten and the device will continue booting. This prevents being unable to connect to a network if there is no suitable network in the last policy and the device boots into an app in lock task mode, or the user is otherwise unable to reach device settings. **Note:** Setting `wifiConfigDisabled` to true will override this setting under specific circumstances. Please see `wifiConfigDisabled` for further details. Setting `configureWifi` to `DISALLOW_CONFIGURING_WIFI` will override this setting under specific circumstances. Please see `DISALLOW_CONFIGURING_WIFI` for further details. |
| defaultApplicationSettings | No | Optional. The default application setting for supported types. If the default application is successfully set for at least one app type on a profile, users are prevented from changing *any* default applications on that profile. Only one `DefaultApplicationSetting` is allowed for each `DefaultApplicationType`. See [Default application settings](https://developers.google.com/android/management/default-application-settings) guide for more details. |
| kioskCustomLauncherEnabled | No | Whether the kiosk custom launcher is enabled. This replaces the home screen with a launcher that locks down the device to the apps installed via the `applications` setting. Apps appear on a single page in alphabetical order. Use [kioskCustomization](/android/management/reference/rest/v1/enterprises.policies#kioskcustomization) to further configure the kiosk device behavior. |
| mountPhysicalMediaDisabled | No | Whether the user mounting physical external media is disabled. |
| preferentialNetworkService | No | Controls whether preferential network service is enabled on the work profile or on fully managed devices. For example, an organization may have an agreement with a carrier that all of the work data from its employees' devices will be sent via a network service dedicated for enterprise use. An example of a supported preferential network service is the enterprise slice on 5G networks. This policy has no effect if `preferentialNetworkServiceSettings` or `ApplicationPolicy.preferentialNetworkId` is set on devices running Android 13 or above. |
| privateKeySelectionEnabled | No | Allows showing UI on a device for a user to choose a private key alias if there are no matching rules in ChoosePrivateKeyRules. For devices below Android P, setting this may leave enterprise keys vulnerable. This value will have no effect if any application has `CERT_SELECTION` delegation scope. |
| wifiConfigsLockdownEnabled | No | This is deprecated. |
| cellBroadcastsConfigDisabled | No | Whether configuring cell broadcast is disabled. |
| deviceConnectivityManagement | No | Covers controls for device connectivity such as Wi-Fi, USB data access, keyboard/mouse connections, and more. |
| installUnknownSourcesAllowed | No | This field has no effect. |
| mobileNetworksConfigDisabled | No | Whether configuring mobile networks is disabled. |
| persistentPreferredActivities | No | Default intent handler activities. |
| permittedAccessibilityServices | No | Specifies permitted accessibility services. If the field is not set, any accessibility service can be used. If the field is set, only the accessibility services in this list and the system's built-in accessibility service can be used. In particular, if the field is set to empty, only the system's built-in accessibility servicess can be used. This can be set on fully managed devices and on work profiles. When applied to a work profile, this affects both the personal profile and the work profile. |
| bluetoothContactSharingDisabled | No | Whether bluetooth contact sharing is disabled. |
| credentialProviderPolicyDefault | No | Optional. Controls which apps are allowed to act as credential providers on Android 14 and above. These apps store credentials, see [this](https://developer.android.com/training/sign-in/passkeys) and [this](https://developer.android.com/reference/androidx/credentials/CredentialManager) for details. See also `credentialProviderPolicy`. |
| enterpriseDisplayNameVisibility | No | Optional. Controls whether the `enterpriseDisplayName` is visible on the device (e.g. lock screen message on company-owned devices). |
| accountTypesWithManagementDisabled | No | Account types that can't be managed by the user. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety profile (readOnly, idempotent). Description adds the resource name format constraint ('enterprises/{enterpriseId}/policies/{policyId}'), providing useful construction context, but lacks details on error handling (e.g., policy not found) or return value semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with clear information hierarchy: purpose first, format requirement second. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple read operation with complete input schema and existing output schema. The description confirms the required parameter status (saying 'Requires') despite the schema's empty required array, but could mention error cases or authentication needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline applies. Description essentially duplicates the schema's parameter description, adding no additional semantic nuance about the 'name' parameter beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Gets') and resource ('policy') with specific scoping ('for a given enterprise and policy ID'). Implicitly distinguishes from list_policies via singular vs. plural, but lacks explicit contrast with sibling retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this singular retrieval vs. list_policies, nor any prerequisites or error conditions mentioned. Only provides input format requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_web_appARead-onlyIdempotentInspect
Gets a web app. Requires the resource name in the format: enterprises/{enterpriseId}/webApps/{webAppId}.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of the web app in the form `enterprises/{enterpriseId}/webApps/{packageName}`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The name of the web app, which is generated by the server during creation in the form `enterprises/{enterpriseId}/webApps/{packageName}`. |
| icons | No | A list of icons for the web app. Must have at least one element. |
| title | No | The title of the web app as displayed to the user (e.g., amongst a list of other applications, or as a label for an icon). |
| startUrl | No | The start URL, i.e. the URL that should load when the user opens the application. |
| displayMode | No | The display mode of the web app. |
| versionCode | No | The current version of the app. Note that the version can automatically increase during the lifetime of the web app, while Google does internal housekeeping to keep the web app up-to-date. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only/idempotent safety properties, while the description adds crucial behavioral context: the exact resource name format required (enterprises/{enterpriseId}/webApps/{webAppId}), which is essential for successful invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states purpose immediately, second provides the critical format prerequisite. Perfectly sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and annotations covering safety hints, the description adequately covers the remaining essential context: the resource identifier format. Complete for a standard GET operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage establishing baseline of 3. Description adds value by reinforcing the parameter format pattern, though it uses 'webAppId' while schema uses 'packageName'—minor terminology variance but still helpful semantic clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Gets' with resource 'web app', clearly distinguishing from sibling 'list_web_apps' (singular retrieval vs. listing) and other get_* tools by resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context by specifying the required resource name format, indicating this is for retrieving specific known web apps. However, lacks explicit comparison to list_web_apps or get_application for when to use each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_devicesARead-onlyIdempotentInspect
Lists devices for a given enterprise. Requires the enterprise ID in the parent field (e.g., enterprises/{enterpriseId}).
| Name | Required | Description | Default |
|---|---|---|---|
| parent | No | The name of the enterprise in the form `enterprises/{enterpriseId}`. | |
| pageSize | No | The requested page size. If unspecified, at most 10 devices will be returned. The maximum value is 100; values above 100 will be coerced to 100. The limits can change over time. | |
| pageToken | No | A token identifying a page of results returned by the server. |
Output Schema
| Name | Required | Description |
|---|---|---|
| devices | No | The list of devices. |
| nextPageToken | No | If there are more results, a token to retrieve next page of results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive, idempotent behavior. Description adds the contextual constraint that an enterprise ID is required, but does not disclose additional behavioral traits like pagination defaults or rate limits beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence establishes purpose immediately; second sentence front-loads the critical prerequisite about the parent field format. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and comprehensive input schema coverage, the description provides sufficient context for a standard list operation. Adequately covers the enterprise scoping requirement, though could briefly acknowledge pagination support implied by the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage (baseline 3), the description adds value by emphasizing that the parent field is required, which contrasts with the schema's 'Required parameters: 0' signal. It reinforces the format example 'enterprises/{enterpriseId}' for the parent parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Lists' with resource 'devices' and scope 'for a given enterprise'. Clearly distinguishes from sibling 'get_device' (singular retrieval) and other list operations like 'list_enterprises' or 'list_policies' by specifying the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides critical prerequisite guidance that the enterprise ID is required in the parent field with correct format. However, does not explicitly state when to use this versus 'get_device' for single-device retrieval or mention pagination behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_enterprisesBRead-onlyIdempotentInspect
Lists enterprises accessible to the caller.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Specifies which Enterprise fields to return. This method only supports BASIC. | |
| pageSize | No | The requested page size. The actual page size may be fixed to a min or max value. | |
| pageToken | No | A token identifying a page of results returned by the server. | |
| projectId | Yes | Required. The Cloud project ID of the EMM managing the enterprises. |
Output Schema
| Name | Required | Description |
|---|---|---|
| enterprises | No | The list of enterprises. |
| nextPageToken | No | If there are more results, a token to retrieve next page of results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds minimal additional context beyond the schema, though 'accessible to the caller' implicitly signals authorization requirements. It does not elaborate on pagination behavior or filtering limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately front-loaded and efficient. However, extreme brevity prevents inclusion of sibling differentiation or usage caveats that would make it maximally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and complete parameter documentation, the description is minimally adequate. However, it lacks critical contextual guidance regarding the relationship to 'get_enterprise' and the nature of 'accessibility' filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the structured documentation already fully describes all four parameters including the enum values for 'view'. The description adds no parameter-specific guidance, meeting the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and resource ('enterprises') and indicates scope ('accessible to the caller'). However, it fails to distinguish from the sibling tool 'get_enterprise', which retrieves a specific enterprise versus listing multiple.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_enterprise', nor does it mention prerequisites such as the required 'projectId' parameter or when pagination is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_policiesARead-onlyIdempotentInspect
Lists policies for a given enterprise. Requires the enterprise resource name in the parent field (e.g., enterprises/{enterpriseId}).
| Name | Required | Description | Default |
|---|---|---|---|
| parent | No | The name of the enterprise in the form `enterprises/{enterpriseId}`. | |
| pageSize | No | The requested page size. The actual page size may be fixed to a min or max value. | |
| pageToken | No | A token identifying a page of results returned by the server. |
Output Schema
| Name | Required | Description |
|---|---|---|
| policies | No | The list of policies. |
| nextPageToken | No | If there are more results, a token to retrieve next page of results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety profile (readOnly, idempotent, non-destructive). Description adds practical prerequisite about parent field format requirement but does not disclose additional behavioral traits like pagination limits or cache behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence establishes purpose; second sentence provides critical usage requirement. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage, comprehensive annotations, and existing output schema, the description adequately covers the essential context (purpose and key prerequisite). Minor gap in explicit sibling differentiation prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all three parameters. Description adds example format 'enterprises/{enterpriseId}' which aligns with schema but does not add significant semantic value beyond structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Lists' with resource 'policies' and scope 'for a given enterprise'. Clearly distinguishes from sibling list_* tools (different resources) and implies distinction from get_policy via 'Lists' vs 'get', though explicit sibling contrast is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisite (requires enterprise resource name in parent field) and format example, which guides usage. However, lacks explicit 'when to use this vs get_policy' guidance or alternatives for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_web_appsBRead-onlyIdempotentInspect
Lists web apps for a given enterprise. Requires the enterprise resource name in the parent field (e.g., enterprises/{enterpriseId}).
| Name | Required | Description | Default |
|---|---|---|---|
| parent | No | The name of the enterprise in the form `enterprises/{enterpriseId}`. | |
| pageSize | No | The requested page size. This is a hint and the actual page size in the response may be different. | |
| pageToken | No | A token identifying a page of results returned by the server. |
Output Schema
| Name | Required | Description |
|---|---|---|
| webApps | No | The list of web apps. |
| nextPageToken | No | If there are more results, a token to retrieve next page of results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond annotations—it does not mention pagination behavior despite pageToken/pageSize parameters, nor does it explain error conditions or return value characteristics (though an output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The purpose is front-loaded in the first sentence. The second sentence about the parent field is somewhat redundant with the schema but provides useful emphasis. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations (covering safety) and an output schema (covering returns), the description provides adequate context for a standard list operation. However, it could be strengthened by mentioning pagination behavior or clarifying this returns a collection versus the singular 'get_web_app'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description repeats the parent field format requirement already documented in the schema ('enterprises/{enterpriseId}') without adding semantic depth about pageSize/pageToken usage or parameter interdependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Lists web apps for a given enterprise' with specific verb and resource. However, it does not explicitly distinguish this from sibling 'get_web_app' (single retrieval vs. listing multiple), which would be helpful for agent selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by specifying the required parent field format, but lacks explicit guidance on when to use this versus 'get_web_app' or other list operations. No 'when-not-to-use' or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!