fastpanel-mcp
Server Quality Checklist
Latest release: v1.2.0
- Disambiguation5/5
Each tool has a clear, distinct purpose with detailed descriptions that prevent confusion. Even similar tools like site_files_upload, site_files_deploy, and site_file_put are well-differentiated by their source and mechanism.
Naming Consistency4/5Most tools follow a resource_action or action_resource pattern, but there is inconsistency in singular vs plural (site_get vs sites_list) and a few outliers like 'me'. Overall, names are readable and predictable.
Tool Count4/5With 32 tools, the surface is broad but each tool addresses a distinct operation within FastPanel's domain. While on the higher end, none seem redundant, and the count matches the complexity of managing a hosting panel.
Completeness3/5The set covers creation, reading, and updating for major resources (sites, databases, users) but notably lacks delete operations for these resources, which is a significant gap for full lifecycle management.
Average 4.5/5 across 32 of 32 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. Description adds context about task types included but no critical behavioral details beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with the action and resource, followed by clarifying examples. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, strong annotations, and no output schema, the description is sufficient. It clearly states what is listed and includes completion. Could specify ordering or pagination but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'limit' described adequately. Description does not mention parameters, but baseline is 3 as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'FastPanel background tasks' with specific examples (backups, migrations, SSL issuance, screenshots). It differentiates from the sibling 'queue_active' by including completed tasks, making its scope distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies broader scope than 'queue_active' (includes completed tasks) but does not explicitly state when to use this tool versus alternatives or when not to use it. Lacks direct guidance on choosing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and side effects. The description adds value by specifying the HTTP method (GET) and handling of empty responses, but does not reveal other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loaded with purpose followed by API mapping and behavior note. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool without output schema, the description covers purpose, endpoint, and empty state handling. This is fully adequate given the tool's simplicity and the richness of sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with zero parameters. The description does not need to add parameter info; baseline 3 applies per rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'backup plans', with specific context of the FastPanel v2 backup system and API endpoint mapping. It is distinct from all sibling tools, which include no other backup-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but does not explicitly provide when-to-use/when-not-to-use guidance or compare with alternatives. The note about empty data array offers a hint but is not a full guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds context by mapping to GET endpoint and listing example settings, which reinforces safety without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and resource, followed by concrete examples and API mapping. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could specify the return format (e.g., object containing all settings). However, the examples and endpoint mapping provide sufficient context for a simple read operation with no parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters and 100% coverage; the description does not need to add parameter info. Baseline for no parameters is 4, and the description appropriately avoids extraneous details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and resource 'panel-wide settings', lists specific examples (OS release, license type, etc.), and disambiguates from sibling tools like site_get or system_load by focusing on global settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., site_get for per-site settings). The description lacks any conditions or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that it returns specific fields and covers both MySQL and PostgreSQL, but does not reveal additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficient sentence that front-loads the action and scope, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with thorough annotations, the description adequately covers return fields and scope, making it fully actionable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the schema covers 100%. Baseline for 0 parameters is 4; the description is not required to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all MySQL and PostgreSQL databases' with a specific verb and resource, and lists returned fields. It distinguishes from sibling list tools like sites_list or users_list, and from database-specific tools like database_dump.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool. Usage is implied by the simple act of listing databases, but absence of exclusion criteria or alternative suggestions limits clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-readOnly. Description adds confirm requirement and API mapping, but doesn't detail side effects of detaching or toggling flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with purpose, usage scenario, and critical instruction. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential use case and detach mechanism, but lacks explanation of boolean flags, return value, or behavior of dry_run. With 9 parameters and no output schema, more detail would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 78% (high), so baseline is 3. Description adds minor clarification for certificate_id null but doesn't explain boolean flags beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the actions (attach, replace, detach) and resource (SSL certificate on a site), distinguishing it from sibling tools like site_update and certificate_create_letsencrypt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context for wildcard flow and detachment (certificate_id=null), plus confirm requirement. However, lacks explicit contrast with alternative SSL tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly and non-destructive, and the description confirms it as a WRITE operation. It also clarifies the preview/execute workflow. However, it doesn't describe the return value or potential side effects, which is notable since no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second adds crucial workflow info. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core action and preview/execute workflow. Missing details like linking to a site (site_id) or DB engine distinction, but these are in schema. OpenWorldHint implies possible side effects not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (78%), so the description adds little beyond the schema. It mentions 'with a dedicated DB user' but doesn't elaborate on parameters or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (create), the resource (database), and the types (MySQL or PostgreSQL). It also mentions the creation of a dedicated DB user, which is specific and distinguishes it from listing or dumping tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use dry_run=true for preview and confirm=true to execute, which is a safety guideline. However, it does not contrast with other tools or specify prerequisites like server_id lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing safety. The description adds the behavioral trait that the result is empty if DNS is not configured, which is useful and non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the main purpose and a key edge case, with no redundant information. It is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, the description covers the purpose, scope, and an edge case (empty if DNS not configured). While no output schema exists, the return format is implied by the tool's nature; the description is sufficient for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100% (vacuously), so no param info is needed. The description adds no parameter meaning, but with zero params, the baseline is 4 as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List all DNS zones' and identifies the specific resource 'FastPanel's DNS service', distinguishing it from sibling tools like dns_records_list which list records within a zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing DNS zones but does not explicitly state when to use or avoid this tool versus alternatives. The note about being empty if DNS is not configured provides some context, but no alternative tools or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by stating 'Read-only' and revealing the SSH dependency (FASTPANEL_SSH_HOST). It also mentions the output is a structured report, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the purpose, lists specific checks, then states read-only and SSH requirement. Every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's function and what it checks. However, since there is no output schema, the description could be more explicit about the structure of the report. Nevertheless, it covers the essential behavioral context for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter site_id is described in the schema as 'Site id from sites_list'. The description adds no further detail on parameter semantics, but since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Diagnose the common reasons a FastPanel site serves errors'. It lists specific checks (docroot, permissions, PHP-FPM socket, etc.), making it distinct from sibling tools like site_logs or nginx_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a site serves errors and enumerates the checks performed. It does not explicitly state when not to use or mention alternatives, but the context is clear enough for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the return fields (40 fields including SSL, backend config, permissions, etc.), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose and key details. No unnecessary words. Efficiently conveys essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description covers the return scope (all 40 fields) and gives examples (SSL, backend config, permissions). For a read-only tool with solid annotations, this is mostly complete. Could mention pagination or error cases, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'site_id' with full schema documentation (100% coverage). The description does not add additional syntax or meaning beyond referencing the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Get full details') and resource ('single site by id'). Specifies the output scope ('all 40 fields including...'). Distinguishes from sibling tools like 'sites_list' (which lists sites) and 'site_update' (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when detailed info on one site is needed, vs. 'sites_list' for a list. Lacks explicit when-not-to-use or alternative names, but context signals and sibling list make it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds limited behavioral info beyond listing server types. Description is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. Front-loaded with action and resource, followed by usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter list tool with no output schema, description fully explains purpose, return value usage, and server types. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so description cannot add beyond schema. Baseline 4 is appropriate as there is no need for parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (List), resource (database servers), and specific types (MySQL, PostgreSQL). Differentiates from siblings by explaining how returned ids feed into database_create and site_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use returned ids in create tools, guiding when to call. Does not include when-not-to-use, but context is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds that it maps to a GET endpoint and lists the types of resources returned, providing useful behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core purpose, and no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers purpose, usage guidance, and expected resource types, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes site_id as 'Site id from sites_list'. The description does not add additional parameter semantics, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List the resources attached to a site' and enumerates specific resource types (linked databases, sub-domains, DNS zones, email domains), differentiating it from sibling tools like sites_list or site_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises use 'before deleting or migrating a site, or to find which database(s) belong to it', providing clear context and use cases, though it does not explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds the data source endpoint, which provides useful context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences: first states purpose, second adds source. Every word earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, rich annotations, and a clear list of returned metrics, the description fully covers the tool's purpose and behavior. No missing context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description does not need to add parameter meaning, but it lists the returned metrics (CPU, memory, disk, uptime), adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves current server load metrics (CPU, memory, disk, uptime). The verb 'Get' and specific resource list distinguish it from other tools like sites_list or dns_domains_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, the description does not mention when-not-to-use or provide comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds context about return fields and that it lists system users, which is beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with immediate purpose and list of return fields. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, description is complete: it states scope (all system users), mentions they are site owners, and lists all return fields. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Description adds no param info but none is needed. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all FastPanel system users (site owners) and enumerates returned fields (id, username, home_dir, etc.), distinguishing it from sibling tools like dns_domains_list or sites_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The purpose is implied by the tool name and description, but lacks comparison to siblings like user_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by detailing filtering to in-flight tasks, meta.all_done flag, and effect of include_finished. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences, front-loaded with the core purpose. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return behavior (filtered tasks, meta.all_done). With openWorldHint and readOnlyHint, it's sufficient for a polling tool. Could potentially hint at polling intervals, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a boolean parameter already described. Description adds meaning: include_finished allows seeing just-completed tasks to know if async op succeeded/failed, which is useful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it polls FastPanel background tasks for a deterministic done/not-done signal, contrasts with naive polling, and specifies filtering behavior. It differentiates itself from siblings like queue_list by focusing on in-flight tasks and providing meta.all_done.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (polling for done/not-done) and when not (naive raw endpoint), and describes include_finished option for checking final status. No explicit alternative sibling named, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses write nature and the preview/execute pattern via dry_run and confirm. Consistent with annotations (readOnlyHint false, destructiveHint false). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Purpose is front-loaded, behavior and usage are concisely stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a create tool with no output schema. Covers key behavioral aspects. Could mention uniqueness constraints but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage; description adds clarifying usage for dry_run and confirm parameters, helping the agent understand the safety pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new FastPanel system user', using a specific verb and resource. It distinguishes from sibling tools like users_list, and no other tool creates users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it's a WRITE operation with dry_run for preview and confirm for execution. However, it does not explicitly state when to use vs alternatives, though no direct alternative exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal behavioral context beyond stating it lists 'all' records. It does not disclose any additional traits like auth needs or pagination, but it is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste. First sentence defines purpose, second provides prerequisite. Highly efficient for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema), the description is complete. It covers what the tool does, what input is needed, and how to obtain that input. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with domain_id fully described. The description reinforces that the id comes from dns_domains_list, adding valuable context beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'DNS records', and the scope 'for a specific domain (zone) by its id'. It also distinguishes itself from sibling dns_domains_list by directing users to use that tool first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite: 'Use dns_domains_list first to get ids.' This provides clear when-to-use guidance and establishes a workflow, making it easy for the agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns literal config text as stored, which is useful. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, followed by usage and endpoint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description fully explains what is returned and the use case. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage and describes site_id as 'Site id from sites_list'. Description does not add further semantics beyond the endpoint context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Read' and the resource 'raw nginx, apache, and php.ini configs'. Distinguishes from sibling tools like site_get and site_configuration_update by specifying it returns the literal config text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using before site_configuration_update to see current state, and explains why (FastPanel defaults often miss hardening). Also provides the exact endpoint, aiding correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false), destructive potential (destructiveHint=true), and idempotentHint=true. The description goes beyond by explaining the read-modify-write pattern, the unverified endpoint risk, the need for confirm:true, and the framework auto-append behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with main purpose first, then details, and warnings. Every sentence adds necessary information (purpose, differentiation, behavioral notes, parameter guidance). Could be slightly tighter, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and annotations with openWorldHint and destructiveHint. The description covers core behavior, risks, and parameter interplay. It does not describe the response on success, but for a write tool with confirm/dry_run, the guidance to check site_get afterwards compensates. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 67% of parameters. The description adds meaning: explains framework as a preset that appends '/public', clarifies that index_dir and framework are mutually exclusive, and stresses that confirm is required for writes. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it changes a site's document root (index_dir) and/or directory index. It distinguishes from sibling tool site_backend_update by explaining why that tool cannot achieve this. The verb 'Change' and resource 'site's document root' are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases such as frameworks serving from subfolders (Laravel/Symfony) and notes that this is the ONLY way to repoint docroot. It recommends dry_run for safety and warns about the unverified endpoint, but does not explicitly list when NOT to use it (e.g., alternative tools for other modifications).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (write operation, not idempotent), description adds async nature, immediate return with 'CREATING' status, polling queue_active, and prerequisite that site must be accessible. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences with clear sections (description, async note, requirements, write confirm). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: async workflow, polling, DNS requirement, confirmation flag. Missing potential error scenarios or rate limits, but sufficient for a complex tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 75% of parameters well. Description adds critical contextual hint that confirm must be true to execute, which is not obvious from schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it issues a Let's Encrypt SSL certificate for an existing site, distinguishing from listing certificates or updating SSL. Specifies async behavior upfront.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells when to use (issuing certs) and mentions requirement of publicly accessible DNS, but does not explicitly contrast with alternatives like site_ssl_update or DNS-01 validation options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses far beyond annotations: safety net with validation and auto-revert, side effect of manual mode, partial update behavior. Annotations (destructiveHint=true, idempotentHint=true) are consistent and the description adds crucial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action, uses structured warnings and bullet-like formatting. It is slightly long but every sentence is informative; could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk write operation, the description covers safety net, side effects, partial updates, endpoint, and references to related tools. No output schema, but the behavioral info is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71% high, but description adds value: explains that omitting a param keeps current, the validate param behavior, and the SSH prerequisite. This goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces nginx, apache, and php.ini config for a site. It distinguishes from siblings like site_configuration_get (read) and site_backend_update (partial) by explaining partial update support and the full scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Guidelines are strong: it explains when to use (replace config), warns about danger, and contrasts with raw API. However, it does not explicitly say when NOT to use, e.g., if only backend update is needed, there is site_backend_update sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and write behavior. The description adds specifics: 'Existing files are overwritten; nothing is deleted' and runs as root, which clarifies the exact destructive scope. Only minor additional context like rate limits missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and well-structured: overview, source type details, overwrite behavior, dry_run/confirm. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description covers all necessary context: prerequisites (SSH), safe usage (dry_run), exact effects for each source type, overwrite policy, and destination semantics. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains parameter usage beyond schema: source_type behaviors (shallow-clone, automatic top-level dir descent), dest_subpath relativity, and ref usage. Considering 71% schema coverage, the description compensates fully, adding essential meaning for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deploys site files by fetching them on the server (git clone or tarball) into the web root, then chowning. It distinguishes itself from siblings like site_files_upload (local upload) by specifying the server-side fetch mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use (WRITE operations, with dry_run for preview) and prerequisites (SSH host). It implies alternatives (upload for local files) but does not explicitly list when not to use. The guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, not destructive. Description adds critical behavioral details: FastPanel quirk (returns 'errors' field and 400 on success), normalization to 'log' field, empty log as '\n', missing file message. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is slightly long but every sentence adds necessary context. Purpose is front-loaded. Could be a bit more concise, but well-structured overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers behavior, edge cases (empty log, missing file), normalization, and result format ('log' field). No output schema but sufficient explanation. Annotations provide safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions. Description enriches 'type' with real-world meaning (nginx vs Apache, error vs access) and explains log file paths. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it tails a site's nginx/apache access or error log without SSH. Specifies the endpoint and normalizes quirks. Distinguishes from sibling tools (none are log-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use each type (frontend_error for 404/permission problems, backend_error for PHP-FPM errors). Does not explicitly mention when not to use this tool or alternatives, but usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description discloses that computed paths are derived from naming convention, not API, and advises on-disk verification for imported certs. This adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5-6 sentences), front-loads the purpose, and packs essential information without fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully covers return fields and edge cases (imported cert verification). It is complete for a list-all tool with no parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters; the input schema is empty. The description does not need to add parameter info. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all SSL certificates, specifies types (Let's Encrypt and custom), and enumerates returned fields including computed paths. It distinguishes itself from create/update tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific context for when the computed paths are needed (hand-writing 443 server block in manual_changes mode) and includes a verification note. However, it does not explicitly contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint:true. Description adds valuable context: 'DESTRUCTIVE: the SQL runs as-is, so a dump containing DROP/CREATE will replace existing tables and data.' Also notes SSH requirement. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. First sentence states main action. Second sentence packs warnings, prerequisites, and usage guidance. Front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: what it does, destructive behavior, preconditions (staging dir, SSH), dry_run/confirm workflow, and output expectation (command preview or execution). No output schema but sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 50% of parameters with descriptions. Description adds meaning for dry_run and confirm ('dry_run:true to preview the command, confirm:true to execute'), and explains source_path constraint (must be in staging dir).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Load' and resource '.sql dump file INTO a database via SSH (mysql)'. It distinguishes from sibling tools like 'database_dump' which produces dump files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (importing SQL dumps), precondition (file in staging dir), and alternative (use database_dump to produce the file). Also warns about destructive nature and required SSH configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, strongly indicating safe read behavior. The description adds value by noting that the tool always reflects the read token, not the write token, which is a behavioral nuance beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a note, all front-loaded with the main purpose. Every sentence adds value: purpose, endpoint mapping, usage recommendation, and a critical caveat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and annotations cover safety signals, the description is fully complete: it explains what the tool does, when to use it, and a relevant limitation. It covers the necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description does not need to explain parameters but adds value by listing output fields (username, roles, home dir, ssh access). Baseline for 0 parameters is 4, and the description meets this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies the FastPanel account behind the current READ token, listing specific fields (username, roles, home dir, ssh access). It distinguishes from sibling tools which operate on other resources (sites, dns, etc.), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use to confirm which user/token the server is authenticated as.' It also includes a note about what it does not tell (whether a write token is configured), providing clear guidance on limitations and appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds context: the tool resolves the backend id internally and uses PUT /api/sites/backend/{backend_id}, and omitted fields keep current values by fetching via site_get. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads purpose and includes all necessary information. It is dense but clear; slight improvement could be breaking into bullet points for readability, but it remains concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 12 parameters and no output schema, the description explains internal resolution, merge semantics, confirm requirement, and docroot separation. It does not describe the return value, but given no output schema, this is a minor gap. Overall quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%. The description adds key context beyond schema: all settings except site_id are optional, omitted fields keep current values, and passing site_id avoids 404. However, not every parameter is individually elaborated beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update backend settings of an existing site' and lists the specific settings (PHP version, handler, app file, port, socket path, env vars). It distinguishes from sibling tool site_update by explicitly noting that this tool does not change the document root, which site_update does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs the agent to pass the SITE id from sites_list, warns against using backend_id directly (404 error), explains that omitted fields keep current values, and directs to site_update for docroot changes. It also flags that confirm:true is required for write operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds rich behavioral detail beyond annotations: chown/perm normalization, bytes not passing through model, trailing-slash semantics, delete destructive behavior, and write flow with dry_run/confirm. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-structured: first sentence states purpose, then details key behaviors. Every sentence is informative, though slightly long. Front-loaded with essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema), the description covers SSH prerequisites, permission normalization, rsync semantics, and write flow. No gaps in explaining behavior and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, but the description adds crucial semantics: trailing-slash for local_path, relative destination for dest_subpath, and the role of dry_run/confirm. Compensates well for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states upload of local file/directory to site web root via SSH, with explicit verb and resource. Distinguishes itself from siblings like site_file_put (single file) and site_files_deploy by specifying the mechanism and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: for bulk upload via SSH, with prerequisites (SSH configured), dry-run/confirm flow, and trailing-slash semantics. Implicitly differentiates from alternatives but lacks explicit when-to-use vs siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes write operation (creates root-owned file), file return details (path, size), and rejection of remote servers/non-MySQL. Adds context beyond annotations (SSH requirement, staging dir restriction) without contradicting readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
All sentences are informative and necessary. Front-loaded with purpose, followed by constraints and usage steps. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, output format, behavioral flags, and limitations. Without output schema, description adequately explains return values (path and byte size).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 2 of 4 params with descriptions; description adds usage context for dry_run/confirm (preview/execute) and clarifies output_path scope (staging dir only). Fully compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Dump a database to a .sql file' using specific verb and resource. Distinguishes from sibling tools like databases_list and database_import by specifying dump/export via SSH and mysqldump.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions prerequisites (SSH configured, staging dir), how to preview vs execute (dry_run, confirm), and constraints (local MySQL only, file path restrictions). Lacks direct comparison to alternatives but boundaries are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint false. Description adds that it is read-only, does NOT reload or modify anything, and requires SSH configured. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Action verb and key usage guidance are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is fully adequate: explains purpose, usage timing, behavioral traits, and preconditions. Sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema (schema coverage 100%). Description does not need to explain parameters; baseline 4 for zero-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs 'nginx -t' to validate live nginx config, with a specific verb ('run') and resource ('nginx config'). Distinguishes from sibling tools by mentioning use before/after site_configuration_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use it before and after site_configuration_update' and warns that syntax errors would take nginx down. Provides context for when to invoke, and clarifies read-only nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: explains compact default, response size (~3KB per site), and potential context overflow. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second provides critical usage detail. Every sentence is informative and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters and comprehensive annotations, the description covers usage context, defaults, size concerns, and alternative tool. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining the practical implications of compact mode and the size impact, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists websites managed by FastPanel, specifies compact mode defaults, and distinguishes from site_get for full details. Action and resource are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use compact vs full mode, warns about context overflow, and suggests site_get for specific site details. Context of use is well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description goes beyond annotations by detailing the two-step API flow (probe then create), marking new_owner as experimental and untested, and explicitly calling out the WRITE nature with dry_run recommendation. No contradiction with annotations (readOnlyHint=false supports write).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-organized paragraphs: first introduces purpose and key constraints (SSL, atomic creation), second explains the flow and parameter relationships. Every sentence adds essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, nested objects, no output schema, and moderate complexity, the description comprehensively covers purpose, usage flow, parameter relationships, behavioral notes, and cross-references to sibling tools. It leaves no major gaps for an agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite high schema coverage (82%), the description adds significant value: for ips, it tells where to get values; for handler, explains differences and recommends checking existing sites; for owner fields, clarifies mutual exclusivity; for database, notes optionality; for domain, gives examples. This enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'new website in FastPanel', and specifies the endpoint '/api/master wizard'. It distinguishes from siblings like site_update and certificate_create_letsencrypt by noting that SSL is not issued and must be done separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use and when-not: 'Does NOT issue SSL — call certificate_create_letsencrypt after site is active.' It also gives a clear two-step flow with dry_run then confirm, and advises using site_get to determine preferred handler. Mutual exclusivity of owner_id and new_owner is explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavioral traits beyond annotations: file writing over SSH, chowning to site user, creating parent directories, dry_run/confirm workflow, and content size limit (256KB). Annotations already indicate destructiveHint=true and idempotentHint=true, and the description aligns perfectly without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each serving a distinct purpose: action, use case/alternatives, parameter guidance. No redundant words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the operation (write, chown, create parent dirs) and the overall workflow. It is complete for a simple file writing tool with clear parameters and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema. For parameters like 'dry_run' and 'confirm', the description explains their role ('dry_run:true to preview, confirm:true to execute'). For 'rel_path', it clarifies 'relative to the web root; parent directories are created as needed.' It also reinforces that 'content' has a max size and how to use encoding for binary. Schema coverage is 67%, and the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a single small file into a site's web root from inline content via SSH, then chowns it. It provides specific examples (index.html, .htaccess, robots.txt) and distinguishes itself from sibling tools (site_files_upload/site_files_deploy), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'quick one-off files (index.html placeholder, .htaccess, robots.txt)' and when not: 'use site_files_upload/site_files_deploy for real payloads.' Also mentions the prerequisite: 'Requires SSH (FASTPANEL_SSH_HOST).'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iMateo/fastpanel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server