proxy-aiops
Server Quality Checklist
Latest release: v0.7.0
- Disambiguation5/5
Each tool targets a distinct resource and action: basic list/detail reads for routes, services, upstreams, and certs are clearly separated from higher-level analyses (backend_health_rca, error_rate_rca, cert_expiry_sweep, route_conflict_analysis) and reversible writes (set/delete/load config, server state/weight). The layered design (e.g., backend_health_rca consumes list_upstreams data) reduces confusion rather than creating it.
Naming Consistency4/5The naming follows a consistent pattern of list_* for enumerations, *_detail for single-item reads, and set_/delete_/load_ for writes, but mixes conventions like route_detail (noun_noun), proxy_overview, and *_rca suffixes. Overall it is readable and predictable, with minor deviations that don't hinder navigation.
Tool Count3/5At 28 tools, this is slightly above the comfortable 15-25 range, but the broad scope across three proxy platforms (traefik, caddy, haproxy) and multiple operational areas (config, health, TLS, traffic, error analysis) justifies most entries. A few tools could be merged (e.g., list_certificates and cert_expiry_sweep), making it borderline rather than excessive.
Completeness4/5The surface covers the core proxy operations lifecycle well: configuration reading/editing/deletion, route and service inspection, upstream health monitoring, TLS certifications, traffic/error statistics, and RCA analyses. Minor gaps include no direct create/delete tools for routes/services (though set_config_value and delete_config_path can achieve this) and limited write capabilities for non-caddy platforms, but the domain is well covered overall.
Average 4.4/5 across 28 of 28 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It discloses the operation is a read ([READ]) but lacks details on behavior such as whether it queries live backends, error handling, or output structure. Minimal extra context beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear headline and a brief args section. No wasted words, front-loaded purpose, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations, so description should provide more context on return structure and usage nuance. It gives a high-level purpose and parameter but omits details like output format and when to use it, making it incomplete for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). The description explains 'target' as a proxy target name from config and notes omitting uses default, adding meaning beyond the schema. This adequately covers the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists services/backends with per-service server-up counts, using a specific verb and resource. However, it doesn't explicitly differentiate from sibling tools like service_detail or list_upstreams, so it 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.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't mention any exclusions or suggest other tools for different needs. The only usage context is implicit in the purpose, providing no explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the read-only nature via '[READ]', mentions 'sanitised and bounded' output, and notes a special haproxy behavior. It does not detail potential errors or rate limits, but the key safety and output traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, front-loaded with the READ intent and resource. The Args section is clearly separated. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter, and some behavioral traits, but it lacks details about the return format (no output schema) and what 'bounded' means in practice. For a simple read tool it's mostly adequate, but an agent might need more context on output structure or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args' section explains the target parameter as 'Proxy target name from config' and specifies that omitting it uses the default. This adds real meaning beyond the bare schema, which only gives a title and default null. The contextual mention of caddy/traefik/haproxy also aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads the live config tree or merged dynamic state, with a specific '[READ]' verb and resource. It doesn't explicitly distinguish from sibling tools like get_config_value, but the resource scope (full tree vs specific value) is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_config_value or search_config. The description only explains what the tool does, not the appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It includes '[READ]' to signal a read-only operation and explains the optional target parameter. It does not disclose return format or error behavior, but for a simple list tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose, followed by a minimal parameter explanation. Every sentence adds value without redundancy, and the structure is clean for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers purpose, parameter semantics, and read-only nature. It does not detail return values, but that is less critical for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'target' parameter, but the description provides an 'Args' block explaining it as 'Proxy target name from config; omit for the default.' This adds meaningful guidance beyond the schema, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool lists listeners/entrypoints across traefik, caddy, and haproxy, with the context 'where traffic enters this proxy'. It distinguishes itself from sibling tools like list_routes and list_services by focusing on entrypoints, though the verb 'list' is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to inspect listener/entrypoint definitions, and the '[READ]' tag suggests a safe read operation. However, it does not explicitly mention when to use this over alternatives or any exclusions, relying on the reader to infer usage from the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as '[READ]', explicitly signalling that it does not mutate state, which is useful given no annotations are provided. However, it does not disclose other behavioral aspects such as potential performance costs, error behavior, or the format of the 'up/down health' data. The [READ] flag is the only clear behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a bracketed [READ] tag, a one-line summary of the output, and a single-line argument explanation. It front-loads the core purpose and contains no wasted words. Structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, no output schema), the description sufficiently covers what the tool returns (platform/version, counts, health). It does not explain error cases or detailed semantics of 'up/down health', but this is not essential for a summary tool with no output schema. The description is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides the parameter name 'target' with a default of null and no description. The description compensates by explaining 'target' as the 'Proxy target name from config' and notes the default behavior when omitted. This is helpful and goes beyond the schema, though it is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'One-shot summary' of platform/version, route/service counts, and upstream health. This specific verb+resource combination distinguishes it from sibling list/detail tools, making its purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'One-shot summary' implies when to use it (a quick overview instead of calling multiple listing endpoints), but it does not explicitly state when not to use it or name alternatives. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. The [READ] label discloses that it is a read operation, and 'from list_upstreams' hints at data provenance. However, it does not elaborate on state or side effects, leaving room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a one-sentence purpose followed by an Args block. Every line provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple detail-fetch tool with no output schema, the description covers invocation fully: what it does, how to specify parameters, and a key prerequisite (list_upstreams). It does not explain return fields, but that is not essential for calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining each parameter: service is the backend name, server is the name/address from list_upstreams, and target is the proxy target name with default behavior. This adds meaning beyond the schema's bare names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving a single upstream server's health/state row. The [READ] prefix and 'One upstream server's health/state row' make it distinct from sibling list tools like list_upstreams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage by indicating the server parameter comes from list_upstreams, but does not explicitly state when to use this tool versus alternatives (e.g., list_upstreams for overview). The 'omit for the default' guidance for target adds practical context but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly labels the operation as '[READ]', indicating non-mutation, and adds useful details about path validation (dot-segments rejected) and off-caddy platform fallback behavior. This goes beyond simple read-only labeling, though it stops short of describing error handling or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, front-loaded with the primary purpose and read-only indicator. The argument explanations are concise and every sentence adds value. It is appropriately sized for a tool with two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two parameters and no output schema, the description covers the main functionality, parameters, and a platform-specific edge case. However, it does not specify the return type, behavior when the path is not found, or error handling, which would be useful given no output schema. Overall, it is adequate but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. Both parameters are explained with specific meaning: path is a slash-separated config path with dot-segment rejection, and target is a proxy target name with a default behavior of omission. This adds significant semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single value from the Caddy config tree by path, which distinguishes it from sibling tools like search_config or config_snapshot. The verb 'get' and specific resource 'caddy config tree by config path' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as search_config or config_snapshot. It does mention off-caddy platform behavior, but this is a behavioral note, not usage guidance. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden and the leading '[READ]' explicitly signals read-only behavior. It also discloses the unexpected behavior on caddy/haproxy. It does not describe return format or error cases, but for a simple listing tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the read indicator, and uses a clear structure. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, one optional parameter, and absent output schema, the description covers the essential aspects: read safety, platform-specific behavior, and parameter usage. Minor omissions like return format are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the target parameter as 'Proxy target name from config; omit for the default,' adding meaning not present in the schema alone. Since schema coverage is 0%, this fully compensates for the single optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies list_middlewares as a read operation for Traefik middlewares and explains its behavior on other proxies. It does not explicitly compare with sibling tools like list_routes, but the platform-specific scope makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear platform boundary: use it for Traefik middlewares, while on caddy/haproxy it returns a teaching note. This is helpful context, though it does not explicitly name alternative tools or provide a full when-not-to-use list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior traits. The '[READ]' prefix signals a safe read operation, and the note about normalization and compatibility adds context. It does not mention pagination, error behavior, or rate limits, but for a listing tool, the key behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a summary line, a compatibility note, and clear Args. Every sentence earns its place, though it could be slightly tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lists routes with defined output fields, and the description covers those fields, the normalization behavior, and the parameter semantics. It lacks details on edge cases (e.g., what 'default' means for target, whether enabled filters are applied) but is sufficient for a straightforward listing tool. No output schema exists, so the field list partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates fully by explaining both parameters. It clarifies that host is an optional filter that keeps host-less catch-alls, and target is a proxy target name from config with a default. This adds specific meaning beyond the bare schema, making the parameters clear and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists routes normalized across platforms, with a specific set of fields. The verb 'list' and resource 'routes' distinguish it from siblings like list_services or list_middlewares, and the mention of normalization clarifies its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all routes in a normalized format, and notes that names/paths are returned as other tools expect. However, it does not explicitly state when to use this instead of route_detail or find_route, nor does it provide exclusions or alternatives. The host and target filters give some context but not clear selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden. It explicitly tags the tool as [READ], discloses that metrics availability depends on the platform, and explains the truncation behavior of the returned envelope. It goes beyond a simple description by noting the caddy teaching note and the envelope's 'truncated' flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear summary, labeled Args, and Returns sections. Every sentence adds value, including platform caveats and output envelope details. It is concise without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return envelope and truncation behavior, which is essential given no output schema. It also mentions metric types and platform dependencies. It could be slightly more detailed about the shape of each service object, but overall it is sufficiently complete for a moderately complex tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'target' parameter (0% coverage), but the description adds useful semantics: it is a proxy target name from config and omitting it selects the default. This compensates for the schema gap and gives the agent enough context to use the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a per-service traffic snapshot with specific metrics (requests, latency/rate/sessions). It distinguishes itself from sibling tools by focusing on traffic metrics and mentions platform-specific sources, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when needing traffic statistics per service. However, it does not explicitly state when to use this over alternatives like proxy_overview or list_services, nor does it mention exclusions. It lacks clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. The '[READ]' prefix signals a non-mutating operation, and the argument explanations add context about accepted route name formats and target defaults. However, it does not disclose error behavior, return format details, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a clear one-sentence purpose and following with a compact argument list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read tool: it states the input source, explains both parameters, and indicates the operation returns full details. It could be more complete by specifying the output shape or failure behavior, but given the low complexity, it is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains that 'name' can be a traefik router name, caddy route config path, or haproxy frontend name, and clarifies that 'target' is a proxy target name from config with a sensible default when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'One route's full detail by name', with a specific verb, resource, and scope. The phrase 'from list_routes' distinguishes it from the sibling list_routes tool and indicates the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after list_routes by stating the input comes from list_routes, which provides clear contextual guidance. However, it does not explicitly mention when not to use the tool or name alternatives such as find_route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. The '[READ]' prefix signals a safe read operation, and the parameter details explain accepted formats. However, it doesn't state whether errors are raised for unknown names or describe the response structure, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose line and a compact args list. Every sentence adds value, and the formatting improves scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description adequately covers the main usage and parameters. It could be more explicit about what 'full detail' includes and error handling, but it's sufficient 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions, but the description explains name as the service name across three proxy formats and clarifies the optional target and its default behavior. This fully compensates for the schema's lack of semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'One service/backend's full detail by name', with a specific verb and resource. It also references 'from list_services', distinguishing it from listing tools. This clearly distinguishes it from siblings like list_services or route_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs that names come from 'list_services', implying a workflow order. It doesn't explicitly name alternatives or exclusions, but the sibling context and 'full detail' scope make the use case clear. A brief mention of when not to use it would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly marks the tool as '[READ]' and describes the matching behavior ('static match, best first'), which are useful behavioral cues. However, with no annotations, it doesn't fully disclose return format, error handling, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main purpose, and uses a clear argument list. Every sentence contributes critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's function and parameters, but with no output schema it fails to state what the function returns (e.g., route names, details, ordering). It also doesn't mention potential failure modes or how 'best first' is determined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all three parameters with examples and defaults: host as hostname, path defaulting to '/', and target as proxy target from config. This provides essential semantic information beyond the schema's bare types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Which routes would serve a host/path' clearly identifies the tool's function as a host/path-to-route matcher. The additional '(static match, best first)' distinguishes it from sibling tools like list_routes or route_detail that merely enumerate or describe routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose clear, implying an agent should use it whenever it needs to resolve a request to a route. However, it doesn't explicitly contrast with sibling tools like list_routes or route_conflict_analysis, missing an opportunity to provide explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden. The [READ] prefix signals a non-mutating operation, and the field list discloses the output shape, but it does not mention data freshness, error cases, or permissions, leaving some behavioral transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear header, useful output spec, and brief parameter notes. Every sentence adds value and the structure is scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with two optional parameters and no output schema, the description fully covers the essential information: what it returns, how to filter, and its relationship to backend_health_rca. It is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explains both parameters clearly, defining service as an optional filter and target as a proxy target name with a default behavior. This adds significant meaning over the bare schema, which only provides names and null defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with '[READ] Server-level upstream health rows' and enumerates the fields returned, clearly identifying the resource and scope. It also states it feeds backend_health_rca, which helps distinguish it from related list tools like list_services or list_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that this is a health-row listing and mentions optional filters for service and target, implying when to use it. However, it does not explicitly contrast with siblings like upstream_detail or backend_health_rca, so usage guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states '[READ]' and 'statically finds,' indicating a read-only analysis, and describes fetching the route table and service list. It also discloses the output dict keys and explains that each finding names the covering route or missing service. Missing details like rate limits or failure modes prevent a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose ('Shadowed routes, dead routes, and redirect loops') before going into parameter details. The 'Args:' section is organized and the return format is listed succinctly. It is longer than necessary, but each section adds value and there is no wasted repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing three types of routing issues), no output schema, and no annotations, the description provides a substantial amount of context: it covers the three finding categories, the parameter structures, and the return dictionary keys. It does not mention edge cases or error conditions, so it is not fully complete, but it is adequate for an agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully compensate. It does this thoroughly: routes expects rows with fields {name, hosts, paths, priority, service, enabled, redirectTo}, services expects {name, serversTotal, serversUp}, and target is explained with 'omit for the default.' This gives complete semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '[READ] Shadowed routes, dead routes, and redirect loops (static)' and then elaborates as 'The flagship routing hygiene analysis' that finds three specific types of routing problems. This clearly states what the tool does and distinguishes it from sibling tools like list_routes or route_detail, which merely retrieve route information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it can fetch the route table and service list, or accept injected routes/services for pure analysis. It explains the optional target parameter and its default behavior. However, it does not explicitly compare itself to alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full transparency burden. It discloses that the tool live-probes domains with a bounded handshake, performs storage/ACME checks, and returns a detailed dictionary with specific keys. This goes well beyond a typical description, though it stops short of mentioning potential network side effects or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, Args, and Returns sections. It is fairly long but every sentence adds value, and the front-loaded summary gives a quick grasp. Minor verbosity in the haproxy note could be trimmed, but it is not wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is remarkably complete. It documents all parameters, return keys (certsEvaluated, expired, critical, warning, ok, unknown, certificates, thresholds, renewalHint, note), special modes, and platform-specific behaviors. An agent has everything needed to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero per-property descriptions, but the description's Args section fully explains every parameter (warn_days, critical_days, port, certs, target) with defaults and semantics. This completely compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: collecting TLS domain inventory, live-probing served certificates, and bucketing by expiry. It distinguishes itself from siblings like list_certificates by emphasizing it's the 'flagship cert sweep' with renewal hints and expiry thresholds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool, including intended targets (traefik/caddy/haproxy), a 'certs' mode for pure analysis, and a note about haproxy's teaching note. However, it does not explicitly contrast with list_certificates or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It starts with '[READ]' and explains the haproxy special case and the optional bounded handshake probe, which is useful context. It doesn't mention potential performance implications of probing or return format, but it discloses the key behavioral differences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a summary sentence, a special-case note, and a clear Args section with three bullets. Every sentence adds information, and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional params and no output schema, the description covers the tool's purpose, special cases, and all parameter semantics. It doesn't describe the return format or error scenarios, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only titles and defaults, so the description's Args section is essential. It explains each parameter with meaningful detail: probe triggers a bounded handshake, port specifies the TLS port, and target selects the proxy target. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists TLS domain inventory for a traefik/caddy target, with an optional probe for live expiry. The verb 'list' and resource 'certificates' are explicit, and it distinguishes itself from siblings like cert_expiry_sweep by focusing on inventory listing rather than a sweep action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates when to use the tool: for TLS domain inventory in traefik/caddy, and notes a haproxy-specific behavior. It doesn't explicitly mention alternatives, but the context is clear enough to infer its usage. However, there are no exclusions or mentions of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the [READ] nature, per-proxy endpoint behavior, and the caddy 'teaching note' exception. It does not detail return format or error conditions, but for a simple version-info tool, this is adequate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with '[READ] Version / build info.' Each sentence earns its place: purpose, proxy-specific endpoint details, caddy exception, and parameter explanation. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter tool with no output schema, the description covers purpose, behavioral nuances, and parameter semantics fully. It gives enough context for an agent to select and invoke it correctly, including the caddy edge case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter with 0% schema-level description coverage, so the description must compensate. It explains that 'target' is a proxy target name from config and 'omit for the default,' which adds meaningful usage detail beyond the raw schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches version/build info, identifies the exact proxy endpoints (traefik /api/version, haproxy /v2/info), and includes a specific note about caddy's lack of a version endpoint. This distinguishes it from the config/routing-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that this is a read operation for version/build info and listing endpoint differences per proxy. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, though the purpose itself strongly implies its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it is a read operation ('[READ]'), mentions live pulling vs. injected data, and describes the classification and action output. While it doesn't discuss error handling or side effects, it is a thorough disclosure for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: a one-line summary, then a detailed explanation, followed by an Args section and a Returns section. Every sentence adds value, and the length is justified given the lack of schema descriptions and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 3 optional params, no annotations, and no output schema. The description compensates fully by explaining the return dict structure, parameter semantics, and behavior. It is complete enough to invoke correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so excellently by explaining each parameter: service as an optional filter, upstreams as injected rows with a specific format and semantics (skips live pull), and target as a proxy target name with default behavior. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Down upstreams grouped per service, each mapped to cause + action.' It uses specific verbs (pulls, groups, classifies) and resource (server-level upstream health), and distinguishes itself as the 'flagship availability RCA' among sibling diagnostic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for availability RCA, and explains two modes—pass 'upstreams' for pure analysis or a target to pull live. It doesn't explicitly name alternatives or exclusions, but the 'flagship' positioning implies primary use for this scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly labels the operation as [READ], describes case-insensitive substring matching, and explains the envelope's truncation field, warning that truncated results are incomplete. It stops short of specifying edge cases like empty matches but overall is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but well-structured: purpose, args, return envelope, and a caveat about truncation. Each sentence adds value, and the most critical information (purpose and truncation warning) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fully explains return values via the envelope example, including truncation semantics. It covers parameter meaning, default behavior for target, and usage context. This is a complete, self-contained description for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does: 'query' is described as a case-insensitive substring over keys and values, and 'target' is explained as a proxy target name with 'omit for the default'. This adds meaning far beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Search the config tree for a string; returns matching config paths'. It clearly distinguishes itself from siblings like get_config_value (which fetches a specific value) by emphasizing it returns paths usable by get/set_config_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it's for locating config paths, applicable to Caddy, and the results are directly usable by get/set_config_value. It also advises narrowing the query when truncated. However, it does not explicitly state when not to use this tool or name direct alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it is a WRITE operation with risk=medium, reversible via a fetched prior weight, weight 0 stops traffic without state change, and dry_run preview exists. This exceeds the minimal expected disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but each sentence carries useful information. The args list is clearly structured, and the note about traefik/caddy, while niche, is still relevant. It could be trimmed slightly, but overall it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no annotations and no output schema, the description covers all parameters, side effects, reversibility, and a preview mechanism. The only minor gap is not stating what the tool returns after execution, but this is largely inferable from the operation type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining each parameter: backend from list_services, server from list_upstreams, weight range 0-256, dry_run for preview, and target with default behavior. This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and the resource ('an haproxy server's load-balancing weight') with a specific range (0-256). This distinguishes it from siblings like set_server_state, which handles server state rather than weight.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use: references list_services and list_upstreams as sources for parameters, and notes the dry_run preview option. It does not explicitly name alternative tools, but the distinction from set_server_state is implied by the different resource being modified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it snapshots prior config for reversibility, refuses unsafe admin API changes, and applies refusal even during dry_run. These nuances go well beyond basic write semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the purpose, then behavior, then parameters. Every sentence provides value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high-risk nature, no annotations, and no output schema, the description covers purpose, safety, reversibility, dry-run behavior, and parameter semantics thoroughly. It is sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the Args section adds clear meaning: config is the full JSON tree, dry_run previews without loading, and target is the proxy target with an 'omit for default' hint. This gives practical usage context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Replace caddy's FULL running config' with a specific verb and resource, and distinguishes itself from sibling tools like set_config_value or get_config_value by emphasizing it replaces the entire config. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on using dry_run for preview and warns about refusal conditions for admin API changes. However, it does not explicitly name alternatives for partial config updates, only implying this tool is for full replacement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is a write operation with medium risk, reversible (fetches prior state for undo), explains the effect of each state, and notes a specific error case. It also suggests dry_run to preview, covering safety and 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the [WRITE][risk=medium] label and the core purpose in the first sentence. It then breaks down state semantics, error context, and a dry_run tip, followed by a clean arg list. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, state meanings, reversibility, error conditions, and parameter semantics thoroughly. It omits details such as the exact return value or whether changes persist across reloads, but these are minor for a set-operation tool and partially offset by the dry_run option.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description independently documents all five parameters. It explains the source of backend/server (from other tools), allowed values for state, the meaning of dry_run, and the target's default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Set an haproxy server's admin state (ready / drain / maint)'. It clearly distinguishes from siblings like set_server_weight by focusing on admin state rather than weight, and the state values are explicitly listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each state (drain finishes in-flight, maint removes immediately, ready re-rotates) and warns that traefik/caddy are not supported. It lacks explicit alternatives or when-not-to-use relative to sibling tools, but the state semantics provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses key behaviors: the operation is reversible, the subtree is captured first, dry_run previews, and it refuses the 'admin' subtree and config root with a clear safety rationale. This is thorough and goes beyond typical descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary, a dry-run note, a safety/refusal explanation, and a brief Args list. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description fully equips an agent to understand what the tool does, how to invoke it safely, and what to expect. It covers purpose, behavior, and all parameters completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions, so the description's parameter explanations are essential. It clearly defines path as slash-separated, dry_run as preview, and target as an optional proxy name – adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Delete a caddy config subtree' – a specific verb and resource. It also notes reversibility and distinguishes it from sibling tools that set or load config values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (to delete a config subtree) and mentions dry_run for preview. It does not explicitly name alternative tools or state when not to use it, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently declares the [READ] nature, discloses the parsing sources and the truncation behavior when 'truncated' is true. This goes beyond basic schema info and gives users essential behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for summary, proxy-specific notes, args, and return envelope. Every sentence adds value, and it remains concise while being detailed enough for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return envelope clearly, including the meaning of 'truncated'. It also covers the argument and proxy-specific behaviors, making it complete for a simple read tool with one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'target' has zero schema description coverage, but the description compensates fully by explaining it as 'Proxy target name from config; omit for the default.' This provides clear meaning and default behavior that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides per-service request/status-code counters and even distinguishes itself by noting it feeds error_rate_rca. The verb is specific and the resource (service counters) is precisely defined, also covering proxy-specific differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context (feeds error_rate_rca) and explains proxy-specific capabilities/limitations (traefik per-code, haproxy per-class, caddy no per-route counters). However, it does not explicitly state when not to use it or name alternative tools like traffic_stats, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior. It explains the data sources (traefik/metrics, haproxy stats), the threshold logic, the cause mapping for different status codes, and the impact of passing 'counters' to skip live pulls. It also notes the specific behavior for caddy targets, providing rich behavioral context beyond a simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, detailed behavior, argument explanations, and return schema. It is appropriately sized for a complex tool; every sentence adds value, and it front-loads the core purpose before diving into specifics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description is exceptionally complete. It explains the return dict structure with all fields, covers edge cases (caddy, counters mode), and describes the algorithm. There is no significant missing information that would leave an agent uncertain about invocation or interpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description compensates fully with an 'Args' section that explains each parameter's meaning, default values, and usage. For example, it defines error_rate_pct as the threshold for flagging, min_requests as the minimum traffic, counters as injected rows, and target as the proxy name. This adds substantial meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: ranks services by 5xx share vs the fleet baseline, identifies causes, and suggests actions. It uses specific verbs like 'rank', 'flags', and 'maps', and distinguishes itself from siblings such as error_counters by emphasizing it is the 'flagship error RCA' and providing detailed cause mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool by explaining its core function and noting special modes like passing 'counters' for pure analysis or handling caddy targets differently. However, it does not explicitly compare itself to alternatives such as backend_health_rca or error_counters, so it lacks explicit when-not guidance, placing it slightly below a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It discloses the write nature and risk level, states that execution is audited under its own risk tier, and mentions the one-time-use constraint and dry-run preview capability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and uses a brief Args list to efficiently document each parameter. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description fully equips an agent to decide when to use the tool, how the undo executes, what parameters mean, and what constraints apply (one-time, dry-run, audit).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters, and it does. It defines undo_id's source, dry_run's purpose, and target's passthrough behavior, adding meaning beyond the bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Apply a recorded undo') and the mechanism ('dispatching its inverse tool'). It distinguishes this from the sibling undo_list tool by focusing on executing an already-recorded undo rather than listing or creating them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance: obtain undo_id from undo_list or _undo_id, use dry_run=True to preview, and expect the undo to be consumable only once. It does not explicitly name when not to use it versus other tools, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses that truncated is measured by fetching an extra row, not guessed, and that effectVerified=false means the inverse operation is only probable and should be checked against live state. This is substantive behavior beyond basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear first sentence stating purpose, then flows into return format details and parameter docs. Every sentence earns its place; it is slightly long but dense with necessary information and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though there is no output schema, the description explains the exact return shape and the meaning of the key fields (truncated, effectVerified). It covers parameter behavior and provides enough detail to use the tool correctly and interpret results confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero coverage, so the description fully compensates by explaining both parameters: limit has a default, a cap, and controls returned rows; target is explicitly noted as unused but accepted for CLI uniformity. This removes any ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('recorded, not-yet-applied undo tokens'), and clarifies the most-recent-first ordering. It also distinguishes itself from the sibling tool 'undo_apply' by explaining that the returned undoId is intended for that tool, making its role as a listing counterpart clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for listing undo tokens before applying them, and explicitly instructs using the undoId with undo_apply. It also advises re-running with a higher limit when truncated is true. It does not explicitly name an alternative for exclusion, but the usage guidance is otherwise strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that changes apply immediately, are reversible (undo restores prior subtree), and that admin subtree is refused, even under dry_run. This goes well beyond the raw schema and compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The format is front-loaded with a clear summary, then behavior, then refusal, then a clean Args list. No filler; each sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations or output schema, the description covers purpose, caveats, parameter semantics, and error behavior (refusal reporting). It is complete 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates: it explains path (slash-separated, example), value (JSON), insert (insert vs replace with rationale), dry_run (preview), and target (proxy target name, default omitted).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '[WRITE] Set a caddy config subtree' providing a specific verb and resource, with an example (route's upstreams). It distinguishes itself from sibling read/delete/load tools by framing the action as a reversible write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that paths come from search_config/list_routes, that this is inappropriate on traefik/haproxy ('raises the support matrix's teaching error'), and that the admin subtree must be modified in caddy's own config file instead. It also explains when to use insert (re-creating a deleted array element).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AIops-tools/Proxy-AIops'
If you have feedback or need assistance with the MCP directory API, please join our Discord server