Sophos Firewall MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool addresses a distinct resource and action (e.g., list, get, create, update, delete) with clear separation. Potential overlaps like list vs get firewall rules are resolved by naming and description. No two tools could be easily confused.
Naming Consistency5/5
All tools follow a consistent 'sophos_<action>_<resource>' snake_case pattern. The two routing tools deviate slightly but are justified by their different role. Overall, naming is predictable and uniform.
Tool Count4/5
41 tools is large but the Sophos Firewall domain covers many resources (firewall rules, hosts, services, NAT, VPN, users, etc.) with full CRUD on most. The count is high but each tool serves a distinct purpose; a few could potentially be consolidated.
Completeness3/5
Major resources like firewall rules, NAT, and users have good lifecycle coverage, but IP hosts, FQDN hosts, services, groups, and VPNs lack update operations. This forces agents to delete and recreate for modifications, which is a notable gap.
Average 4.1/5 across 41 of 41 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- Last stable release on July 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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 indicate readOnlyHint: false, implying mutability. The description adds no behavioral context beyond executing a tool—fails to disclose risks, potential side effects from arbitrary tool calls, or that it can invoke destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses a structured docstring format (Args, Returns). It is front-loaded with the main purpose. The Returns section adds minor redundancy but is useful given no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic mechanics but omits important context: that it can call any registered tool (a meta-tool), the need for proper tool registration, and potential security concerns. The mention of return type is vague but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds clear meaning to both parameters beyond the schema: 'tool_name' as the registered tool to call, and 'arguments' as an optional dictionary. Since schema description coverage is 0%, the description compensates effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Dynamically execute a routed tool by name with arguments.' It distinguishes itself from sibling tools by being a meta-tool for dynamic invocation, while siblings are specific Sophos tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., direct tool calls or the 'route_tools' sibling). The description lacks context on prerequisites, security implications, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no additional behavioral details such as what happens if the user does not exist, whether deletion is reversible, or any 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose line, usage note, parameter list, and return value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic purpose and usage but lacks details on error handling, idempotency behavior, and permissions. Given the presence of an output schema and annotations, it is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; the description adds some context for the 'client' parameter ('Optional SophosFirewallClient instance'), but the meaning of 'client' remains vague. The 'username' parameter description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a local user account by username.' The verb 'delete' and resource 'local user account' are specific. This distinguishes it from sibling tools like create_user or list_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use when removing obsolete or revoked user accounts from Sophos Firewall.' It does not mention alternatives or when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds no behavioral details beyond the creation action. No contradiction, but fails to add context like whether creating a duplicate is idempotent or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line purpose, one-line usage advice, then Args and Returns sections. No wasted words. Well-structured with clear separation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and parameters. Output schema exists (API response status dictionary), so return values are handled. Missing behavioral nuances like handling existing groups, but adequate for a simple creation tool with annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 params described). The description repeats schema descriptions for name and host_list, adding no new meaning. The client param is not in schema but description clarifies 'Optional SophosFirewallClient instance', adding slight value. Overall baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create an IP host group containing multiple IP host objects'. Verb (create) and resource (IP host group) are specific. Distinguishes from siblings like sophos_create_ip_host (individual host) and sophos_list_ip_host_groups (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'bundling multiple IP host objects together for unified security policies'. Does not mention when not to use or alternatives, but the context from siblings is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description confirms deletion. Beyond that, no additional behavioral context is provided (e.g., irreversibility, permissions, or side effects). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-liner, usage sentence, and clear Args/Returns sections. It is concise but slightly redundant (usage sentence could merge with action). No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool type (delete) and presence of annotations and output schema, the description is adequate but leaves out prerequisites (e.g., service group must exist) and error conditions. The usage guidance is minimal. Completeness is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only name has a description). The description adds value by documenting the optional client parameter as 'Optional SophosFirewallClient instance', which the schema lacks. It also restates the name parameter's purpose, adding no new info but maintaining clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete), the resource (service group), and the identifier (by name). It distinguishes from sibling tools like sophos_delete_service and sophos_delete_ip_host_group by specifying 'service group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage sentence: 'Use when removing an obsolete service group definition from Sophos Firewall.' This provides context but does not mention when not to use the tool or suggest alternatives (e.g., listing first). No exclusions are stated.
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 declare readOnlyHint=true, so the read-only nature is already known. The description adds that it returns a list or dict, which is basic. It does not disclose pagination, rate limits, or whether the call retrieves all groups without a filter. Given the annotation, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences upfront plus structured Args/Returns. Every sentence serves a purpose, and it is front-loaded with the main action. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with optional filter, the description covers purpose, usage context, and return type. It omits details like default behavior (lists all groups) or pagination, but an output schema exists to provide structure. Slightly more completeness would be ideal, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only name has schema description). The description matches the schema for name and adds a description for client ('Optional SophosFirewallClient instance'), which was missing in the schema. However, it does not explain how client affects behavior or provide examples. At 50% coverage, the description compensates minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List IP host groups configured on Sophos Firewall', which is a specific verb (List) and resource (IP host groups). This distinguishes it from sibling tools like sophos_list_ip_hosts (individual hosts) and sophos_create_ip_host_group (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: 'Use when viewing grouped IP host definitions used in rule sets.' However, it does not explicitly state when not to use it or mention alternatives like sophos_list_ip_hosts for individual hosts. The usage is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, and the description adds nothing beyond 'List' to indicate safety. There is no mention of side effects, required permissions, or rate limits. The description adds minimal behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for purpose, one for usage, then Args and Returns. Every element earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list operation), presence of output schema, and readOnlyHint annotation, the description covers the key aspects: what it lists, when to use it, and parameter details. Minor gaps like pagination or default behavior are acceptable for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (client parameter undescribed). The description adds some meaning: for username, it repeats 'Optional username filter'; for client, it says 'Optional SophosFirewallClient instance.' This adds value but does not fully compensate for the missing schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List local user accounts configured on Sophos Firewall,' using a specific verb and resource. It distinguishes from siblings like 'sophos_list_live_users' by specifying 'local' users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when browsing local user accounts and group memberships,' providing clear context. It implicitly distinguishes from live users via the 'local' qualifier but lacks explicit when-not-to-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds that it updates fields and returns an API response status dictionary, but does not disclose additional behavioral traits beyond what annotations and schema already convey. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose line, usage line, parameter list, and return type. However, it is somewhat lengthy due to the repetitive Args section, which could be trimmed. It is adequate but not exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 1 required, and an output schema present, the description provides a clear purpose, usage guidance, and return description ('API response status dictionary'). It is reasonably complete, though it could briefly mention the relationship to sophos_update_firewall_rule_status for further clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (90%), so baseline is 3. The description's Args section repeats parameter info largely matching the schema, adding little extra meaning. It does not provide examples or clarifications beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates configuration fields on an existing firewall rule, using a specific verb and resource. It lists what can be modified (logging, action, zones, etc.), distinguishing it from siblings like sophos_create_firewall_rule, sophos_delete_firewall_rule, and sophos_update_firewall_rule_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool: 'Use when modifying parameters such as logging, action, zones, host objects, or status on an existing security policy.' It provides context but does not explicitly exclude cases where it should not be used or mention alternatives, though the sibling list implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only, not idempotent, and not destructive. The description adds that it creates a rule and returns a status dictionary, which is helpful but does not disclose potential side effects (e.g., if dependencies like zones or networks don't exist, the creation might fail). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, one for usage, a clear Args list, and a Returns line. Every part is useful and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic usage and return type, but given the complexity of creating a rule that references many existing objects (zones, networks, services), it lacks prerequisites and error scenarios. For example, it doesn't warn that referenced objects must exist. Still adequate for a tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 89%, so the schema already documents most parameters. The description's Args section adds examples (e.g., ['LAN'], ['Any']) that are not in the schema, and clarifies defaults. This adds practical value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new IPv4 firewall security rule.' which is a specific verb+resource. It distinguishes from siblings like sophos_update_firewall_rule and sophos_delete_firewall_rule by indicating use for new rules. The second sentence adds context about usage for network access control policies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when defining new network access control policies between zones and host objects.' which provides some guidance, but it does not explicitly state when not to use this tool or mention alternatives like updating or deleting rules. The guidance is implicit given sibling tool names, but not direct.
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 indicate not readOnly, not idempotent, not destructive. The description adds that it creates a rule and returns a status dictionary, but does not disclose potential failure conditions or prerequisites beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, use-case, argument list, and return info. It is concise but could be slightly shorter by removing redundant parameter details already in schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, use cases, parameters, and return format. With high schema coverage and annotations, it is fairly complete. Missing details about uniqueness constraints or error handling are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 89%, so the schema already documents most parameters. The description lists parameters with brief descriptions, adding minimal extra value (e.g., default values). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates NAT/DNAT rules and lists specific use cases (port forwarding, SNAT, DNAT). This distinguishes it from sibling tools like sophos_list_nat_rules or sophos_get_nat_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when defining port forwarding, SNAT masquerading, or DNAT inbound translation rules', providing clear context. However, it does not mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint and idempotentHint, and the description adds minimal extra behavioral context. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short, front-loaded, and focused; every sentence adds value without repetition of schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers purpose and usage but lacks details on idempotency, prerequisites, and return value specifics despite output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the description adds 'Optional SophosFirewallClient' for the client parameter but doesn't explain its purpose or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it deletes an FQDN host object by name, distinguishing it from siblings like sophos_delete_ip_host.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when deleting domain-based host objects', providing context but not excluding alternatives or detailing when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds no further behavioral traits (e.g., authentication needs, rate limits) beyond listing what data is retrieved, which is consistent with the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three short paragraphs plus an args/returns note. It is front-loaded with the main purpose and well-structured without any redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with an output schema, the description covers purpose, usage context, parameter (minimally), and return type. However, the parameter documentation is weak, and there is no mention of prerequisites or authentication, but overall it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'client' is described as 'Optional SophosFirewallClient instance' with no further details. Schema coverage is 0%, and the description fails to explain how the parameter affects behavior or provide usage details beyond its optionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves system information including specific attributes like appliance model, firmware version, serial number, and uptime. It also explicitly states when to use it, which distinguishes it from siblings that focus on other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use when inspecting hardware/firmware details and overall system status.' Although it does not explicitly mention when not to use or name alternatives, the context is sufficient to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds the return type (list/dict) and briefly mentions the service types. No further behavioral details (e.g., pagination, limits) are given, but the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with separate sections for purpose, usage, args, and returns. Every sentence adds value and is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with a simple input schema and an output schema present, the description adequately covers the core functionality and usage context. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; only the 'name' parameter has a schema description. The tool description restates the name filter but adds no details for the 'client' parameter, which remains undocumented. The description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists service objects including TCP, UDP, ICMP, and IP protocol definitions. This verb+resource pairing is specific and distinguishes it from sibling tools like sophos_list_ip_hosts or sophos_list_firewall_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use 'when inspecting custom or predefined port and protocol definitions.' While it doesn't mention alternatives, the context is clear for a simple read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat that. However, it does not disclose any additional behavioral traits such as required permissions, pagination, or error handling. With annotations covering the safety profile, the description adds minimal extra context, meriting a score of 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and includes a brief Args/Returns section. It is fairly concise but could be more streamlined by removing the redundant 'Returns:' line. Overall, it is well-structured and avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema that likely documents return values, the description is adequate. It covers the tool's purpose, usage context, and parameter type. The output schema handles return value details, so the description does not need to elaborate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'client' parameter. The description states it is an optional SophosFirewallClient instance, adding some meaning beyond the schema. However, it does not explain the parameter's purpose or how it affects the function, providing only a basic type and optionality note. This partially compensates for the low schema coverage but remains minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List SSL VPN remote access policies configured on Sophos Firewall.' It uses a specific verb ('List') and identifies the exact resource (SSL VPN remote access policies), distinguishing it from sibling tools like sophos_list_ipsec_vpns and other list 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use when viewing user access policies, SSL VPN IP pools, and permitted networks.' While it doesn't mention when not to use or alternative tools, the guidance is clear and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds that operations can be 'Get', 'Set', or 'Remove', but does not elaborate on the consequences of Set or Remove beyond what the annotations imply. It provides basic transparency without deep behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded purpose statement and a structured Args list. Every sentence serves a purpose, and there is no fluff. Slightly more compact than average, hence a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description adequately covers the tool's role, parameters, and usage context. It lacks examples or explicit warnings about destructive actions, but overall it provides sufficient information for a low-level API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description's Args section repeats information already in the schema (operation types, tag example, params purpose). It adds no new semantics beyond reinforcing the schema's descriptions, so it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute a low-level, generic Sophos Firewall XML API operation.' It specifies that it is for custom or low-level calls not supported by dedicated high-level tools, distinguishing it from the many sibling tools that handle specific entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool when dedicated high-level tools do not support the required tag or configuration, implying when not to use it. While it does not list specific alternatives, the sibling list provides context, and the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that it enables/disables, which aligns, but offers no additional behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but includes an 'Args' section that somewhat duplicates the schema. However, it is still efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (toggle a rule status) and the presence of an output schema, the description covers purpose, use case, and parameters adequately. It is complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats schema descriptions for name and status, and clarifies client is optional. With 67% schema coverage, this adds marginal value but does not enhance understanding beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Enable or disable' and the resource 'existing firewall rule', and distinguishes from sibling tools like sophos_update_firewall_rule which likely modifies other properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives specific use case 'Use when toggling a security policy active state without deleting the rule', providing clear context for when to apply this tool.
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 indicate the tool is not read-only, idempotent, or destructive, but the description adds that it 'returns API response status dictionary.' No further behaviors (e.g., duplicate handling, auth requirements) are disclosed, so the description provides only marginal added value beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, beginning with a clear purpose statement, followed by usage guidance, parameter list, and return info, all within a few bullet points. Every sentence contributes essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, the description covers key aspects: purpose, usage, all parameters with defaults and examples, and return value. An output schema exists, so the return description suffices. Minor missing elements like error handling or duplicate behavior prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the description's parameter section largely duplicates the schema. However, it adds useful examples for destination_port (e.g., '8080' or '8000:8080') and clarifies the client parameter as 'Optional SophosFirewallClient instance,' which are beyond the schema. The added value is moderate, not transformative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a custom TCP/UDP service definition,' which clearly identifies the action (create) and the resource (service definition). Among siblings like sophos_list_services or sophos_delete_service, this tool is uniquely the creation one, making the purpose distinct and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when adding new port or protocol definitions for firewall rules,' providing clear context for when to invoke the tool. However, it does not mention when not to use it or list alternatives, so it lacks exclusions needed for a perfect score.
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 indicate destructiveHint=false, but the description confirms it is a create operation without disclosing details like idempotency or error handling. It does mention the return type ('API response status dictionary'), adding some transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose statement, usage context, and parameter descriptions. It is front-loaded and contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of the tool (3 parameters, 2 required) and the presence of an output schema, the description covers purpose, usage, parameters, and return type. It is complete enough for an agent to invoke correctly, though it could mention behavior on duplicate names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%. The description repeats schema descriptions for 'name' and 'service_list' but adds value by explaining the 'client' parameter as an optional SophosFirewallClient instance, which is not described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new service group object.' and explains it bundles service port definitions into a named group for security rules. This distinguishes it from sibling tools like sophos_create_service which creates individual services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when bundling multiple service port definitions into a single named group for security rules.' This provides clear context for when to use it, though it does not explicitly state when not to use it or mention alternatives.
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 standard (readOnlyHint false, destructiveHint false). Description discloses the operation (create) but lacks details on side effects, error scenarios, or permissions. The return value is only vaguely described as 'API response status dictionary.' Could be more informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-structured: one purpose sentence, then Args list, then Returns. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers the create operation with required parameters and usage context. Given the presence of an output schema (not detailed in input), the return description is sufficient but generic. Could include more on group name format or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so the schema already documents most parameters. The description's Args section adds minimal new info (e.g., default group, optional email) but is largely redundant with the schema. The 'client' parameter lacks description in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new local user account on Sophos Firewall' with specific verb and resource. Distinguishes from sibling tools like sophos_list_users, sophos_delete_user, and sophos_get_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context: 'Use when registering new local user accounts for VPN or portal access.' Does not specify when not to use or list alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that it returns a list or dict, but does not disclose additional behavioral aspects like authorization or rate limits. Since annotations cover safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus Args/Returns sections, all front-loaded and without extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple list operation with one optional parameter, the description covers purpose, usage, parameter, and return values. Output schema exists, so return documentation is not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the 'client' parameter as an optional SophosFirewallClient instance, adding meaning beyond the schema. However, it does not describe default behavior or impact, so improvement is possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists network interfaces with specific details (configuration, IP addresses, zones, link state). It uses a specific verb and resource, and no sibling tool overlaps with this purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when inspecting physical or virtual interface configurations, subnets, and link states.' This provides clear context, but does not mention when not to use it or alternatives, though siblings are distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description aligns by stating 'Retrieve details,' confirming it is a read-only operation. No additional behavioral traits beyond annotations are provided, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose statement, usage guidance, and structured Args/Returns sections. Every sentence adds value, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with an output schema and thorough annotations. The description covers purpose, usage, parameters, and return value adequately with no missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. The description's Args section adds meaning for the client parameter ('Optional SophosFirewallClient instance'), which the schema does not describe. For the name parameter, it largely repeats the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve details of a specific service definition' with a specific verb and resource. It distinguishes from sibling tools like sophos_list_services (which lists all services) and sophos_create_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage: 'Use when verifying target port ranges or protocol parameters for a service.' This provides clear context for when to invoke the tool.
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 include readOnlyHint: true, which is consistent with the 'list' operation. The description does not add behavioral traits beyond what annotations provide, such as idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-sentence purpose and a structured docstring for parameters and returns. Every sentence is useful and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description covers purpose, usage context, and parameters adequately. It does not need to explain return values as the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (name has description, client does not). The description repeats the schema's description for 'name' without adding new meaning. No compensation for the undocumented 'client' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List NAT and DNAT port-forwarding rules on Sophos Firewall,' which is a specific verb and resource. It distinguishes from sibling tools like sophos_get_nat_rule (single rule) and sophos_create_nat_rule (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Use when reviewing Network Address Translation rules and port forwarding,' providing clear context for when to use. However, it does not explicitly exclude alternatives or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds that the tool lists objects and can filter by name, but does not disclose other behavioral aspects like pagination or rate limits. With annotations covering safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a few sentences plus a structured docstring (Args/Returns). It is front-loaded with the purpose and usage context. Minor verbosity in the docstring could be trimmed, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the return description is adequate. The tool is simple with two optional params, and the description covers purpose and when to use. It could include more detail on client usage or response format, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (name has description, client does not). The description adds meaning for both parameters, especially client ('Optional SophosFirewallClient instance'), which is missing from schema. However, the client parameter type is still vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List service group objects configured on Sophos Firewall', specifying verb and resource. This distinguishes it from sibling tools like sophos_list_services (individual services) and sophos_list_ip_host_groups (IP host groups).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool: 'Use when browsing bundled groups of services used in rule policies.' This helps an agent decide, though it does not explicitly mention when not to use or list alternatives.
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 states that the tool creates an object and returns a status dictionary, but does not specify error handling, behavior on duplicate names, or authentication requirements. Annotations provide no additional safety or behavioral hints, so the description carries the full burden and only partially covers it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary action and resource, followed by a one-line usage context, then structured parameter list, and returns summary. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers creation, usage, parameters, and return value adequately. It lacks details on uniqueness constraints or error conditions, but these are minor for a straightforward create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the input schema by explaining the 'client' parameter (optional instance), which is missing from the schema description. For 'name' and 'fqdn', the description largely repeats schema descriptions, but the overall coverage is improved to near complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'FQDN host object', distinguishing it clearly from sibling tools like sophos_create_ip_host by specifying the object type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case ('when defining domain name target objects for firewall or NAT rules'), giving context for when to use this tool. It does not explicitly exclude alternatives, but the context is clear enough for an AI agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it creates an object but does not disclose behavioral details such as idempotency (per hint false), authentication requirements, or rate limits. The output schema is mentioned but not detailed. This is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a primary statement, usage guidance, and an Args/Returns section. It is front-loaded with the key purpose. However, the Args section somewhat redundantly repeats schema information, making it slightly less concise than optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (1 required), high schema coverage (83%), and an output schema, the description covers all essential aspects. It explains when to use the tool, parameter details, and the return type. No critical information is missing for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so baseline is 3. The description adds value by providing examples for parameters like subnet_mask ('e.g. 255.255.255.0' or '24') and explaining host_type options. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new IP host object, listing specific types (IP, Network, IP Range, IP List). This distinguishes it from the sibling tool sophos_create_fqdn_host, which handles FQDN hosts. The verb 'create' and resource 'IP host' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage line: 'Use when registering host IP or network subnet definitions for firewall policies.' This provides context, though it does not explicitly state when not to use it. Given siblings like sophos_create_fqdn_host, the differentiation is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and idempotentHint=true, covering the safety profile. The description adds that deletion is by name and returns a status dictionary, which is consistent but does not add significant new behavioral context beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using 8 lines including structured Args and Returns sections. Every sentence is informative, with no redundancy or fluff. It is well front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters, output schema exists), the description covers purpose, usage context, parameters, and return value. It could mention idempotent behavior or error handling, but annotations and output schema fill some gaps. Overall adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'name' is described in schema). The description compensates by providing clear explanations for both parameters: 'name' and 'client', adding meaning beyond the schema for the undocumented 'client' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an IP host object by name', specifying the verb and resource. It distinguishes from sibling tools like sophos_delete_fqdn_host and sophos_delete_ip_host_group by the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when deleting unused IP host objects from the firewall database', providing a specific context for when to use the tool. It implicitly advises against deleting objects that are in use, though it does not name alternative tools for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds no new behavioral context beyond aligning with these. With annotations covering safety, this is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three short paragraphs for purpose, usage, and args/return. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool, the description covers usage, parameters, and return type. Output schema likely details return structure. Siblings provide context. Could mention error handling or prerequisites, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only name described). The description adds meaning by explicitly listing both parameters and their roles, especially clarifying the optional client parameter as 'Optional SophosFirewallClient instance', compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Delete a custom service definition object by name.' The verb 'delete' and the specific resource 'custom service definition object' are precise, distinguishing it from siblings like sophos_list_services or sophos_create_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when deleting obsolete service port definitions from Sophos Firewall,' providing a clear context. Does not mention alternatives or when not to use, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'Retrieve' aligns. No additional behavioral traits (e.g., error handling, permissions) are disclosed, but annotations cover the safety aspect sufficiently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences cover purpose, usage, and parameter definitions. No unnecessary words, and the most important info appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is complete enough. It covers the essential aspects: what, when, and parameters. Minor gap: no mention of behavior when rule not found, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The name parameter's description in both schema and description is redundant, but the client parameter lacks a schema description and the description adds 'Optional SophosFirewallClient instance', providing needed clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Retrieve details for a specific firewall rule by name', which is a clear verb+resource pairing. It distinguishes from sibling tools like list, create, update, and delete rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case: 'Use when inspecting full policy configuration for a single firewall rule.' Though it doesn't explicitly mention alternatives, the sibling set implies when not to use (e.g., for listing use list_firewall_rules).
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 aligns with the readOnlyHint annotation by using 'Retrieve,' indicating no side effects. It adds value by specifying the kind of details retrieved (permissions, email, profile). No contradictions or missing behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two introductory sentences and a brief argument list. Every word serves a purpose—no fluff. Front-loaded with action and use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description's mention of 'User account details' is sufficient. It does not need to enumerate fields. The description covers the main purpose and usage, though could marginally expand on output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (username described, client not). The description repeats the username description and adds 'Optional SophosFirewallClient instance' for client, but lacks detail on when or how to use the client parameter. Baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve details for a specific local user account,' using a specific verb and resource. It also gives context for inspection of permissions, email, or profile settings, distinguishing it from sibling tools like sophos_list_users which list all users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use when inspecting permissions, email, or profile settings for a user.' This implies the tool is for detailed lookup, differentiating from listing tools. No explicit when-not-to-use or alternatives, but the context is clear.
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 declare readOnlyHint=true, so description adds limited behavioral context beyond that. Mentions return type ('List or dict') which is useful but not critical. No disclosure of pagination, limits, or other side effects, but adequate for a read-only list 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (4 lines), front-loaded with purpose, then usage, then args/returns. No extraneous words. Clear structure that is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema (not shown), so description needn't detail return values. It mentions return type. For a simple list with two optional params, the description covers the essentials. Could add detail about no pagination or default behavior, but sufficient for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only name described). Description adds meaning for 'client' ('Optional SophosFirewallClient instance') beyond the schema, which has no description. For 'name', it repeats schema info. Compensates for missing schema detail on client parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action ('List firewall security rules') and resource ('configured on the appliance'). Distinguishes from sibling tools (e.g., sophos_get_firewall_rule for single rule) by implying a batch operation. Includes usage context ('browsing security policies, searching by name').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('browsing security policies or searching for rules matching a specific name'). Does not explicitly mention when not to use or list alternatives, but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, indicating a read operation. It adds that the tool returns 'List or dict of FQDN host objects', providing useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a clear one-line purpose, a usage sentence, and a structured Args/Returns section. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (list with optional filter), and the output schema exists. The description covers the main behavior, but lacks details on error handling or pagination. Still adequate for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters with descriptions. The description adds meaning for the 'client' parameter by specifying its type ('SophosFirewallClient instance'), but repeats the schema's filter description for 'name'. Overall minimal new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'FQDN (Fully Qualified Domain Name) host objects'. It also differentiates from siblings by specifying 'domain-based network host objects', contrasting with IP host 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when inspecting domain-based network host objects', providing clear context. It does not explicitly state when not to use or list alternatives, but the purpose is well-defined.
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 annotation readOnlyHint=true already indicates read-only behavior. The description adds no further behavioral details like pagination or limits, but does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three short sentences with clear front-loading of purpose, followed by usage and args sections. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple listing purpose, read-only annotation, and optional filters, the description is adequate. It mentions return type (list or dict) and has an output schema. Minor omission: no mention of pagination or result limits, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only name described). The description adds meaning for the client parameter as 'Optional SophosFirewallClient instance' and repeats the name filter, compensating for the missing schema description on client.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List IP host objects defined on Sophos Firewall,' specifying the verb and resource. It distinguishes from siblings like sophos_get_ip_host and sophos_list_ip_host_groups by mentioning browsing of IP addresses, subnets, and ranges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when browsing IP address, network subnet, or IP range objects,' providing clear context. It does not explicitly exclude cases nor name alternative tools, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=true, so the description adds little beyond 'returns API response status dictionary.' No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus Args/Returns sections. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple delete operation, annotations covering safety profile, and presence of an output schema (not shown but indicated), the description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains 'name' as the host group to remove and 'client' as an optional SophosFirewallClient instance, adding meaning beyond the schema (which only has title for client).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete an IP host group by name,' providing a specific verb and resource. It distinguishes itself from sibling tools like sophos_list_ip_host_groups and sophos_create_ip_host_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Use when deleting an obsolete host group object from Sophos Firewall,' giving clear context. While it doesn't explicitly exclude other uses or mention alternatives, it sufficiently guides the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that it 'Retrieve configuration details', which is consistent with read-only behavior. No additional behavioral traits are disclosed beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, with a clear one-sentence purpose, a usage line, and a structured Args/Returns section. Every part adds value, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with an output schema present, the description covers the purpose, usage, parameters, and return value. It is complete given the tool's complexity and available structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes only the 'name' parameter; the 'client' parameter lacks description. The tool description clarifies 'client: Optional SophosFirewallClient instance', adding meaning for the otherwise undocumented parameter. Schema coverage is 50%, and description compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and resource 'configuration details for a specific IP host object'. It distinguishes itself from sibling tools like sophos_list_ip_hosts (which lists all) by specifying it targets a specific object by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: 'Use when inspecting target IP address or subnet definition for an object.' It does not explicitly mention when not to use or alternative tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it retrieves 'detailed configuration,' implying no side effects. No behavioral traits beyond this are disclosed, but the annotation covers the main aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences for purpose and usage, followed by arg/return details. It is front-loaded with the key action and avoids redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and annotations, the description adequately explains the tool's purpose and key parameters. It mentions relevant audit parameters (source, destination, service) and is complete for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (name has description, client lacks). The description clarifies that client is 'Optional SophosFirewallClient instance,' adding meaning beyond the schema's 'Client' title. For name, it restates the schema but is consistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve detailed configuration of a specific NAT rule,' specifying the verb (retrieve) and resource (NAT rule). It differentiates from siblings like sophos_list_nat_rules (list all) and sophos_create_nat_rule (create), ensuring distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case: 'Use when auditing original/translated source, destination, and service parameters.' It does not explicitly state when not to use or list alternatives, but the context is sufficiently clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds that it lists 'active logged-in user sessions' but does not disclose other traits like pagination, limits, or effects; minimal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: one sentence for purpose, one for usage, then args/returns. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema, the description is complete. It specifies the action, usage, parameter semantics, and return type, requiring no further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains that 'client' is an optional SophosFirewallClient instance, adding meaning beyond the schema's default null. Clarifies type and optionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'active logged-in user sessions on Sophos Firewall', distinguishing it from sibling tools like sophos_list_users that list user accounts rather than sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'when monitoring live user logins, active session counts, or connected users.' Does not include when-not-to-use or alternatives, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, destructiveHint=false, readOnlyHint=false. The description adds value by enumerating the updateable fields (status, translated_source, etc.) and stating the return type (API response dictionary). This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with clear sections: purpose, usage, args, returns. It is concise (8 lines) and front-loaded with the main purpose, with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, optional fields) and the presence of annotations and output schema, the description is thorough. It explains what can be updated, when to use, arguments, and return value, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%) with most parameters described. The description's docstring replicates parameter descriptions with minimal added context. The 'client' parameter is described as 'Optional SophosFirewallClient instance' in docstring but not in schema, providing marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update fields on an existing NAT rule' with a specific verb and resource. It differentiates from sibling tools (list, get, create, delete) by focusing on updating an existing rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when updating status or target translation parameters on an existing NAT or port-forwarding rule', providing clear context on when to use. It does not explicitly list alternatives but implies other tools for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, and the description consistently indicates a read operation ('Find...'). The description adds value by specifying the return type: 'List of matching tool schema definitions or status string.' No contradiction. It also discloses the default for top_k. This fully transparent behavior is well beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three lines of purpose and two lines of parameter docs. Every sentence is essential and front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and return type. Given the presence of an output schema (not shown, but provided), it does not need to detail the return structure. However, it could explain how matching works (e.g., semantic search) or the relationship with 'call_routed_tool.' Still, it is complete enough for a meta-tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema itself lacks parameter descriptions (0% coverage), the description provides meaningful context: query is 'Natural language task description or question' and top_k is 'Number of relevant tools to return. Default is 5.' This adds necessary meaning beyond the schema's type-only info, partially compensating for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find relevant Sophos Firewall tools matching a natural language prompt.' This specific verb+resource combination distinguishes it from sibling tools, which are operational tools for direct actions. The tool serves as a meta-tool for discovering other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs to find the appropriate tool for a natural language task, but it does not explicitly state when not to use it or provide alternatives. The sibling 'call_routed_tool' might be related but is not mentioned. Guidance is implied but lacks 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?
Annotations already indicate destructive and idempotent behavior. The description adds that deletion is permanent and returns an API response status dictionary, providing additional context beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences covering purpose, usage, and parameters/returns. No redundant information, and the structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with an output schema, the description effectively covers what it does, when to use, and parameters. It does not mention prerequisites like rule existence, but sibling tools handle related operations, making this fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 50% coverage (description only for 'name'). The description's 'Args' section repeats the name description but adds meaningful detail for 'client' (optional SophosFirewallClient instance), compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a firewall rule by name,' specifying the action and resource. The 'Use when' line adds context for obsolete security policies, distinguishing it from siblings like create, update, or list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use for permanently removing an obsolete security policy, which guides when to invoke it. Does not explicitly exclude alternative scenarios or mention other tools, but the 'use when' directive is sufficient context.
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 indicates the tool is read-only ('Retrieve') and mentions the return of 'Status details'. The annotation readOnlyHint: true already signals safety, but the description adds value by listing specific services and the monitoring/diagnosing use case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short paragraphs covering purpose, usage, args, and returns. Every sentence is necessary and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, when to use, parameter, and return. An output schema exists, so detailed return info is not needed. Minor omission: no mention of default behavior if client is omitted, but overall complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage for the only parameter 'client', the description adds essential meaning: 'Optional SophosFirewallClient instance.' This clarifies the parameter's purpose, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and resource 'operational status of system services' with specific examples (DNS, DHCP, IPS, etc.). This effectively distinguishes it from sibling tools that target firewall rules, users, or other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when monitoring background service health or diagnosing firewall subsystem failures,' providing clear context for when to use the tool. It does not include exclusions or alternatives, but the guidance is sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description adds that it returns configurations and status, which is additional behavioral context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage, args/returns. No wasted words, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple input schema, existing output schema, and annotations, the description covers purpose, usage, parameter semantics, and return value without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'client' is described as 'Optional SophosFirewallClient instance', adding type and optionality beyond the schema (which had 0% description coverage). This fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists 'IPsec site-to-site VPN connection configurations and status', using a specific verb and resource. It distinguishes from siblings like sophos_list_firewall_rules that deal with different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when inspecting site-to-site IPsec tunnel states and gateway parameters', providing clear context. However, it does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. The description adds 'permanently removing' which reinforces the irreversible nature, but does not introduce additional behavioral context beyond what annotations convey. Still, it aligns well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, one for usage, followed by clear Args and Returns. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with annotations and an output schema, the description covers purpose, usage, parameters, and return value. It does not need to elaborate on the output format since the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters with descriptions (name). The description compensates for the client parameter by stating 'Optional SophosFirewallClient instance,' adding meaning beyond the schema's empty description. The Args section matches and clarifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a NAT rule by name.' The verb 'Delete' and resource 'NAT rule' are specific, and the tool is easily distinguished from sibling tools like sophos_create_nat_rule or sophos_update_nat_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use when permanently removing a NAT or port-forwarding policy.' This tells the agent exactly when to invoke this tool, and there is no confusion with alternatives since deletion is unique.
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:

[![sophos-firewall-mcp MCP server](https://glama.ai/mcp/servers/jelmervdm/sophos-firewall-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jelmervdm/sophos-firewall-mcp)

Score Badge

Copy to your README.md:

[![sophos-firewall-mcp MCP server](https://glama.ai/mcp/servers/jelmervdm/sophos-firewall-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jelmervdm/sophos-firewall-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/jelmervdm/sophos-firewall-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server