action1-mcp-server

Get usage statistics for an enterprise

action1_get_subscription_usage

Read-onlyIdempotent

Retrieve enterprise subscription usage statistics to monitor license consumption and verify deployed licenses across the organization.

Instructions

Get usage statistics for an enterprise. Gets details about license usage for the entire enterprise. Perm: manage_enterprise.

Input Schema

Name	Required	Description	Default
`verbose`	No	Skip per-item compactor.
`response_format`	No	Output format. Default markdown.

Output Schema

Name	Required	Description	Default
`id`	No
`self`	No
`type`	No
`organization`	No
`current_active_endpoint_count`	No
`monthly_average_endpoint_count`	No
`current_inactive_endpoint_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.6.0Oct 26, 2026
- changedInput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- changedOutput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- changedOutput schema / additionalProperties
```
Previous value: -trueNew value: +{}
```
- addedOutput schema / properties / current_active_endpoint_count
```
Added value: +{}
```
- addedOutput schema / properties / current_inactive_endpoint_count
```
Added value: +{}
```
- addedOutput schema / properties / id
```
Added value: +{}
```
- addedOutput schema / properties / monthly_average_endpoint_count
```
Added value: +{}
```
- addedOutput schema / properties / organization
```
Added value: +{}
```
- addedOutput schema / properties / self
```
Added value: +{}
```
- addedOutput schema / properties / type
```
Added value: +{}
```
First observedv0.5.0Jun 27, 2026

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered structurally. The description adds the manage_enterprise permission requirement, which is genuinely new information, but says nothing about aggregation granularity, time ranges, or cost of the call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the resource front-loaded and the permission appended. The second sentence largely restates the first ('details about license usage' vs 'usage statistics'), which is the only waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema, annotation coverage, and a fully described input schema, the definition is close to sufficient. What it lacks is the relation to the other subscription-usage tools in a very crowded sibling set, which is the one thing structured fields cannot convey.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with only two optional parameters (verbose, response_format, the latter enum-constrained), so the schema carries parameter documentation. The description adds nothing about them — notably it does not clarify the cryptic 'skip per-item compactor' effect of verbose — so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb plus resource ('get usage statistics for an enterprise', 'license usage for the entire enterprise') makes the scope clear. It implicitly distinguishes itself from per-org listings by saying 'the entire enterprise', but the near-identical siblings action1_get_subscription and action1_get_org_subscription_usage are never named or ruled out.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the word 'enterprise' and the 'Perm: manage_enterprise' note, which tells the agent who can call it. There is no explicit statement of when to prefer this over action1_get_org_subscription_usage or action1_list_subscription_usage_organizations, and no when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server