Skip to main content
Glama
Sign In
umami-mcp

umami-mcp

by mikusnuz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

transfer_website

Transfer a website to a user or team via the Umami transfer endpoint. Provide website UUID, destination type, and destination ID to reassign ownership.

Instructions

Transfer a website to a user or team using the current Umami transfer endpoint

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "websiteId": "<websiteId>",
      "destinationType": "<destinationType>",
      "destinationId": "<destinationId>"
    },
    "name": "transfer_website"
  }
}

Input Schema

NameRequiredDescriptionDefault
websiteIdYesWebsite UUID to transfer
destinationIdYesTarget user or team UUID
destinationTypeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.1.1
    • addedInput schema / properties / destinationId
      Added value: +{
+  "description": "Target user or team UUID",
+  "format": "uuid",
+  "type": "string"
+}
    • addedInput schema / properties / destinationType
      Added value: +{
+  "enum": [
+    "user",
+    "team"
+  ],
+  "type": "string"
+}
    • removedInput schema / properties / userId
      Removed value: -{
-  "description": "Target user UUID to transfer ownership to",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "websiteId",
-  "userId"
-]New value: +[
+  "websiteId",
+  "destinationType",
+  "destinationId"
+]
  2. First observedv1.2.1

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden and falls short. It implies a mutation ('Transfer') but does not disclose permissions, reversibility, effects on existing shares or access, or error conditions; 'using the current Umami transfer endpoint' is implementation detail rather than useful behavior.

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?

The definition is a single front-loaded sentence with no sprawl. The phrase 'using the current Umami transfer endpoint' is slightly redundant but does not obscure the core purpose.

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

Completeness2/5

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

This is a mutation tool with no annotations and no output schema, so the description should explain permissions, side effects, and response expectations. It omits those details, leaving an agent with enough to identify the operation but not enough to invoke it confidently.

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 67%, with websiteId and destinationId documented in the schema. The description adds only limited semantic mapping by naming 'user or team' as the destination, but it does not explain the destinationId UUID requirement or add meaning beyond the enum already present for destinationType.

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 uses a specific verb and resource: 'Transfer a website' with an explicit destination scope of 'a user or team'. This clearly distinguishes it from siblings such as update_website, delete_website, or create_website_share.

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 description gives no explicit when-to-use or when-not-to-use guidance, no prerequisites such as required permissions, and no alternatives. At best, 'Transfer a website to a user or team' implies the ownership-change scenario, but an agent must infer all operational context.

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