Skip to main content
Glama
johsem

Semaphore UI MCP server

by johsem

create_integration_alias

Destructive

Creates a new alias for an existing integration in a Semaphore UI project via the management API, letting you reference that integration by an alternate name.

Instructions

Create a new alias for an integration. POST /project/{project_id}/integrations/{integration_id}/aliases.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYes
integration_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already flag this as destructive and non-idempotent, so the description should clarify what is being created or replaced, but it adds nothing. Critically, an alias creation presumably needs alias content, yet no payload or naming behavior is described, leaving the mutation opaque.

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?

Only two short sentences and front-loaded with the verb, which is good. The second sentence is a redundant REST path restatement that adds little beyond what the schema already lists.

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?

Short and technically accurate for a two-parameter call, but for a destructive create tool with no output schema it leaves too much unsaid: what the alias consists of, what it affects, and what must exist beforehand. Adequate at best.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry the burden, and it only restates project_id and integration_id as path segments via the URL template. It gives no meaning to what an alias is, no constraints, and the schema exposes no field for the alias value itself, which the description never addresses.

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: 'Create a new alias for an integration', with the target path spelled out. It does not, however, distinguish itself from the very similar siblings create_project_integration_alias and create_terraform_alias, so an agent cannot tell from the description alone which one applies.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the near-identical sibling create_project_integration_alias. The only orientation offered is a raw HTTP path, which does not help select the tool.

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

Deploy Server

Other Tools