mcp-1panel-plus

Overview Schema Source Related Servers Discussions Admin

Get Website Metadata

get_website

Read-only

Fetch website metadata by explicit website ID from a selected 1Panel node; filesystem paths and raw Nginx configuration are excluded.

Instructions

Get website metadata by explicit website ID on the selected node. Filesystem paths and raw Nginx configuration are excluded.

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": {
      "website_id": "<website_id>"
    },
    "name": "get_website"
  }
}

Input Schema

Name	Required	Description	Default
`nodeId`	No	Target node ID: "local" for the Main Node, or a numeric string ID (e.g. "3") from list_nodes.	local
`website_id`	Yes	Numeric website ID.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 11, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine content scope by excluding filesystem paths and raw Nginx configuration, but says nothing about behavior for an unknown ID, missing/offline node, or permission requirements.

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?

Two short sentences, lookup key and scope front-loaded before the exclusion clause. No redundant restatement of the title, though the exclusion sentence is terse enough to leave an agent guessing at what 'metadata' actually contains.

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?

For a two-parameter read-only lookup with no output schema, the definition covers the key facts: identifying key, node targeting and payload boundaries. The main residual gap is the absence of any positive description of what the returned metadata includes, only what is excluded.

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 (nodeId defaulting to 'local', website_id as a bounded integer) are fully documented in structured data. The description's contribution is limited to reinforcing that the ID must be explicit and numeric rather than a domain or path, which is a marginal addition.

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 website metadata') plus the lookup key ('by explicit website ID') and the node scope. The exclusion sentence narrows the payload, which helps separate it from config/filesystem-reading tools, though no sibling is named outright.

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 implied by 'explicit website ID' — an agent learns this is a single-record lookup rather than a listing — and the exclusions signal what this tool will not return. There is no explicit routing instruction (e.g., 'use list_websites to find the ID first') or statement of when not to use it.

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