Provides tools for managing Nginx Proxy Manager resources including proxy hosts, redirection hosts, 404 hosts, streams, certificates (Let's Encrypt and custom), access lists, users, and settings via its API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@kognar/nginx-manager-mcp-server list all proxy hosts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server que abstrai chamadas à API do Nginx Proxy Manager.
npm install
npm run buildRelated MCP server: coolify-mcp
Aceita via argumentos de CLI ou variáveis de ambiente (CLI tem precedência):
flag | env | descrição |
|
| URL completa da API do NPM (use como está — não adicione porta) |
|
| email de login |
|
| senha |
npx @kognar/nginx-manager-mcp-server \
--base-url https://npm.example.com \
--email admin@example.com \
--password changemeAdicione no claude_desktop_config.json (ou .mcp.json):
{
"mcpServers": {
"nginx-manager": {
"command": "npx",
"args": [
"-y",
"@kognar/nginx-manager-mcp-server",
"--base-url", "https://npm.example.com",
"--email", "admin@example.com",
"--password", "changeme"
]
}
}
}Alternativa com env vars:
{
"mcpServers": {
"nginx-manager": {
"command": "npx",
"args": ["-y", "@kognar/nginx-manager-mcp-server"],
"env": {
"NPM_BASE_URL": "https://npm.example.com",
"NPM_EMAIL": "admin@example.com",
"NPM_PASSWORD": "changeme"
}
}
}
}Proxy hosts — npm_list_proxy_hosts, npm_get_proxy_host, npm_create_proxy_host, npm_update_proxy_host, npm_delete_proxy_host, npm_enable_proxy_host, npm_disable_proxy_host
Redirection hosts — idem com redirection_host
404 hosts — idem com dead_host
Streams — idem com stream
Certificates — npm_list_certificates, npm_get_certificate, npm_create_certificate_letsencrypt, npm_create_certificate_custom, npm_renew_certificate, npm_test_certificate_http_reach, npm_delete_certificate
Access lists — npm_list_access_lists, npm_get_access_list, npm_create_access_list, npm_update_access_list, npm_delete_access_list
Users — npm_list_users, npm_get_user, npm_get_me, npm_create_user, npm_update_user, npm_set_user_password, npm_set_user_permissions, npm_delete_user
Misc — npm_get_settings, npm_get_setting, npm_update_setting, npm_get_audit_log, npm_get_reports_hosts, npm_health
npm run dev # executa via tsx
npm run typecheck # valida tipos sem emitirAutenticação usa POST /api/tokens com cache em memória e refresh automático 1 min antes da expiração.
Create an access list.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| items | No | ||
| clients | No | ||
| pass_auth | No | ||
| satisfy_any | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Create an access list,' omitting any details about destructive actions, permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than conciseness. It fails to convey essential information, wasting the opportunity to provide value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is grossly incomplete. An agent cannot understand what the tool does or how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to any of the 5 parameters. Critical fields like 'items', 'clients', 'pass_auth', and 'satisfy_any' remain completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an access list.' is essentially a tautology of the title and name. It states the action but provides no differentiation from sibling tools like npm_update_access_list, npm_get_access_list, or other create tools, making it minimally helpful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as npm_update_access_list or npm_get_access_list. The description lacks any context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a custom certificate record. File upload must follow via npm_upload_certificate.
| Name | Required | Description | Default |
|---|---|---|---|
| nice_name | Yes | ||
| domain_names | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It only mentions the required follow-up upload but omits details on auth requirements, side effects, or response behavior, which are critical for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, each serving a distinct purpose: defining the main action and indicating the required follow-up. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters and no output schema or annotations, the description is insufficient. It does not explain parameter usage, return values, or the overall process beyond the upload step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to the parameters 'nice_name' or 'domain_names'. It fails to explain their purpose or expected values, leaving the schema to carry all semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a custom certificate record, distinguishing it from sibling tools like npm_create_certificate_letsencrypt. It specifies the action ('create') and the resource ('custom certificate record'), with a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance that file upload must follow via npm_upload_certificate, indicating a two-step workflow. While it doesn't list when not to use this tool, it gives clear contextual usage for custom certificates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a new Let's Encrypt certificate for the given domain names.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | Yes | ||
| domain_names | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as idempotency, side effects, or prerequisites like domain ownership verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous text, but it is too brief to be informative. Slightly below average due to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested parameters and a required agreement boolean, yet no output schema or annotations. The description alone is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameter beyond what the schema defines. With 0% schema description coverage, it fails to add meaning for required fields like 'meta.sub.letsencrypt_agree' or 'meta.sub.letsencrypt_email'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names 'Let's Encrypt certificate' which distinguishes it from the sibling tool 'npm_create_certificate_custom'. The verb 'request' is specific and the resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like npm_create_certificate_custom. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a 404 host.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | ||
| ssl_forced | No | ||
| domain_names | Yes | ||
| hsts_enabled | No | ||
| http2_support | No | ||
| certificate_id | No | ||
| advanced_config | No | ||
| hsts_subdomains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'create' without any details on side effects, permissions, or resource impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concise in a helpful way—it omits essential information, making it under-specified rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description is wholly insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description adds no meaning to the 8 parameters, leaving the agent without any explanation of their purpose or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a 404 host' is essentially a tautology of the title and does not explain what a '404 host' is, failing to differentiate from sibling tools like create_proxy_host or create_redirection_host.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new proxy host.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | ||
| locations | No | ||
| ssl_forced | No | ||
| domain_names | Yes | ||
| forward_host | Yes | ||
| forward_port | Yes | ||
| hsts_enabled | No | ||
| http2_support | No | ||
| access_list_id | No | ||
| block_exploits | No | ||
| certificate_id | No | ||
| forward_scheme | Yes | ||
| advanced_config | No | ||
| caching_enabled | No | ||
| hsts_subdomains | No | ||
| allow_websocket_upgrade | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It only says 'Create,' which implies mutation, but does not describe side effects, permissions, conflict handling, or response behavior. This is critically incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it fails to provide any value beyond the name. It is under-specified rather than concise, offering no meaningful content despite the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (16 parameters, nested objects, no annotations, no output schema), the description is grossly insufficient. It does not explain the return value, error cases, or any operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema) and the tool description adds no parameter explanations. With 16 parameters including required ones like domain_names and forward_host, this is a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new proxy host.' clearly states the verb and resource, and the tool name differentiates it from siblings like create_dead_host or create_redirection_host. However, it does not elaborate on scope or nuances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., redirection host or dead host). There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a redirection host.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | ||
| ssl_forced | No | ||
| domain_names | Yes | ||
| hsts_enabled | No | ||
| http2_support | No | ||
| preserve_path | No | ||
| block_exploits | No | ||
| certificate_id | No | ||
| forward_scheme | Yes | ||
| advanced_config | No | ||
| hsts_subdomains | No | ||
| forward_http_code | No | ||
| forward_domain_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states 'create' without mentioning side effects, permissions, or safety, which is insufficient for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, but this is under-specification rather than conciseness; it does not efficiently convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, many siblings, no output schema), the description is completely inadequate, leaving major gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no information about the 13 parameters, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a redirection host.' is a tautology, restating the tool's title and name without providing any additional context or differentiation from sibling tools like npm_create_proxy_host or npm_create_dead_host.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, leaving the agent without context for selection among many similar creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a TCP/UDP stream.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | ||
| incoming_port | Yes | ||
| certificate_id | No | ||
| tcp_forwarding | No | ||
| udp_forwarding | No | ||
| forwarding_host | Yes | ||
| forwarding_port | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Create', implying resource creation, but does not disclose side effects, permission requirements, or idempotency. No behavioral details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. However, it sacrifices necessary detail, making it less useful. It could be slightly longer to include key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested objects, no output schema), the description is severely incomplete. It omits parameter roles, default behaviors, and return value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any of the 7 parameters, including required ones like incoming_port, forwarding_host, and forwarding_port. The meta nested object is also undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('TCP/UDP stream'), differentiating from siblings like npm_create_proxy_host which handle HTTP/HTTPS. However, it does not specify the context (e.g., Nginx Proxy Manager) or elaborate on the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like npm_create_proxy_host or npm_create_redirection_host. The description does not mention suitability for non-HTTP traffic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new user.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | ||
| name | Yes | ||
| Yes | |||
| roles | No | ||
| nickname | Yes | ||
| is_disabled | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, required permissions, or limitations. The description is extremely sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-informative for a tool with multiple parameters and no additional guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects, no output schema), the description is severely incomplete. It fails to provide essential context for an AI agent to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any parameter information beyond what's in the schema. Six parameters including nested objects remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Create' and the resource 'user'. It distinguishes from sibling tools like npm_delete_user, npm_update_user, and npm_list_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or context provided. The description is too minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an access list.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Delete an access list' without disclosing any side effects, permissions required, or whether the deletion is permanent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very short, it lacks necessary detail about the operation, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations or output schema, the description should provide more context about behavior and impact, but it is too minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'id' parameter or its required nature; with 0% schema description coverage, the description adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'access list', distinguishing it from sibling tools like npm_create_access_list and npm_get_access_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting an access list by ID, but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a certificate by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'delete', which implies a destructive action, but does not explain side effects, required permissions, or any impact on dependent resources. A delete tool should clarify that the operation is permanent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It conveys the necessary information without any redundancy, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is destructive, has no output schema, and no annotations, the description should provide more context about the operation's safety, expected response, and any conditions. It fails to address these, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required integer parameter 'id' with exclusiveMinimum 0. The description adds 'by ID', which aligns with the schema. Since schema description coverage is 0%, the description adds some meaning but does not explain what the ID refers to (e.g., certificate ID). This is adequate for a single obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'certificate' with the method 'by ID'. It is specific enough to distinguish from sibling delete tools that target different resources. However, it could be improved by an explicit sentence differentiating it from other certificate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that deletion is irreversible, any prerequisites (e.g., certificate must not be in use), or that this should be used when removing a certificate from the system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a 404 host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a destructive action (delete) but does not disclose consequences (e.g., permanent deletion, cascading effects, required permissions). With no annotations, the description should carry the full burden, but it fails to provide behavioral context beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but overly minimal. While it avoids verbosity, it sacrifices essential details. It is appropriately sized for a simple operation but lacks structure (e.g., not front-loaded with critical info).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool performs deletion with one parameter and no output schema, the description is incomplete. It omits critical context like id source, id validation, deletion confirmation, or error conditions. The agent lacks sufficient information to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the required 'id' parameter or its meaning. The agent receives no guidance on what 'id' represents or how to obtain it, making parameter usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a 404 host' clearly states the action (delete) and the resource (a 404 host). However, it does not clarify the relationship between '404 host' and the sibling term 'dead_host', causing slight ambiguity. It is specific enough but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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 like npm_disable_dead_host or npm_update_dead_host. The description does not provide prerequisites, scenarios, 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.
Delete a proxy host by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It states deletion but omits consequences (e.g., irreversible, no confirmation), authorization needs, or side effects like invalidating dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is concise but may be under-specified. It lacks detail but fits basic requirements without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no output schema), the description is minimal. It does not specify return value, error handling, or what happens post-deletion. Could mention if the resource must exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description does not explain the 'id' parameter beyond schema details (integer, >0). No hints on how to obtain the ID or permissible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), resource (proxy host), and identifier (by ID). It distinguishes from sibling tools like npm_create_proxy_host, npm_get_proxy_host, etc. by specifying delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., npm_disable_proxy_host). No prerequisites, effects on related resources, or when deletion is allowed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a redirection host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose that deletion is permanent and irreversible, nor does it mention any side effects or required permissions. With no annotations, the description carries the full burden of behavioral disclosure, which it fails to meet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but lacks necessary details, making it under-specified rather than concise. It uses only 4 words, omitting critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no output schema, no parameter descriptions, and no annotations, the description is incomplete. It should at minimum clarify the permanent nature of the operation and the role of the id parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no value beyond the schema for the parameter 'id.' With schema description coverage at 0%, the description should explain that the 'id' identifies the redirection host to delete, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a redirection host,' which is a specific verb+resource combination. It accurately reflects the tool's function but does not distinguish from related operations like disabling, which could be added for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as npm_disable_redirection_host. The description lacks any context about appropriate usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a stream.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It does not indicate whether deletion is permanent, what dependencies exist, or any required permissions. For a delete operation, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words), but it is under-specified rather than efficiently complete. Valuable information about the parameter and behavior is omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema but lack of output schema, the description should at minimum explain the deletion's effect and id meaning. It fails to provide a complete picture for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for the required 'id' parameter. The meaning of 'id' (e.g., stream ID) is not clarified, leaving the agent to infer from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action on the resource ('Delete a stream'), but it does not differentiate from sibling delete tools (e.g., npm_delete_proxy_host). The verb and resource are explicit, but no unique scope or effect is described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool, prerequisites, or alternatives. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a user.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action (delete) but fails to mention whether deletion is irreversible, cascading, or requires special permissions, leaving critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (three words) but fails to earn its place because it merely repeats the title. It could be more informative without adding length, making it under-specified rather than concisely effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description provides almost no context about return values, side effects, or usage constraints. Even for a simple tool, this is insufficient for an agent to understand the full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' has no description in the schema (0% coverage), and the tool description does not explain its meaning or format. While the integer and exclusiveMinimum hint at a user identifier, the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a user.' is a tautology that restates the tool name and title without adding any specificity or distinguishing it from siblings like npm_update_user or npm_set_user_permissions. While the purpose is clear, it does not provide additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. For instance, it does not clarify prerequisites or that this is the only way to remove a user, nor does it mention related tools like npm_disable_proxy_host for other resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable a 404 host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects (e.g., does disabling stop traffic?), reversibility, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but its brevity omits necessary details. It is not overly verbose but sacrifices completeness for concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter) and lack of output schema, the description is still incomplete. It fails to explain the 'id' parameter or the effect of disabling a dead host, which is insufficient given the numerous sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the required 'id' parameter. With 0% schema description coverage, the description should add meaning to the parameter, but it adds none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disable a 404 host' clearly states the action (disable) and the resource (404 host). It directly distinguishes the tool from sibling tools like npm_enable_dead_host or npm_delete_dead_host.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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. The purpose is clear, but there is no mention of prerequisites or why one might choose to disable rather than delete or enable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable a proxy host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as side effects, reversibility, idempotency, required state (e.g., host must be enabled), or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words), but this brevity comes at the cost of missing essential information. It is under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter details, the description is insufficient for an agent to understand the tool's behavior, effect, or proper usage. Critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the 'id' parameter's meaning beyond what the schema indicates (integer, exclusiveMinimum >0). The description adds no value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disable a proxy host' minimally states the action and resource, distinguishing it from sibling disable tools for other resources. However, it is nearly a tautology with the tool name and lacks any additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., enable_proxy_host, dead host disable). There are no prerequisites, conditions, or usage notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable a redirection host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'disable' with no details on side effects, immediacy, or permissions required. Since no annotations exist, the description carries full burden but fails to disclose behavioral traits beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 4 words, extremely concise and front-loaded. Every word is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimally adequate but lacks context about what 'disable' entails (e.g., impact on redirection, success/failure communication). It is incomplete for an agent without domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one integer parameter 'id' with no description, and the tool description does not mention it at all. With 0% schema coverage, the description should compensate by explaining the parameter's role, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'disable' and the resource 'redirection host', making the action clear. However, it does not distinguish this tool from sibling tools like disable_dead_host or disable_proxy_host, which have identical phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or when not to. There is no mention of prerequisites, reversibility, or comparison to alternative tools like enable_redirection_host.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable a stream.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as whether the action is destructive, reversible, or requires permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. It lacks necessary information, making it insufficient rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal context, the description is completely inadequate. It fails to explain what disabling a stream entails, the effects, or any prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'id' with 0% schema description coverage. The description does not explain what 'id' refers to or any constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disable a stream' restates the tool's name and title without adding specificity. It does not differentiate from sibling tools like npm_disable_dead_host or npm_disable_proxy_host, leaving the nature of 'stream' undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to disable vs delete, enable, or other stream operations. The description provides no context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable a 404 host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the minimal purpose. No annotations exist, so the description carries full burden. Fails to disclose what enabling entails (e.g., flag setting, routing changes, reversibility), permissions required, or potential side effects. This is insufficient for a state-modifying tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words), but this conciseness comes at the cost of clarity. While no extraneous words exist, it is under-specified for effective tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description fails to provide sufficient context. It does not clarify the meaning of 'id,' the state change (enabling vs. disabling), or how this tool relates to siblings. Agent is left guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It makes no mention of the 'id' parameter, leaving its meaning (identifier of the dead host to enable) implicit. An agent would have to infer from tool name, which is unreliable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enable a 404 host,' using a specific verb ('enable') and resource ('404 host'). This distinguishes it from sibling tools like 'disable' and 'create' variations. However, 'dead host' is a domain-specific term that may not be immediately clear to all agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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., vs. npm_disable_dead_host or npm_update_dead_host). Does not mention prerequisites such as the host needing to exist and be disabled. No exclusionary criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable a proxy host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It fails to mention that the proxy host must exist, that enabling is reversible, or any required permissions. The minimal description does not compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but it is under-specified. While there is no waste, the lack of detail makes it less useful. A balance between conciseness and informativeness is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is far from complete. It does not address what happens after enabling, error conditions, or the state change. Competes with many sibling tools but offers no unique context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain the parameter 'id'. It does not mention that id refers to the proxy host ID. The schema itself is sparse, and the description adds no value beyond what the name implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable a proxy host.' clearly states the action (enable) and resource (proxy host), distinguishing it from siblings like create, delete, disable, and list. However, it lacks additional context about what enabling entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like npm_create_proxy_host (to create) or npm_disable_proxy_host. There is no mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable a redirection host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats the action without disclosing behavior beyond the trivial 'enable' concept. No annotations are present, so there is no indication of whether the operation is reversible, requires authentication, or has side effects. The description fails to add value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one sentence), which is concise but comes at the cost of completeness. It is not wasteful, but several important details are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and minimal parameter info, the description is insufficient for a tool that changes state. The agent lacks context about outcomes, errors, or relationships to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'id' with no description, and the tool description provides no explanation of what 'id' represents (e.g., the host ID to enable). Schema coverage is 0%, so the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Enable') and the resource ('a redirection host'), making it clear what the tool does. However, it does not differentiate from sibling tools like 'npm_enable_proxy_host' or 'npm_enable_dead_host', which use the same verb for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the other enable tools (e.g., enable_proxy_host, enable_stream). There is no mention of prerequisites, allowed states, or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable a stream.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavioral traits. It fails to mention side effects, required permissions, or what 'enable' actually does (e.g., start streaming, make active). This is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but lacks essential content. It is under-specified rather than genuinely concise, sacrificing usefulness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema or annotations, the description is entirely inadequate. It does not explain the purpose or context of enabling a stream, leaving the agent with no useful information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no information about the required 'id' parameter, such as its meaning or constraints, beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable a stream' clearly indicates the verb (enable) and resource (stream), distinguishing it from sibling tools like disable_stream or create_stream. However, it lacks specificity about what enabling entails, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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. The description does not mention prerequisites, context, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an access list by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Get an access list by ID,' which implies a read operation, but does not disclose what happens if the ID is invalid, authentication requirements, or any side effects. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose. It is concise, but possibly too terse for a tool with no annotations. A slightly longer description could improve completeness without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 parameters, no output schema, no annotations), the description lacks critical context: what the tool returns (likely an access list object), behavior on missing ID, and error types. An agent needs more details to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (id, expand) with 50% description coverage (expand has a description in the schema, id does not). The description adds no information about the parameters beyond what the schema provides. It does not explain the meaning of 'expand' or constraints on 'id' beyond the schema's exclusiveMinimum. This is a missed opportunity to add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get an access list by ID.' It identifies the specific verb (get) and resource (access list) with a retrieval method (by ID). This distinguishes it from sibling tools like npm_list_access_lists (which lists all) and create/update/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific ID, as indicated by 'by ID.' However, it does not explicitly state when to use this tool versus alternatives like npm_list_access_lists (for listing all access lists) or mention prerequisites or error handling. The clarity is adequate but lacks explicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the audit log.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, required permissions, rate limits, or pagination. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence with no wasted words. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse. It lacks details about the audit log's content, interpretation, or constraints. For a simple fetch operation, more context would improve usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with 100% schema description coverage trivially. The baseline for no parameters is 4; the description adds no additional meaning but also does not need to since schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch the audit log' with a specific verb+resource. It distinguishes from sibling get tools like npm_get_access_list by referencing a unique resource. However, it lacks additional context about what an audit log entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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. The description simply states the action without context for appropriate use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a certificate by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the basic action without indicating whether the operation is read-only, error behavior, or any side effects. This is insufficient for an agent to anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no extraneous words. It front-loads the core purpose and efficiently conveys the necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate parameter count (2), the description provides only the bare minimum. It omits return values, pagination, or error conditions. For a simple retrieval tool, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. The description adds no extra meaning beyond the schema: 'id' is just 'by ID' and 'expand' already has a schema description. The minimal addition does not compensate for the incomplete schema definition of 'id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'certificate by ID', making the purpose unambiguous. While it differentiates from siblings with similar naming patterns (e.g., npm_get_proxy_host), it does not explicitly highlight unique aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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., npm_list_certificates, npm_renew_certificate). There is no mention of prerequisites, context, 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.
Get a 404 host by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose any behavioral traits beyond the read operation implied by 'Get'. No mention of permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence, no wasted words. However, it is so minimal that it may not provide enough context for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return values or behavior. It does not mention any prerequisites or results, making it incomplete for a CRUD tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only expand parameter has a description). The tool description does not add meaning beyond what the schema provides, notably missing an explanation for the required 'id' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (404 host), distinguishing it from sibling get tools like npm_get_proxy_host. However, it does not explain what a 404 host is, limiting complete clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as npm_list_dead_hosts or other get tools. The description does not mention prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Get', implying a read-only operation, but does not disclose any other behavioral traits such as authentication requirements or side effects. Given the simplicity, this is acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a tool with no parameters and a straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is complete enough to inform the agent of the tool's purpose. It could optionally hint at the return value, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter details. The baseline for zero parameters is 4, and the description appropriately confirms the tool takes no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the currently authenticated user' clearly states the verb (Get) and the specific resource (currently authenticated user). It distinguishes this tool from sibling tools that retrieve other resources or perform mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use this tool versus alternatives. However, the purpose is self-evident for a simple retrieval tool, so it is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a proxy host by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden for behavioral disclosure. It does not mention permissions, error behavior (e.g., if ID not found), rate limits, or any side effects. The description is too sparse to adequately describe the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but omits necessary details. It states the core purpose, but could be more informative without being verbose. The structure is minimal but functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of an output schema, the description should at least mention that it returns a single proxy host, possibly with expand options, but it does not. The description is complete only in the most basic sense and lacks sufficient context for a remote agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 50% of parameters with descriptions (expand has a description, but id lacks one). The tool description adds no meaning beyond the schema; it does not clarify what 'id' represents or how to use 'expand'. The description fails to compensate for the missing schema description on the required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('proxy host'), clearly distinguishing it from sibling tools like create, update, delete, and list. The 'by ID' is implicit from the required id parameter, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like npm_list_proxy_hosts (for listing) or other get tools for different resources. There is no mention of prerequisites or 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.
Get a redirection host by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the basic operation without disclosing behavior like error handling (e.g., if ID not found), auth requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary verbiage. It efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It doesn't explain what a redirection host is, the structure of the response, or any additional context needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. The 'expand' parameter already has a description in the schema, but 'id' has none and the description doesn't supplement it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('a redirection host'), and method ('by ID'). It distinguishes from sibling tools like list_redirection_hosts and create/update/delete variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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. Lacks context about prerequisites, limitations, or comparison to similar tools (e.g., list_redirection_hosts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate hosts report (counts by type/status).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not explicitly state that the tool is read-only or non-destructive, which is important given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it could be slightly more descriptive without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not clarify the output format, the scope of hosts included, or any prerequisites, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters, the schema coverage is 100%, and the description has no need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns an aggregate hosts report with counts by type and status, distinguishing it from list/get tools for individual hosts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as listing individual hosts or retrieving specific host details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a setting by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description relies solely on the word 'Get' to imply read-only behavior, but no additional details about side effects, authentication, or return format are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but lacks structure and sufficient detail for a minimal viable description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single parameter, the description fails to explain what the tool returns, what names are acceptable, or any side effects. It is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'name' is described only as 'by name', adding no meaning beyond the schema. The schema description coverage is 0%, and the description does not explain what values are valid or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it 'Get[s] a setting by name', which indicates the action and resource, but it does not differentiate from the sibling tool 'npm_get_settings' (which likely lists all settings) or clarify what a 'setting' is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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 like 'npm_get_settings' or 'npm_update_setting'. No prerequisites or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all NPM settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply says 'List', which implies a read operation, but provides no details on authentication requirements, side effects, or return structure. With no annotations, the description carries the full burden for behavioral disclosure, and it fails to add meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is appropriately front-loaded with no wasted words. It is highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is functional. However, it lacks any context about the output format or prerequisites, which for a listing tool could be considered adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuous). The description does not need to add parameter info, and it correctly communicates the operation without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all NPM settings' with a specific verb (List) and resource (NPM settings). It distinguishes from sibling tools like npm_get_setting which retrieves a specific setting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as npm_get_setting or other list tools. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a stream by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, authentication, or response behavior, but it only states the basic retrieval action. Does not mention read-only nature or any important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise but too minimal; lacks necessary detail for a retrieval tool with two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely incomplete: no output schema, no explanation of what a 'stream' is, no return value description, and no behavioral context. Fails to provide sufficient information for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the description adds no meaning beyond the schema. The 'id' parameter is undocumented in both schema and description. The 'expand' parameter's schema description is already present, so description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Get) and resource (stream by ID), distinguishing it from siblings like npm_create_stream or npm_list_streams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as npm_list_streams or npm_get_proxy_host. Missing context about prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user by ID. Pass 'me' via id=0 is not supported; use the numeric ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the behavior that id=0 is not supported. However, it does not mention other behaviors such as authentication needs, error handling for missing users, or response format. The disclosure is minimal but accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Every sentence earns its place by stating the core function and a critical caveat. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and a caveat, but lacks details about the expand parameter, potential errors, and differentiation from sibling tool npm_get_me. For a simple tool with no output schema, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (expand has a description). The description adds meaning to the id parameter by clarifying that 0 is not valid for 'me', which goes beyond schema's exclusiveMinimum. However, it does not explain the expand parameter, missing an opportunity to add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'user by ID'. It also specifies a key nuance that 'Pass 'me' via id=0 is not supported; use the numeric ID.' This distinguishes it from sibling tools like npm_get_me.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific usage guideline regarding the id parameter (not using 0 for 'me'), but does not explicitly differentiate this tool from alternatives like npm_get_me or explain when to use which. It implies the context but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check NPM API health/version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates a read-only operation by saying 'Check health/version' but does not specify details like return format or whether it is safe (no side effects). More transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence—with no wasted words. It is front-loaded and efficiently communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check tool with no parameters and no output schema, the description is mostly complete. It could be more specific about what 'health/version' includes, but overall it provides adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline is 4. The description adds no parameter info because none exist. It correctly states the purpose without needing to detail parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('NPM API health/version'), clearly indicating the tool's purpose. It is easily distinguished from sibling tools which all manage specific resources like access lists or certificates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. However, since it is a simple health check and all siblings are CRUD operations on specific entities, the intended usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all access lists.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'List all access lists,' with no disclosure of side effects, permissions, or limits. The tool appears to be a read-only operation, but no explicit behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded, but could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given 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 and no output schema, the description is minimally complete. It conveys the basic action, but lacks details like filtering scope or return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning to the `expand` parameter; however, the schema already documents it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('access lists'), which aligns with the tool name and title. However, it does not provide additional context to differentiate it from other list tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like `npm_list_certificates` or `npm_list_hosts`. The description lacks any usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all SSL certificates.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states the action but omits details like authentication requirements, response format (list of objects), or potential pagination. It is adequate for a simple read operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is minimally complete. It could mention that the response is a list of certificate objects or include a note about the expand parameter's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra meaning beyond the schema's description of the 'expand' parameter. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all SSL certificates' clearly states the verb (list) and resource (SSL certificates), distinguishing it from sibling list tools for other resources. However, it could be more specific about the scope (e.g., all certificates for the user or system).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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 like npm_get_certificate for a single certificate or other list tools. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 404 (dead) hosts.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states the function with no mention of side effects, authentication needs, rate limits, or return format. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (single sentence) and front-loaded. It conveys the essential purpose without verbosity, though it could include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and no output schema, the description should explain what the output contains. It only says 'list all 404 hosts' without specifying the response format or fields. This is insufficient for an agent to fully understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one optional parameter 'expand' with a description). The description does not add any additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all 404 (dead) hosts' clearly states the verb (list), the resource (dead hosts), and clarifies the meaning of '404'. It distinguishes from sibling list operations like npm_list_proxy_hosts and npm_list_redirection_hosts, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other list tools (e.g., when to list dead hosts vs proxy hosts). No context about prerequisites or alternatives given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all proxy hosts configured in Nginx Proxy Manager.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'list all', implying a read operation, but does not disclose any behavioral traits like pagination, permission requirements, or side effects. For a simple list tool, this is minimally sufficient but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one parameter, the description is minimal but covers the core purpose. It lacks details about the returned data structure or any filtering options, but for a straightforward list tool, it is barely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional 'expand' parameter. The description adds no additional meaning; it does not explain the parameter's effect or provide examples. Baseline 3 is appropriate since the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and resource 'proxy hosts', with the scope 'all proxy hosts configured in Nginx Proxy Manager'. It clearly states the tool's function and distinguishes it from sibling list tools like npm_list_access_lists by naming the specific resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as npm_get_proxy_host for a single host. There are no exclusions or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all redirection hosts.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose all behavioral traits. It only says 'list all' without mentioning pagination, limits, or any other behavioral aspects. This is inadequate for a list operation that may return many items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. While appropriate for a simple list tool, it could benefit from slight elaboration to improve completeness without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no annotations, no output schema), the description covers the core action but lacks contextual details such as how results are structured or any limitations. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'expand' is fully described in the input schema (100% coverage). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does 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 'redirection hosts', making the tool's purpose unambiguous. It distinguishes itself from sibling tools like 'list_proxy_hosts' by specifying the type of host. However, it lacks additional scope or context that could enhance clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like listing dead hosts or proxy hosts. Siblings are present but not mentioned, leaving the agent without decision-support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all TCP/UDP streams.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It does not disclose whether the operation is read-only, requires authentication, or how results are structured (e.g., pagination, return format). The phrase 'List all TCP/UDP streams' implies read-only but provides no safety or behavioral guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise and front-loaded. However, it is under-specified, lacking important details that could be added without significant verbosity, so it doesn't earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with one optional parameter and no output schema, the description should explain what 'streams' are, how the expand parameter affects results, and the return format. It omits these details, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (expand). The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (TCP/UDP streams), which is specific and distinguishes this tool from sibling list tools that target different resources like access lists, certificates, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does without any context about prerequisites, exclusions, or alternative tools, leaving the agent without enough information for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all NPM users.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional expand fields (e.g. ['owner','certificate']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It only states the function without disclosing read-only behavior, authentication needs, rate limits, or pagination. The expand parameter is documented in the schema but not here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and direct, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 optional param, no output schema), the description is too sparse. It should mention that it returns a list of user objects and any authentication or rate limit contexts. Without annotations or output schema, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'expand', including an example. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all NPM users, with a specific verb and resource. It is distinct from sibling tools like npm_get_user or npm_create_user, though it could explicitly note the 'all' scope to avoid ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, when to pick this over npm_get_user, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renew a Let's Encrypt certificate.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'Renew a Let's Encrypt certificate' without explaining side effects, authorization needs, or what 'renew' entails (e.g., does it replace an existing certificate?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient and to the point. However, it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and low parameter coverage, the description is insufficient. It fails to explain the tool's behavior, return values, or how to use the parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no explanation for the required 'id' parameter. The agent is left to infer that it is the certificate ID, but no guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Renew' and the specific resource 'Let's Encrypt certificate', distinguishing it from sibling tools like 'npm_create_certificate_letsencrypt' which creates certificates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does 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, such as creating a new certificate or renewing via a different method. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a user's password.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| secret | Yes | ||
| current | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action ('Set a user's password') without informing about side effects, authorization requirements, or whether password complexity is validated. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence without unnecessary words. It is concise, though it could be expanded slightly without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the absence of an output schema, the description is incomplete. It does not explain what 'id' refers to or provide enough context for the agent to use the tool correctly, especially given the three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no meaning to parameters. The parameters 'id', 'secret', and 'current' are not explained, leaving an agent to guess their roles among the three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets a user's password, with a specific verb ('Set') and resource ('user's password'). However, it does not differentiate from sibling tools like npm_update_user, which may also modify user credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like npm_update_user or npm_create_user. There is no mention of prerequisites, context, or 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.
Set a user's permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| streams | Yes | ||
| dead_hosts | Yes | ||
| visibility | Yes | ||
| proxy_hosts | Yes | ||
| access_lists | Yes | ||
| certificates | Yes | ||
| redirection_hosts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says 'set' without mentioning that it overwrites all permissions, requires authentication, or may fail for missing users. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise but too brief. It lacks essential details, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 required parameters and no output schema, the description is severely incomplete. It does not explain the permission model, default values, or effects of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must explain the parameters. It provides no information about what each parameter (e.g., visibility, streams) means or how they interact. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) on the resource (user's permissions), distinguishing it from sibling tools like npm_update_user or npm_set_user_password. However, it could be more specific by mentioning that it sets multiple permission fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like npm_update_user. The description lacks any context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test whether domains are HTTP-reachable before requesting a cert.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description lacks details beyond the action. No annotations are provided, so it should disclose behavioral traits like side effects (presumably none), authentication needs, or what constitutes reachability. The word 'test' implies read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no extraneous information. It is appropriately sized for a simple test tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what the output represents (e.g., boolean or list of reachable/unreachable). It omits this critical information, reducing completeness despite the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'domains' is well-defined by the schema (array of strings, required). The description adds minimal meaning by linking it to testing HTTP reachability, but does not elaborate further. Schema coverage is 0%, but the parameter is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (test), resource (domains), and context (before requesting a cert). It uniquely identifies the tool's purpose among siblings, as no other tool explicitly tests HTTP reachability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before requesting a cert' provides clear usage context, implying it should be used prior to certificate creation tools. However, it does not explicitly exclude scenarios or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an access list.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| items | No | ||
| clients | No | ||
| pass_auth | No | ||
| satisfy_any | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only says 'Update an access list.' It does not indicate whether updates are additive/replacive, if the action is reversible, what permissions are needed, or any side effects. This is a critical gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks essential detail, crossing from concise into under-specification. Each sentence should add value; this single sentence adds minimal value beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects, no output schema), the description is grossly incomplete. It fails to explain the tool's behavior, parameter roles, or return values, leaving the agent with no actionable understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 6 parameters (id, name, items, clients, pass_auth, satisfy_any). The agent cannot infer parameter meanings or constraints from the description alone, making it impossible to use correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Update' and the resource 'access list', making the basic purpose clear. However, it does not distinguish this tool from sibling update tools (e.g., npm_update_proxy_host) or specify what aspects of an access list can be updated, limiting its clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like npm_create_access_list or npm_get_access_list. There are no exclusions, prerequisites, or context hints, leaving the agent with no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a 404 host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| meta | No | ||
| ssl_forced | No | ||
| domain_names | No | ||
| hsts_enabled | No | ||
| http2_support | No | ||
| certificate_id | No | ||
| advanced_config | No | ||
| hsts_subdomains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Update a 404 host' with no mention of side effects, permissions, idempotency, or whether the update is a full replacement or partial merge. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but this brevity comes at the cost of informativeness. It is under-specified rather than efficiently structured, lacking any useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, nested objects, no output schema, no annotations), a one-sentence description is wholly inadequate. The agent lacks critical information to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to any of the 9 parameters. The agent cannot infer the purpose of fields like meta, ssl_forced, or domain_names from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a 404 host' clearly states the verb (update) and resource (404 host), which distinguishes it from sibling tools like create, delete, or enable for dead hosts. However, it does not elaborate on what a 404 host is, but the name and context make it recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like npm_create_dead_host (creation) or npm_enable_dead_host (enabling). The agent receives no context on prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing proxy host (partial fields allowed).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| meta | No | ||
| locations | No | ||
| ssl_forced | No | ||
| domain_names | No | ||
| forward_host | No | ||
| forward_port | No | ||
| hsts_enabled | No | ||
| http2_support | No | ||
| access_list_id | No | ||
| block_exploits | No | ||
| certificate_id | No | ||
| forward_scheme | No | ||
| advanced_config | No | ||
| caching_enabled | No | ||
| hsts_subdomains | No | ||
| allow_websocket_upgrade | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses partial update capability. It fails to mention side effects, validation, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that is front-loaded with key information, but it could include more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 17 parameters, nested objects, and no output schema, the description is vastly inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only adds that partial fields are allowed, offering no explanation for the 17 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'proxy host', and distinguishes from sibling tools like create and delete by specifying 'existing' and 'partial fields allowed'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, nor any prerequisites or exclusions. It only states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a redirection host.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| meta | No | ||
| ssl_forced | No | ||
| domain_names | No | ||
| hsts_enabled | No | ||
| http2_support | No | ||
| preserve_path | No | ||
| block_exploits | No | ||
| certificate_id | No | ||
| forward_scheme | No | ||
| advanced_config | No | ||
| hsts_subdomains | No | ||
| forward_http_code | No | ||
| forward_domain_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'update' without revealing behavioral traits like idempotency, partial update support, or required permissions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (5 words) but lacks essential detail. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, no output schema, and no behavioral guidance, the description is completely inadequate for correct tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 14 parameters. Users have no textual help beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Update' and resource 'redirection host', which is clear but generic. It does not distinguish from sibling tools like update_proxy_host or update_dead_host, making it minimally adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., create, delete, enable). Users must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a setting by name.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | ||
| name | Yes | ||
| value | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. 'Update' implies mutation, but it does not specify whether it overwrites or merges, if changes are reversible, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is too short (4 words) and lacks necessary detail. Conciseness should not come at the expense of completeness; it is under-specified for a tool with 3 parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, nested object, no output schema), the description is completely inadequate. It does not explain the effect, return value, or any contextual details that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'name' implicitly, but does not explain 'meta' or 'value'. The meaning of 'value' (any type) is unclear, and 'meta' as an object with additional properties is opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'setting', indicating the tool modifies a configuration setting by name. Among sibling tools, many target specific resources (proxy host, stream, user), but this is a generic update for settings. It does not differentiate from those siblings, so not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_setting or other update tools. No context about prerequisites, required permissions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a stream.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| meta | No | ||
| incoming_port | No | ||
| certificate_id | No | ||
| tcp_forwarding | No | ||
| udp_forwarding | No | ||
| forwarding_host | No | ||
| forwarding_port | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose any behavioral traits such as whether the update is partial or full, required permissions, side effects, or error states. The description carries the full disclosure burden but provides nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (3 words) but this is under-specification rather than efficient conciseness. It wastes the opportunity to provide essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, nested objects, no output schema) and lack of annotations, the description is wholly inadequate. It provides no information on return values, error handling, or relationship to stream lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 8 parameters including a complex nested 'meta' object, the description adds no meaning to any parameter. It does not explain required fields, permissible values, or parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a stream' is a tautology that merely restates the title without specifying what aspects are updated or how it differs from other update tools. It provides no unique context to distinguish from sibling tools like npm_update_dead_host.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., create, delete, enable/disable stream tools). There is no indication of prerequisites or disclaimers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a user.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| No | |||
| roles | No | ||
| nickname | No | ||
| is_disabled | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral transparency, but it provides no information about mutation behavior, idempotency, partial vs full update, or any other traits beyond the verb 'Update'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely concise (2 words), the description is under-specified to the point of uselessness. Conciseness is not valuable when it omits critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description is woefully incomplete. It fails to explain required fields, update semantics, or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage on its 6 parameters. The description adds no semantic meaning to fields like 'is_disabled' or 'roles', leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a user' is a tautology, merely restating the tool name and title without specifying what aspects of a user can be updated or how it differs from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like npm_create_user or npm_set_user_password. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a unique combination of action and resource (e.g., npm_create_proxy_host vs npm_delete_proxy_host). Actions like create, delete, get, list, update, enable, disable are clearly distinct across resource types (proxy_host, redirection_host, stream, etc.), leaving no ambiguity for an agent.
All tools follow a consistent 'npm_<verb>_<noun>' pattern. Verbs are standard CRUD plus enable/disable, and nouns are resource names. No mixing of camelCase or snake_case, and the pattern is predictable across all 54 tools.
With 54 tools, this server has a very high tool count for a single domain. While each tool serves a distinct purpose, the number exceeds the 25+ threshold for 'too many', potentially overwhelming an agent or requiring excessive navigation.
The tool set covers full CRUD for all major Nginx Proxy Manager resources (proxy hosts, redirection hosts, streams, certificates, access lists, users, settings) plus enabling/disabling, certificate testing and renewal, audit log, and reports. No obvious gaps exist for core proxy management tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
MCP server for generating rough-draft project plans from natural-language prompts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kognar-ai/ngnix-manager-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
