action1-mcp-server

Get version in Software Repository package

action1_get_version

Read-onlyIdempotent

Retrieve detailed information about a specific software package version by its ID to inspect version metadata and contents.

Instructions

Get version in Software Repository package. Gets details about a package version specified by its ID. Perm: view_software_repository.

Input Schema

Name	Required	Description
`org_id`	No	Org UUID.
`verbose`	No	Skip per-item compactor.
`package_id`	Yes	Provide a specific package ID.
`version_id`	Yes	Provide a specific version ID.
`response_format`	No	Output format. Default markdown.

Output Schema

Name	Required	Description	Default
`OS`	No
`id`	No
`self`	No
`type`	No
`notes`	No
`version`	No
`EULA_text`	No
`binary_id`	No
`file_name`	No
`update_type`	No
`install_type`	No
`release_date`	No
`security_CVE`	No
`EULA_accepted`	No
`app_name_match`	No
`approval_status`	No
`scoped_approvals`	No
`reboot_exit_codes`	No
`security_severity`	No
`additional_actions`	No
`success_exit_codes`	No
`allow_x86_x64_on_arm`	No
`silent_install_switches`	No
`uninstall_app_name_match`	No
`silent_uninstall_switches`	No
`minimum_required_agent_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed29 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 / EULA_accepted
```
Added value: +{}
```
- addedOutput schema / properties / EULA_text
```
Added value: +{}
```
- addedOutput schema / properties / OS
```
Added value: +{}
```
- addedOutput schema / properties / additional_actions
```
Added value: +{}
```
- addedOutput schema / properties / allow_x86_x64_on_arm
```
Added value: +{}
```
- addedOutput schema / properties / app_name_match
```
Added value: +{}
```
- addedOutput schema / properties / approval_status
```
Added value: +{}
```
- addedOutput schema / properties / binary_id
```
Added value: +{}
```
- addedOutput schema / properties / file_name
```
Added value: +{}
```
- addedOutput schema / properties / id
```
Added value: +{}
```
- addedOutput schema / properties / install_type
```
Added value: +{}
```
- addedOutput schema / properties / minimum_required_agent_version
```
Added value: +{}
```
- addedOutput schema / properties / notes
```
Added value: +{}
```
- addedOutput schema / properties / reboot_exit_codes
```
Added value: +{}
```
- addedOutput schema / properties / release_date
```
Added value: +{}
```
- addedOutput schema / properties / scoped_approvals
```
Added value: +{}
```
- addedOutput schema / properties / security_CVE
```
Added value: +{}
```
- addedOutput schema / properties / security_severity
```
Added value: +{}
```
- addedOutput schema / properties / self
```
Added value: +{}
```
- addedOutput schema / properties / silent_install_switches
```
Added value: +{}
```
- addedOutput schema / properties / silent_uninstall_switches
```
Added value: +{}
```
- addedOutput schema / properties / success_exit_codes
```
Added value: +{}
```
- addedOutput schema / properties / type
```
Added value: +{}
```
- addedOutput schema / properties / uninstall_app_name_match
```
Added value: +{}
```
- addedOutput schema / properties / update_type
```
Added value: +{}
```
- addedOutput schema / properties / version
```
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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered elsewhere. The description adds one genuinely useful piece of context beyond the annotations, the required permission 'view_software_repository', but says nothing about what is returned or how completeness varies with the verbose flag.

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?

Short and front-loaded, but the second sentence ('Gets details about a package version specified by its ID') largely restates the first. The permission note earns its place; the middle sentence mostly does not.

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

Completeness4/5

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

An output schema exists, so return values need not be described, and the schema fully covers the five parameters. What remains missing is routing guidance against the many nearby package/version tools, which is a modest gap for a simple read-by-ID call.

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 every parameter including org_id, verbose and response_format is already documented. The description only restates that lookup is by ID and adds no new meaning for the optional flags, 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?

States a specific verb and resource ('Get version in Software Repository package') plus the identity of the resource ('a package version specified by its ID'). An agent can distinguish this from the sibling list_software_repository / get_software_repository_package calls, though the package-vs-version boundary is only loosely implied.

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: the reader infers it should be called when a specific package_id and version_id are already known. No explicit when-not guidance and no pointer to alternatives such as action1_list_version_endpoints or action1_get_software_repository_package.

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

Deploy Server