action1-mcp-server

Get enterprise settings

action1_get_enterprise

Read-onlyIdempotent

Retrieves enterprise settings for your organization, letting you inspect configuration data in markdown or JSON.

Instructions

Get enterprise settings. Gets settings for an enterprise. You can query data for your enterprise only.

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
`name`	No
`self`	No
`type`	No
`verified`	No
`description`	No
`allowed_fast_closure`	No
`closure_requested_at`	No
`closure_requested_by`	No
`closure_scheduled_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 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 / allowed_fast_closure
```
Added value: +{}
```
- addedOutput schema / properties / closure_requested_at
```
Added value: +{}
```
- addedOutput schema / properties / closure_requested_by
```
Added value: +{}
```
- addedOutput schema / properties / closure_scheduled_at
```
Added value: +{}
```
- addedOutput schema / properties / description
```
Added value: +{}
```
- addedOutput schema / properties / id
```
Added value: +{}
```
- addedOutput schema / properties / name
```
Added value: +{}
```
- addedOutput schema / properties / self
```
Added value: +{}
```
- addedOutput schema / properties / type
```
Added value: +{}
```
- addedOutput schema / properties / verified
```
Added value: +{}
```
First observedv0.5.0Jun 27, 2026

TDQS

B3.1/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety behavior is covered. The description adds a useful authorization scope constraint ('your enterprise only'), but does not explain the effect of the verbose parameter or the return content. With annotations carrying most of the behavioral burden, the added scope note is enough for a 3.

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

Conciseness3/5

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

The description is short and front-loaded with the main action. However, the second sentence ('Gets settings for an enterprise') largely restates the first, so one sentence does not fully earn its place.

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?

The tool has a full output schema and rich annotations, so the description need not explain return values or safety behavior. Still, it could better situate the tool against siblings like action1_update_enterprise or clarify what 'enterprise settings' includes. The scope constraint is helpful but minimal.

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 description coverage is 100%, so both parameters ('verbose' and 'response_format') are fully documented in the schema. The description adds no parameter-level detail beyond the schema, which is acceptable at baseline 3 when the schema does the heavy lifting.

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?

The description states a specific verb and resource: 'Get enterprise settings' and 'Gets settings for an enterprise.' It is clear what the tool does, but it does not distinguish itself from closely related siblings such as action1_update_enterprise or action1_get_setting.

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

Usage Guidelines2/5

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

The only guidance is the scope constraint 'You can query data for your enterprise only.' The description does not say when to use this tool instead of alternatives like action1_update_enterprise or action1_get_setting, nor does it state any prerequisites beyond the enterprise scope.

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

Deploy Server