action1-mcp-server

Check for Software Repository package matching conflicts before creating a new…

action1_get_match_conflicts_for_software_repository

Read-onlyIdempotent

Check for Software Repository package matching conflicts before creating a new package version to avoid duplicate or conflicting entries.

Instructions

Check for Software Repository package matching conflicts before creating a new package version. Perm: view_software_repository.

Input Schema

Name	Required	Description
`org_id`	No	Org UUID.
`verbose`	No	Skip per-item compactor.
`app_name_match`	No	Provide the REGEX expression to match the software name.
`response_format`	No	Output format. Default markdown.

Output Schema

Name	Required	Description	Default
`id`	No
`name`	No
`self`	No
`type`	No
`status`	No
`vendor`	No
`builtin`	No
`versions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 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 / builtin
```
Added value: +{}
```
- addedOutput schema / properties / id
```
Added value: +{}
```
- addedOutput schema / properties / name
```
Added value: +{}
```
- addedOutput schema / properties / self
```
Added value: +{}
```
- addedOutput schema / properties / status
```
Added value: +{}
```
- addedOutput schema / properties / type
```
Added value: +{}
```
- addedOutput schema / properties / vendor
```
Added value: +{}
```
- addedOutput schema / properties / versions
```
Added value: +{}
```
First observedv0.5.0Jun 27, 2026

TDQS

A4.5/5.0

Behavior4/5

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

While annotations cover the safety profile (readOnlyHint: true), the description adds crucial operational detail by specifying the required permission ('Perm: view_software_repository'). This context is vital for an agent deciding if it has the authority to call the tool.

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

Conciseness5/5

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

The definition is extremely tight and efficient. It fits all necessary information—action, resource, condition, and permission—into a single, highly structured sentence without any filler.

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

Completeness5/5

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

Given that annotations define it as a non-destructive, read-only operation, and the schema is comprehensive, the description successfully adds the final necessary pieces of context: the specific use case and the required permissions.

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?

Since schema description coverage is 100%, the input schema fully defines the parameters. The description is highly focused on the 'why' (usage/purpose) rather than the 'how' (parameter meaning), making the baseline score of 3 appropriate.

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

Purpose5/5

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

The description clearly states the purpose: 'Check for Software Repository package matching conflicts.' It identifies the specific resource (Software Repository package) and the action being performed.

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

Usage Guidelines5/5

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

It provides explicit usage context by stating this check is required 'before creating a new package version,' effectively defining when to invoke the tool relative to other package management lifecycle stages.

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

Deploy Server