Continuous website testing by Validoria — monitor security, SEO, performance, and accessibility.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 71 of 74 tools scored. Lowest: 2.9/5.
Most tools are clearly separated by resource (targets, runs, findings, incidents, etc.) and action. A few close pairs like active_runs/list_runs and mute_finding/create_muting_rule could confuse, but descriptions clarify the distinctions.
The majority of tools follow verb_noun naming (create_target, get_target, delete_journey). A few outliers use noun phrases (active_runs, daily_trends, system_health, team_stats) which slightly breaks the pattern, but overall the convention is predictable.
74 tools is extreme for any MCP server. Even for a comprehensive monitoring platform, this overwhelms agents with too many granular operations (e.g., enable_all_tests vs disable_all_tests vs update_test, or import_targets duplicating create_target). A more consolidated set would be appropriate.
The tool surface is remarkably complete for the monitoring domain: full CRUD for targets, journeys, rules, reports, secrets, and fragments; plus run triggering, incident management, findings handling, SEO tracking, guest scans, and admin tools. Only maintenance windows lack an update operation, which is minor.
acknowledge_incidentAcknowledge IncidentAInspectAcknowledge an open incident to signal that someone is looking at it. Changes status from OPEN to ACKNOWLEDGED.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentId | Yes | The incident ID to acknowledge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states the status change and the intent behind it, which is useful. However, it does not mention what happens if the incident is not in OPEN state (e.g., error vs no-op) or whether the action is reversible, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no filler. Each sentence adds essential information: the purpose and the state change.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core behavior and purpose adequately. It could be more complete by noting error conditions or how to obtain the incidentId, but given its simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter incidentId as 'The incident ID to acknowledge', and the main description adds no additional meaning beyond that. Schema coverage is 100%, so the baseline is 3, and the description does not elevate it further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Acknowledge an open incident') and its purpose ('to signal that someone is looking at it'), while also specifying the exact state transition ('Changes status from OPEN to ACKNOWLEDGED'). This distinguishes it from sibling tools like resolve_incident, which would close the incident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when an incident is open and someone needs to indicate they are investigating it. However, it does not explicitly mention alternatives such as resolve_incident or state when not to use it, so it lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
active_runsActive RunsAInspectGet currently running and queued tests across all targets. Useful for checking what tests are in progress right now.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | No | Filter by target ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns running and queued tests, but it does not explicitly state read-only nature, side effects, or any limitations. It adds a bit of context but lacks rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that are front-loaded with the main purpose and a brief use case. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter and no output schema, the description adequately explains scope and use case. It could mention return format, but not essential for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes targetId as 'Filter by target ID' with 100% coverage. The description doesn't add additional semantics for the parameter, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and defines the resource as 'currently running and queued tests across all targets.' This clearly distinguishes it from sibling tools like list_runs or get_run by focusing on the current active state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'useful for checking what tests are in progress right now,' providing clear context for when to use it. However, it doesn't explicitly name alternatives or state when not to use it, like list_runs for historical runs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_keywordAdd KeywordAInspectAdd an SEO keyword to track for a target. Max 50 keywords per target.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | The keyword to track | |
| targetId | Yes | The target ID | |
| isPrimary | No | Mark as primary keyword | |
| pageScope | No | URL pathname pattern to scope the keyword to (e.g. /kategori/*) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only discloses the 50-keyword limit; it does not mention whether duplicates are handled, whether the target must exist, whether the operation is idempotent, or what happens on success or failure. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that immediately state the action and resource. It includes the important limit but avoids any filler or redundant information, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters and no output schema or annotations, the description covers the core purpose and a key constraint, but it lacks details on return values, duplicate keyword handling, and target validation. It is adequate but leaves meaningful gaps for an agent to discover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all four parameters, including descriptions for keyword, targetId, isPrimary, and pageScope. The description adds no additional parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' with a clear resource 'SEO keyword' and context 'to track for a target'. This unambiguously communicates the tool's function and distinguishes it from sibling tools like list_keywords and remove_keyword.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when adding a new keyword to a target's tracking, but it does not explicitly state when to use it over alternatives or when not to use it. The 'Max 50 keywords per target' constraint provides a boundary but no explicit guidance on exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_targetAnalyze TargetAInspectFingerprint a URL and get test recommendations before creating a target. Detects platform (Shopify, WordPress, etc.), CDN, server stack, frontend framework, analytics, and B2B/ecommerce signals. Returns recommended tests with explanations. Use this before create_target to know what type to assign and which tests will be enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to analyze, e.g. "https://example.com" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It clearly states the tool 'detects' and 'returns' information, implying a read-only analysis, but it does not explicitly confirm that it makes no modifications, handle error cases, or note any side effects like making external network requests. This is a reasonable but not exhaustive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and structured logically: purpose, detection details, output, and usage guidance. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), the absence of an output schema, and no annotations, the description covers the key aspects: what it does, what it detects, what it returns, and when to use it. It omits only finer details like error behavior or the exact structure of recommendations, but it remains sufficiently complete for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the sole 'url' parameter 100% with its own description and format. The tool description adds context by framing the URL as a website to fingerprint, but it does not add new constraints (e.g., public accessibility) beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fingerprint') and resource ('a URL'), clearly distinguishing it from sibling tools like create_target or get_target. It also explains the outcome ('get test recommendations') and lists specific detection capabilities, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this before create_target'. This serves as clear usage guidance and an alternative, directly linking to a sibling tool and clarifying the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_load_testCancel Load TestBInspectCancel a running load test.
| Name | Required | Description | Default |
|---|---|---|---|
| loadTestRunId | Yes | The load test run ID to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It only says 'Cancel a running load test' without detailing whether the operation is reversible, requires special permissions, or affects collected data. This lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the essential verb and object. It is not verbose, but it is under-specified. While brevity is positive, the tool could benefit from a bit more context without adding excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is nearly complete, but it omits important behavioral details such as idempotency, effect on run status, and whether a non-running test can be cancelled. This leaves the agent with unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter (loadTestRunId) with 100% coverage. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'cancel' and identifies the resource 'load test', clearly distinguishing it from sibling tools like start_load_test and list_load_tests. The phrase 'running' clarifies the scope, making the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what it does but provides no guidance on when to use it versus alternatives, nor any prerequisites or caveats. There is no mention of when cancellation is allowed (e.g., only while running) or what happens to the test results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_automation_ruleCreate Automation RuleAInspectCreate an automation rule that reacts to events. Triggers: TEST_FAILED, TEST_RECOVERED, INCIDENT_CREATED, INCIDENT_RESOLVED, TARGET_DOWN, TARGET_RECOVERED. Actions: escalate (change severity), suppress (mute), rerun (schedule retry), notify, webhook, add_note.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Rule name | |
| actions | Yes | Actions to execute when triggered | |
| trigger | Yes | Event that triggers the rule | |
| targetId | No | Optional target ID to scope rule to a specific target | |
| conditions | No | Optional conditions that must be met | |
| priorityOrder | No | Priority order (lower = evaluated first) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It details the rule's reactivity and the available triggers/actions, but doesn't disclose whether the rule becomes active immediately, any permission requirements, or what the response contains. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three short sentences. The main purpose is front-loaded, followed by scannable lists of triggers and actions, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects for conditions and actions, plus priorityOrder, but the description only covers triggers and actions. It omits optional conditions, priority order, and targetId scope. Since there is no output schema, the return value is also unspecified. The schema covers these, but for a moderately complex create operation, a fuller overview is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage, but the description adds extra meaning by explaining each action type (e.g., escalate changes severity, suppress mutes, rerun schedules a retry). This enriches the bare enum values with practical semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an automation rule that reacts to events, and lists the specific triggers and actions. It is specific and informative, but it doesn't explicitly differentiate from sibling tools like create_muting_rule or create_notification_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context by enumerating the supported triggers and actions, making it evident when to use this tool. However, it doesn't mention exclusions or alternative tools for specific scenarios, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_journeyCreate JourneyAInspectCreate a custom browser test flow for a target. Steps are executed sequentially in a Playwright browser. Supports actions: navigate, click, type, fill, select, assert, wait, screenshot, scroll, hover, use_fragment. Variables like {{LOGIN_EMAIL}} are resolved from the target secrets vault.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Journey name | |
| steps | Yes | Ordered list of browser actions | |
| platform | No | Platform tag (e.g. "shopify", "woocommerce") | |
| targetId | Yes | Target ID to create the journey for | |
| description | No | Journey description | |
| timeoutSeconds | No | Max execution time in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It reveals that steps run sequentially in Playwright, lists supported actions, and explains variable resolution from the secrets vault—useful runtime semantics. However, it omits creation-time behaviors such as validation, storage, or response type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—four sentences, front-loaded with the purpose, and each sentence provides distinct value (execution model, supported actions, variable resolution). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested steps and no output schema, the description provides solid context: sequential execution, supported actions, and variable resolution. It falls short by not explaining what the create operation returns or explicitly noting that it does not run the journey (trigger_journey does). Slightly more completeness would earn a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond property descriptions by enumerating valid actions and illustrating variable syntax ({{LOGIN_EMAIL}}), helping users construct the steps array correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Create a custom browser test flow for a target.' It distinguishes from other create_* siblings by emphasizing browser test flow and Playwright execution, making it evident this is for creating a journey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit. The description explains what the tool does but does not state when to use it versus alternatives like trigger_journey or update_journey, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_maintenance_windowCreate Maintenance WindowAInspectSchedule a maintenance window for a target. During maintenance, alerts and notifications are suppressed. Supports one-time, daily, and weekly recurring windows.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the window, e.g. "Weekly deploy" | |
| endsAt | Yes | End time as ISO 8601 string, e.g. "2026-04-05T04:00:00Z" | |
| startsAt | Yes | Start time as ISO 8601 string, e.g. "2026-04-05T02:00:00Z" | |
| targetId | Yes | The target ID | |
| recurrence | No | Recurrence pattern (required if isRecurring is true) | |
| description | No | Optional description | |
| isRecurring | No | Whether this window repeats |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the key behavioral effect: alerts and notifications are suppressed during maintenance. It also mentions support for one-time and recurring windows, adding useful context beyond the basic create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the main action, and contains no redundant or vague phrasing. Every word contributes to understanding the tool's purpose and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and no output schema, the description only covers the basic purpose and suppression behavior. It does not explain how to configure recurrence (the isRecurring and recurrence relationship) or mention what the tool returns, leaving the agent to infer these details from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds minimal parameter information beyond the schema, only hinting at daily/weekly recurrence without explaining the isRecurring/recurrence dependency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb ('Schedule') and resource ('maintenance window for a target'), and explains the core purpose (suppress alerts/notifications). It distinguishes from sibling tools like list_maintenance_windows and delete_maintenance_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning alert suppression during maintenance, but it does not explicitly state when to use this tool versus alternatives like create_muting_rule or create_automation_rule, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_muting_ruleCreate Muting RuleAInspectCreate a rule to auto-mute findings matching a pattern. Existing open findings matching the rule are muted immediately. Supports muting by fingerprint pattern, test definition, or test+target combination.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes | FINGERPRINT: match by finding fingerprint substring. TEST_DEFINITION: mute all findings from a test. TEST_TARGET: mute findings from a specific test on a specific target. | |
| reason | No | Reason for muting | |
| targetId | No | Target ID to scope the rule to (required for TEST_TARGET, optional for others) | |
| expiresAt | No | Optional expiry as ISO 8601 string. Rule auto-expires after this time. | |
| testDefinitionId | No | Test definition ID (required for TEST_DEFINITION and TEST_TARGET scopes) | |
| fingerprintPattern | No | Substring to match in finding fingerprints (required for FINGERPRINT scope) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the transparency burden. It usefully discloses that existing open findings matching the rule are muted immediately and that the rule auto-mutes future matching findings. It does not discuss permissions or response details, but the key side effect is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose first, then immediate-muting behavior, then supported scope types. Every sentence adds unique, relevant information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core action, key side effects, and the three modes, complemented by a rich schema. However, since there is no output schema, it could mention what the API returns (e.g., the created rule ID). This is a minor gap, but overall the context is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents every parameter thoroughly (100% coverage), including conditional requirements. The description adds a high-level mapping of the three scope modes but does not provide additional per-parameter meaning beyond what the schema already states, so it earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a rule to auto-mute findings matching a pattern,' which names the specific verb, resource, and purpose. It differentiates from one-off muting tools by emphasizing this is a persistent rule and lists three distinct scope modes, making it clear what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this tool is for pattern-based, persistent muting and notes the immediate effect on existing findings, which implies appropriate use cases. However, it does not explicitly mention alternatives like mute_finding or state when not to use the tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_notification_ruleCreate Notification RuleAInspectCreate a notification alert rule. Defines which events at which severity levels trigger notifications on which channels. Supports quiet hours and per-target scoping.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Rule name | |
| enabled | No | Whether the rule is active | |
| targetId | No | Scope to a specific target | |
| eventTypes | Yes | Events that trigger this rule | |
| severities | No | Only trigger for these severities | |
| channelTypes | Yes | Channels to notify | |
| quietHoursEnd | No | Quiet hours end (hour UTC) | |
| quietHoursStart | No | Quiet hours start (hour UTC) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral aspects: the rule triggers notifications based on events, severities, and channels, and supports quiet hours and per-target scoping. However, it does not mention side effects, permission requirements, or response behavior, leaving some gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and resource. Each sentence adds meaningful detail: the first defines the purpose, the second highlights key features. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description covers the core functionality but omits possible validations or response details. However, the schema already documents parameters fully, and the description effectively captures the essential behavior, making it complete enough for an experienced user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the overall semantics: 'Supports quiet hours and per-target scoping' clarifies the purpose of quietHoursStart/End and targetId beyond their schema descriptions. This enriches the parameter understanding without being verbose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Create a notification alert rule.' It then defines the specific purpose: 'Defines which events at which severity levels trigger notifications on which channels,' distinguishing it from sibling tools like create_automation_rule and create_muting_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it creates notification alert rules with event/severity/channel mappings. While it does not explicitly mention alternatives or exclusions, the context is sufficient given the tool's name and sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_page_fragmentCreate Page FragmentAInspectCreate a reusable step sequence that can be shared across multiple Journeys. Fragment names must be unique per team.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Fragment name (unique per team) | |
| steps | Yes | Ordered list of browser actions | |
| description | No | Fragment description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only mentions that fragment names must be unique per team, which is already stated in the schema. It does not disclose any other behavioral traits such as whether the operation is idempotent, what happens on duplicate name, authorization requirements, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every word contributes value. It is concise without sacrificing necessary context about reuse and uniqueness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity due to the nested steps array, but the schema covers the parameter details. There is no output schema, but for a creation tool, return values are often implicitly understood. The description does not mention any prerequisites (e.g., team context) or effects on existing fragments, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter semantics beyond the schema, but the schema already thoroughly documents each parameter, including nested step properties. Therefore, the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Create') on a specific resource ('page fragment') and clarifies what a page fragment is ('reusable step sequence') and its intended use ('shared across multiple Journeys'). This clearly distinguishes it from sibling tools like create_journey or update_page_fragment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to define a reusable step sequence for use in multiple Journeys. It does not explicitly state when not to use it or name alternative tools, but the context is clear given sibling tools like create_journey and update_page_fragment. Lacks explicit exclusion but sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_scheduled_reportCreate Scheduled ReportAInspectCreate a new scheduled email report. Reports include run stats, open findings, composite scores, and per-target status.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Report name | Weekly Summary |
| hourUtc | No | Hour in UTC to send the report | |
| dayOfWeek | No | Day of week for WEEKLY reports (0=Sunday, 1=Monday, ..., 6=Saturday) | |
| frequency | No | How often to send | WEEKLY |
| recipients | No | Comma-separated email addresses. Empty = all team members. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects. It fails to mention that scheduling will start sending emails, potential permission requirements, or the return value. The description is safe but incomplete on behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant wording. It front-loads the core action and then briefly states the report contents, earning every sentence its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a clear overview, but for a mutation tool with no output schema and no annotations, it omits details about what is returned after creation, side effects, and permission context. It is adequate but not fully complete for an agent to understand all consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description's mention of report contents does not add substantive meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with resource 'scheduled email report' and lists the report contents, clearly distinguishing it from update/delete/list siblings. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for creating scheduled reports, but provides no explicit guidance on when to prefer this over update_scheduled_report or other alternatives. No exclusions or prerequisites are mentioned, leaving usage context mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_targetCreate TargetAInspectAdd a new website, API, or webshop target for monitoring with full onboarding. Automatically enables compatible tests, triggers an initial scan, and captures a page screenshot. Requires write scope (Free plan: 1 target). Use analyze_target first to detect platform and get test recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to monitor, e.g. "https://example.com" | |
| name | Yes | Display name for the target | |
| tags | No | Optional tags for categorization | |
| type | Yes | Target type: WEBSITE, API, or WEBSHOP. Use analyze_target to auto-detect. | |
| weight | No | Business weight, used to rank findings by consequence: REVENUE_PATH (checkout, payment, signup), PUBLIC (customer-visible but not transactional), INTERNAL (staging, admin tooling). | PUBLIC |
| environment | No | Deployment environment | PRODUCTION |
| uptimeEnabled | No | Enable background uptime monitoring |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It explicitly states that the tool 'automatically enables compatible tests, triggers an initial scan, and captures a page screenshot,' and notes the write scope requirement and free plan limit. This goes well beyond a simple 'create' statement, though it does not cover failure modes or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. The first sentence states the purpose, the second lists key side effects, and the third covers prerequisites and a recommended alternative. It is perfectly front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, 3 enums) and the absence of annotations and output schema, the description provides solid coverage: purpose, side effects, prerequisites, plan limits, and an ordering recommendation. The only notable omission is what happens on success (return value), but this is common for create tools and the description is otherwise complete enough for an 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little parameter-specific meaning beyond the schema; it mentions 'website, API, or webshop' which maps to the type enum, and 'Use analyze_target first' echoes the type parameter description. The schema already documents all parameters thoroughly, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Add a new website, API, or webshop target for monitoring.' It also distinguishes the tool from siblings like update_target, delete_target, and analyze_target by focusing on the creation and onboarding scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: use to add a target and mentions prerequisites ('Requires write scope (Free plan: 1 target)'). It also explicitly names an alternative via 'Use analyze_target first to detect platform and get test recommendations.' However, it does not explicitly state when not to use (e.g., for updating existing targets), so it lacks full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_trendsDaily TrendsAInspectGet daily time-series data for runs, findings, and average duration. Useful for identifying trends over time. Returns up to 90 days of data.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days of history to return | |
| targetId | No | Filter by target ID (omit for team-wide) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does mention 'Returns up to 90 days of data,' which is a useful limit, but it omits other behavioral aspects like read-only nature, permission requirements, or return structure. This is a moderate disclosure for a read-only analytics tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three concise sentences, each adding value: the core function, the use case, and the data limit. There is no unnecessary fluff, and it is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, use case, and a key limit (90 days), but it lacks details about the output format or structure, especially since there is no output schema. For a simple data retrieval tool, the description is adequate but leaves room for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (days and targetId) having clear descriptions in the schema. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets daily time-series data for runs, findings, and average duration, which specifies the verb, resource, and scope. However, it does not explicitly distinguish itself from sibling tools like target_stats or team_stats, so it misses the differentiation criterion for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is 'useful for identifying trends over time,' which provides clear context for when to use it. It does not mention exclusions or alternative tools, but the use case is explicit enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_automation_ruleDelete Automation RuleAInspectPermanently delete an automation rule.
| Name | Required | Description | Default |
|---|---|---|---|
| ruleId | Yes | The automation rule ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. The word 'permanently' communicates irreversibility, but additional details such as permission requirements, side effects, or behavior for non-existent rules are absent, representing a clear gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single five-word sentence that directly states the function without any redundant or irrelevant content. This is an ideal model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description provides the necessary purpose and permanence. It lacks some deeper context about errors or side effects, but given the low complexity, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage with a description for ruleId ('The automation rule ID to delete'). The tool description adds no further parameter-level semantics, so it stays at the baseline for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as 'permanently delete' targeting 'an automation rule', using a specific verb and resource. This distinguishes it from sibling tools like create_automation_rule, get_automation_rule, and update_automation_rule, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as disabling a rule or using other delete operations. It only states the action, leaving the agent to infer context without any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_journeyDelete JourneyAInspectPermanently delete a journey and all its steps.
| Name | Required | Description | Default |
|---|---|---|---|
| journeyId | Yes | The journey ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states 'permanently delete' (irreversibility) and 'all its steps' (cascade effect), which are critical for a destructive tool. However, it omits details like authentication requirements or error behavior, so it's not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is front-loaded and every word contributes value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with no output schema, the description covers the essential destructive and cascade context. It could add details about idempotency or not-found errors, but the low complexity means the current description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter journeyId, and the description does not add additional meaning beyond the schema. The baseline of 3 applies because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'delete' and identifies the resource 'journey' along with scope 'all its steps', clearly distinguishing it from sibling tools like create_journey, update_journey, get_journey, and list_journeys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided, but the destructive nature is implied by the name and description. It lacks exclusions, prerequisites, or comparisons with alternatives, so usage context is only partially clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_maintenance_windowDelete Maintenance WindowAInspectRemove a scheduled maintenance window.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID (for access verification) | |
| windowId | Yes | The maintenance window ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It describes the deletion but does not disclose that the action is permanent, irreversible, or whether it affects scheduled activities. This is a notable gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. It is front-loaded and easy to parse, though extremely minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description states the core action, and the schema handles parameter details. However, it lacks guidance on usage context and fails to disclose the irreversible consequences, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for both parameters (windowId and targetId), so the schema already explains their meaning. The description adds no additional parameter semantics beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' with the resource 'scheduled maintenance window', clearly distinguishing it from create_maintenance_window and list_maintenance_windows. It states exactly what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is implied by the action, but there is no explicit guidance on when to use this tool versus alternatives, such as when a maintenance window should be cancelled. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_notification_ruleDelete Notification RuleAInspectPermanently delete a notification rule.
| Name | Required | Description | Default |
|---|---|---|---|
| ruleId | Yes | The notification rule ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'permanently' does disclose that the deletion is irreversible, which is a key behavioral trait. However, it does not mention permission requirements, side effects (e.g., stopping notifications), or behavior for nonexistent rule IDs, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word contributes to the meaning, and it is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description provides the essential action and permanence. However, the lack of annotations and output schema means the description should ideally cover side effects or error cases. It is minimally viable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines ruleId with a clear description ('The notification rule ID to delete') and 100% coverage. The tool description adds no additional parameter semantics. Since the schema fully documents the parameter, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Permanently delete a notification rule.' The verb 'delete' and resource 'notification rule' are specific and explicit. This distinguishes it from other delete_* sibling tools such as delete_target or delete_secret.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention that list_notification_rules should be used to find rule IDs, or that update_notification_rule is appropriate for modifications. Usage is implied by the name and description but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_page_fragmentDelete Page FragmentAInspectPermanently delete a page fragment.
| Name | Required | Description | Default |
|---|---|---|---|
| fragmentId | Yes | The fragment ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that deletion is permanent, which adds useful irreversibility context beyond just 'delete'. However, it does not mention permissions, side effects, or behavior if the fragment is in use, leaving gaps in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the verb and object. There is no redundancy or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with no output schema, the description is functionally sufficient. However, the absence of annotations and any mention of side effects or return value leaves minor gaps, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (fragmentId) with a clear description, so schema coverage is 100%. The tool description adds no additional meaning beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('delete') and resource ('page fragment'), clearly distinguishing it from sibling tools like create_page_fragment, update_page_fragment, and list_page_fragments. The added 'permanently' reinforces the destructive nature without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternative delete tools or when not to use it. It does not mention any prerequisites, conditions, or exclusions, leaving the agent to infer usage solely from the description and resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_scheduled_reportDelete Scheduled ReportAInspectPermanently delete a scheduled report.
| Name | Required | Description | Default |
|---|---|---|---|
| reportId | Yes | The scheduled report ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the deletion is permanent, which is useful context, but does not mention permissions, side effects on associated data, or whether the action can be undone. The minimal disclosure meets a basic threshold but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Permanently delete a scheduled report.' Every word contributes meaning, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is adequate but minimal. It lacks guidance on what the response looks like, whether confirmation is required, or any prerequisites. The 'permanently' note adds some context, but overall the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for reportId. The tool description does not add any additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('delete') and resource ('scheduled report') and clearly differentiates from siblings like update_scheduled_report or list_scheduled_reports. The word 'permanently' clarifies the scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives such as update_scheduled_report or disable. No preconditions, exclusions, or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_secretDelete SecretAInspectPermanently delete a secret from a target's vault.
| Name | Required | Description | Default |
|---|---|---|---|
| secretId | Yes | The secret ID to delete | |
| targetId | Yes | The target ID (for access verification) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the deletion is permanent, which is a key trait, but does not mention permissions, side effects, or reversibility beyond the word 'permanently'. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-worded sentence with no unnecessary words. It front-loads the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two documented parameters, the description is adequately complete. It conveys the permanent nature and vault context, though it could benefit from noting what happens if the secret is in use or if any confirmation is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both secretId and targetId, covering 100% of parameters. The description adds no additional parameter information, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (permanently delete), the resource (a secret), and the scope (from a target's vault). It distinguishes itself from sibling tools like store_secret and rotate_secret by focusing on destructive deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for removing secrets permanently but does not explicitly state when to use it over alternatives like rotate_secret. No exclusions or alternate tool references are provided, leaving some ambiguity for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_targetDelete TargetAInspectPermanently delete a target and all its associated data (runs, findings, incidents, artifacts). This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be true to confirm deletion | |
| targetId | Yes | The target ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It clearly warns that deletion is permanent ('cannot be undone') and cascades to associated data, which is the critical behavioral trait for a delete tool. It does not address authentication or return values, but the core destructive behavior is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action ('Permanently delete') and includes the key warning. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (2 required, fully described in schema), no output schema, and no nested objects, the description provides sufficient context. It explains the tool's full effect and irreversible nature, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for targetId and confirm. The parameter purposes are obvious from the schema, so no extra compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'target', and specifies the scope by enumerating associated data (runs, findings, incidents, artifacts). It is unambiguous and distinct from sibling tools like update_target or create_target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies destructive, permanent usage but does not explicitly contrast with alternatives or state when not to use it. There is no mention of 'use update_target to modify' or 'consider list_targets before deletion', so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
disable_all_testsDisable All TestsAInspectDisable all test definitions globally. Optionally filter by category to only disable tests in that category. Requires admin scope.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Only disable tests in this category. Omit to disable all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the global scope, optional filtering, and admin permission requirement, but does not mention reversibility, impact on running tests, or the return value. It provides basic behavioral context but lacks deeper side-effect disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the main action, followed by optionality and a permission note. No extraneous words or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema, no annotations), the description adequately covers the core purpose, usage, and permission. It misses explicit guidance on alternatives and side-effect details, but these are not critical for this straightforward mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a descriptive enum and clear parameter description. The description's 'Optionally filter by category' essentially restates the schema, adding no new semantic value beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Disable' with a clear resource 'all test definitions globally', and the optional category filter adds specificity. It clearly distinguishes from siblings like enable_all_tests and trigger_all_tests by stating the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a prerequisite ('Requires admin scope') and hints at selective use via category filtering, but it does not explicitly mention alternatives like enable_all_tests or when not to use this tool. Usage is implied rather than explicitly contrasted with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
enable_all_testsEnable All TestsAInspectEnable all test definitions globally. Optionally filter by category to only enable tests in that category. Requires admin scope.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Only enable tests in this category. Omit to enable all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation requires admin scope and applies globally, and that the category parameter filters which tests are enabled. However, it does not explain whether the operation is idempotent, what happens to already-enabled tests, or what the response looks like, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the main action, then the optional filter, then the permission requirement. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description covers the essential aspects: what it does, the optional filter, and the auth requirement. It lacks information about side effects or reversibility, but given the low complexity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single optional 'category' parameter, including an enum of categories and the note 'Omit to enable all.' The description repeats this information almost verbatim ('Optionally filter by category to only enable tests in that category') without adding new detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('enable') and resource ('test definitions') with clear scope ('globally') and an optional filter. It distinguishes itself from siblings like disable_all_tests and trigger_all_tests by explicitly stating it enables definitions, not runs or disables them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: use this to enable all test definitions globally, optionally filtered by category. It also states the admin scope prerequisite. However, it does not explicitly mention when not to use it or name alternative tools, though the sibling list implies this is for bulk enablement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_automation_ruleGet Automation RuleAInspectGet full details of a specific automation rule.
| Name | Required | Description | Default |
|---|---|---|---|
| ruleId | Yes | The automation rule ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a get/read operation, implying no destructive side effects, but does not disclose error behavior, permission needs, or what 'full details' includes. The adjective 'full' adds modest context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It states the verb and resource directly, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter, this is adequate but not rich. It lacks details about the return structure (no output schema) or edge cases like missing IDs. However, the tool is straightforward enough that the description is likely sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for the single required parameter (ruleId). The description adds no additional parameter-level semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('automation rule') and the qualifier 'specific' to distinguish it from list_automation_rules. This unambiguously conveys that the tool retrieves a single rule by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving one specific rule, but does not explicitly mention when to use it instead of sibling tools like list_automation_rules. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_findingGet Finding DetailsAInspectGet full details of a specific finding, including evidence, AI analysis, and recommended fix.
| Name | Required | Description | Default |
|---|---|---|---|
| findingId | Yes | The finding ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses the return content and implies read-only behavior via 'Get', but does not explicitly state side effects, error handling, or permissions. Adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the action and lists key return fields without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description adequately communicates what the tool returns. It could go further by explicitly stating the full return object, but the listed details cover the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes findingId as 'The finding ID' with 100% coverage. The description adds no further parameter semantics beyond implying a specific finding, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'finding', and enumerates the specific details returned (evidence, AI analysis, recommended fix). This distinguishes it from sibling tools like list_findings and mute_finding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific finding' clearly implies this tool is for retrieving one finding by ID, contrasting with list tools. However, it does not explicitly name alternatives or state when not to use it, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_incidentGet Incident DetailsAInspectGet full details of a specific incident including linked findings, AI analysis, and deployment correlation.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentId | Yes | The incident ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the content of the response (linked findings, AI analysis, deployment correlation) but does not mention read-only behavior, error handling, or any side effects. The 'get' verb implies read-only, but the description could add more context such as required permissions or typical response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the action and includes specific, valuable details. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description provides sufficient context about what the tool returns. It lacks explicit mention of response format or potential errors, but these are not critical for a 'get' operation, so it feels reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter incidentId, with a basic description 'The incident ID'. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets full details of a specific incident, distinguishing it from list_incidents and incident mutation tools. It also specifies key content areas (linked findings, AI analysis, deployment correlation), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving comprehensive details of one incident, which provides clear context relative to siblings like list_incidents. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_journeyGet JourneyAInspectGet full details of a specific journey including all steps.
| Name | Required | Description | Default |
|---|---|---|---|
| journeyId | Yes | The journey ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool returns 'full details' and 'all steps', but says nothing about read-only nature, required permissions, error behavior (e.g., 404 for invalid journey ID), or response structure beyond that vague phrasing. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, every word contributes to conveying the action and scope. It is compact and front-loaded with the core purpose. While concise, it lacks some detail, but that is a completeness concern, not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with a single required parameter and no output schema, the description covers the essential return content (full details, all steps). It does not enumerate all possible fields, but that is not strictly required at this level of complexity. It could mention error scenarios or required permissions, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter, journeyId, which is described as 'The journey ID'. The description adds no extra semantic meaning to the parameter—it simply mentions 'specific journey' which aligns with the parameter but does not elaborate on format, constraints, or how to obtain the ID. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (journey), with specific scope ('specific journey') and content ('all steps'). It unambiguously distinguishes from list_journeys (which lists multiple) and mutation tools like create/update/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need full details of a single journey, differentiating it from list_journeys. However, it does not explicitly mention alternatives, exclusions, or conditions (e.g., 'use this to get a single journey; use list_journeys to browse'). The guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_load_testGet Load Test ResultsBInspectGet details and results of a load test run.
| Name | Required | Description | Default |
|---|---|---|---|
| loadTestRunId | Yes | The load test run ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It implies a read-only operation via 'get' but does not mention return format, permissions, or any side effects. This is minimal and does not add value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every part contributes to explaining the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is adequate but lacks detail on what 'details and results' include. Since there is no output schema, the description should clarify the return shape, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the only parameter loadTestRunId is already described in the input schema. The description adds no extra semantics or format details, so the score is baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets details and results of a load test run, which is specific and clearly aligns with the tool name. It differentiates from list-oriented siblings like list_load_tests, but does not explicitly contrast with get_run, which might be generic. Overall, the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_run, list_load_tests, or start_load_test. The description simply states what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_runGet Run DetailsAInspectGet full details of a specific test run including metrics, score, summary, errors, and associated findings.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The run ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It does list the included data fields, which provides some insight into return contents, but it does not mention error handling, permissions, or explicitly state that it is a read-only operation. 'Get' implies read-only but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, the target resource, and the expected content in a compact and readable way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter and no output schema, so the description need not explain return types. It adequately communicates the main output (metrics, score, summary, errors, findings) and the target resource. However, it could have explicitly mentioned that the runId is required to specify which run, though the schema already conveys this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for the single parameter runId with the description 'The run ID'. The tool description adds no parameter-specific information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('specific test run'), clearly distinguishing it from sibling list_runs. It also lists the contents (metrics, score, summary, errors, findings), which makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives. The usage is implied as a standard getter for full run details, but the description does not provide exclusions or comparisons with sibling tools like list_runs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_site_mapGet Site MapAInspectGet the latest crawl snapshot for a target. Returns page inventory stats, SEO issues, broken pages/assets, response times, and a diff against the previous crawl. Optionally include page-level details.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID | |
| pageLimit | No | Max pages to return when includePages is true | |
| pageStatus | No | Filter pages by status | |
| includePages | No | Include individual page data (can be large). Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add behavioral context by saying 'latest crawl snapshot' and 'diff against previous crawl', implying a read-only, comparative action. However, it does not explicitly state read-only safety, rate limits, or potential data-size implications, which are not covered elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and then listing key outputs. There is no fluff, and the structure makes it easy for an agent to grasp the tool's function quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey return value composition. It lists categories of data but lacks structural details, pagination behavior, and the interplay between includePages, pageLimit, and pageStatus. Given the moderate complexity, the description is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema, only indirectly echoing includePages via 'page-level details' and hinting at pageStatus via 'broken pages/assets, response times'. It does not explain parameter interdependencies, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and specific resource 'latest crawl snapshot for a target', then enumerates distinct outputs (page inventory stats, SEO issues, broken pages/assets, response times, diff against previous crawl). This distinguishes it from sibling tools like get_target or get_finding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving crawl snapshot data but does not explicitly state when to use it versus alternatives, nor provide any when-not or exclusion guidance. Sibling tools like analyze_target might be alternatives, but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_targetGet Target DetailsAInspectGet detailed information about a specific target including status, uptime, fingerprint, and composite scores.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates this is a read-only retrieval operation by saying 'get detailed information,' but it does not mention any permissions, error behavior (e.g., target not found), or side effects, which would be helpful for an agent to fully understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the action and result ('Get detailed information') and then specifies the content. Every word adds value, with no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the key return fields. However, it does not clarify the distinction from the closely related get_target_scores tool, which could be a source of agent confusion. Overall, it is mostly complete for a basic getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter targetId with a basic description. The tool description adds no additional detail about the parameter (e.g., where to find the ID or its format), so it does not enhance what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific target' with a specific verb and resource, and enumerates the types of details (status, uptime, fingerprint, composite scores). This distinguishes it from sibling tools like get_target_scores, which focuses on scores, and analyze_target, which implies deeper analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need detailed information about a single target, but it does not explicitly state when to use this tool versus alternatives like get_target_scores or analyze_target, nor does it provide exclusions or prerequisites. Guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_target_scoresGet Target Composite ScoresBInspectGet composite scores (Security, SEO, Performance, Accessibility) for a target. Each score is 0-100 with a status rating.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It adds useful output context (score range 0-100 and status rating) but does not explicitly state that this is a read-only operation, whether scores are cached, or how the status rating is determined. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the primary purpose and packs additional output details into the second sentence, making every word valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description covers the returned score categories and range. Minor gaps exist, such as not explaining the status rating or prerequisites, but overall it is sufficiently 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for the only parameter (targetId), so the baseline is 3. The description does not add any additional meaning or format details for the targetId parameter beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves composite scores (Security, SEO, Performance, Accessibility) for a target, using a specific verb ('Get') and resource. However, it does not explicitly differentiate from sibling tools like recompute_scores or target_stats, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as recompute_scores or analyze_target. It simply states what it does without any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_team_settingsGet Team SettingsAInspectGet the team's configuration including AI enrichment, uptime monitoring, severity escalation, run policies, notification coalescing, SEO, and Kloner Tasks integration settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It uses 'get' to imply a read-only operation but does not explicitly state that no changes are made, nor does it disclose permissions, return format, or side effects. The listing of settings adds some context, but it falls short of full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently lists the included settings. It is appropriately concise with no redundant wording, earning a perfect score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description provides adequate context about what the tool returns (the team's configuration). It falls slightly short by not explicitly confirming that the response contains the full set of settings, but the 'including' phrasing implies coverage. Overall, it's complete enough for a zero-argument getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter details. The baseline for 0 params is 4, and the description does not need to explain parameters. It adds no parameter semantics because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the team's configuration and enumerates specific setting categories (AI enrichment, uptime monitoring, etc.). This distinguishes it from siblings like 'update_team_settings' (modification) and 'team_stats' (statistics), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to view team configuration, and the verb 'get' signals a read operation. However, it does not explicitly exclude modification use cases or mention the alternative 'update_team_settings', so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
guest_get_scanGet guest scan resultsAInspectPoll results for a guest_start_scan. Pass the scanId and guestSessionId from the start response. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| scanId | Yes | Scan workflow id from guest_start_scan | |
| guestSessionId | No | Guest session id returned by guest_start_scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses that the operation is a poll (implying repeated calls) and that no API key is required, which is useful. However, it does not describe what happens if the scan is still running, error cases, or the response shape, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the purpose and then providing usage instruction. Every word earns its place, with no redundancy or fluff. It is appropriately sized for a simple polling tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter poll tool without an output schema, the description covers the necessary context: what it does, where to get parameters, and authentication. It omits return value details, but given the tool's simplicity and clear sibling relationship, this is a minor gap. The description is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions already exist. The description adds minor value by stating both IDs come from the start response, but this largely repeats the schema descriptions (e.g., 'from guest_start_scan'). No additional format, constraints, or meaning are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls results for a guest_start_scan, using the specific verb 'poll' and naming the resource. It differentiates from the sibling tool guest_start_scan by focusing on retrieving results after a scan is initiated. The instruction to pass scanId and guestSessionId from the start response reinforces its complementary role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after calling guest_start_scan, as it references passing IDs from the start response. It provides clear context for when to use the tool, but does not explicitly mention alternatives or exclusions. The pairing with guest_start_scan makes the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
guest_start_scanGuest quick scan (no account)AInspectRun a free 6-test HTTP scan against a public URL without an API key. Rate-limited (5/IP/hour, 3/session/day). Returns scanId — poll with guest_get_scan. For continuous monitoring, sign up free and use create_target. See teste-no://docs/quickstart.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL to scan, e.g. https://example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses rate limits, the lack of an API key requirement, the return of scanId, and the free/guest nature. It does not explicitly state that the scan will send HTTP requests to the target, but this is implied by 'HTTP scan' and 'against a public URL.' Overall, it provides solid behavioral context for a one-off scan tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (four sentences) and front-loaded: the first sentence states the core function, followed by rate limits, return value, and an alternative tool. Every sentence earns its place, including the documentation link, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is complete: it explains purpose, rate limits, expected output (scanId), the next step (guest_get_scan), and an alternative for a different use case. The agent has enough context to select and invoke the tool correctly without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full coverage for the single parameter 'url' with a clear description. The tool description adds little beyond the schema, though it reinforces that the URL must be public and supports http(s). Since schema coverage is 100%, the baseline of 3 is appropriate; the description does not meaningfully enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Run a free 6-test HTTP scan against a public URL without an API key.' It distinguishes from sibling tools by emphasizing the guest/no-account nature and explicitly mentions scanning a URL, which sets it apart from tools like guest_get_scan (polling) and create_target (continuous monitoring).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit alternative: 'For continuous monitoring, sign up free and use create_target.' It also directs the user to poll with guest_get_scan, establishing when to use this tool versus follow-up tools. The context of a quick, guest, rate-limited scan is clear, and the exclusion of continuous monitoring is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
import_targetsImport TargetsAInspectBulk import up to 100 websites for monitoring. Each URL gets a target created with auto-enabled tests, initial scan, and screenshot capture. Partial success — failed URLs are reported individually without blocking others.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Array of targets to import |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully compensates by disclosing key behaviors: auto-enabled tests, initial scan, screenshot capture, and the crucial partial success semantics where failed URLs are reported without blocking others. This is specific and useful for an agent, covering side effects and failure handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, starts with a clear action, and packs behavior details without redundancy. Every clause contributes to understanding the tool's scope and failure model.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter bulk import tool, the description adequately covers the operation's scope, individual target behavior, and error handling. The only minor gap is not describing the successful response format (e.g., created target IDs), but since there is no output schema, this is a slight omission rather than a critical defect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all parameters (url, name, type), so the description adds little beyond restating the URL-to-target mapping. The 'up to 100' limit is already present in the schema as maxItems, and the description does not introduce new parameter-specific details beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Bulk import up to 100 websites') and the outcome ('Each URL gets a target created'). It distinguishes itself from the sibling tool 'create_target' by emphasizing bulk quantity and the combined setup behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Bulk import' phrasing and the explicit 100-item limit imply batch usage, making it clear that this is for multi-target scenarios. However, it does not explicitly mention the alternative 'create_target' for single imports or any exclusion criteria, leaving the guidance slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_automation_rulesList Automation RulesAInspectList all automation rules for the team. Rules automatically react to events (test failures, incidents, downtime) with configurable actions (escalate severity, suppress, rerun, webhook, notify).
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | No | Filter by enabled/disabled status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that rules react to events with configurable actions, which adds useful context about the resource itself. However, it does not disclose behaviors like pagination, ordering, default filter behavior when 'enabled' is omitted, or the response format. For a read-only list tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first is front-loaded with the core action and scope; the second provides valuable context about automation rules without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description sufficiently explains what the tool does and what the resource represents. It could mention return values or response format, but given the low complexity, the description is reasonably complete. The absence of output schema raises the bar slightly, but the tool's simplicity mitigates the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter ('enabled'), which already includes 'Filter by enabled/disabled status'. The description adds no additional semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List all automation rules for the team.' This clearly distinguishes it from sibling tools like get_automation_rule (which fetches a single rule) and create_automation_rule. It also adds context about what automation rules do, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for the team' establishes scope, and the description implies this is the appropriate tool for enumerating automation rules. It does not explicitly mention alternatives or exclusions, but for a simple list operation, the context is clear enough to guide usage. The filter parameter for enabled status is also hinted by the description's 'List all', implying optional filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_findingsList FindingsAInspectList findings (discovered issues) across your targets. Filter by status, severity, or target. Returns title, severity, status, test name, and AI enrichment if available.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of findings to return | |
| status | No | Filter by finding status (default: OPEN) | |
| severity | No | Filter by severity | |
| targetId | No | Filter by target ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral transparency burden. It discloses the return fields and that AI enrichment is included 'if available', a useful caveat. However, it does not mention defaults like status=OPEN or limit=50, nor explicitly state it's a read-only operation, leaving some behaviors implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and every phrase adds value. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists the key return fields and filter options. For a simple list tool with fully documented parameters, this is reasonably complete. It could clarify default behavior or the meaning of 'AI enrichment', but overall it covers the essential aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions filterable dimensions (status, severity, target) which map to parameters but adds no extra meaning beyond the schema's own descriptions. No additional syntax or format detail is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('findings'), clarified as 'discovered issues', distinguishing it from sibling list tools like list_incidents and list_targets. It immediately conveys the tool's scope and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool lists findings 'across your targets' and supports filtering by status, severity, or target. This provides clear context for when to use it, though it does not explicitly mention alternatives or exclusions (e.g., use get_finding for a single finding).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_incidentsList IncidentsAInspectList incidents (grouped operational issues) across your targets. Filter by status. Returns title, severity, status, findings count, and deployment correlation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of incidents to return | |
| status | No | Filter by incident status | |
| targetId | No | Filter by target ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that it is a listing operation and lists returned fields. However, it does not explicitly state read-only behavior, default behavior when status is omitted, or whether targetId is required for cross-target scope. Some behavioral traits are implied but not fully specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-sentence structure: the first sentence states the action and scope, and the second lists return fields and filter. Every word contributes meaning, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain return values. It mentions title, severity, status, findings count, and deployment correlation, but does not describe pagination, default limit behavior, or the overall response structure. It is adequate for a simple list tool but leaves some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline 3. The description mentions 'Filter by status', which aligns with the status parameter, and 'across your targets' implies targetId context, but it adds little semantic value beyond the schema's existing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it lists incidents, defines them as 'grouped operational issues', and indicates scope 'across your targets'. It also mentions filtering by status and the return fields, which distinguishes it from tools like get_incident and list_findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it lists incidents across targets and supports status filtering. It implies multiple-incident retrieval, contrasting with get_incident for single incidents, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_journeysList JourneysAInspectList custom browser test flows (journeys) for a target or all team targets. Journeys are multi-step Playwright tests that verify user flows like checkout, login, and search.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | No | Filter by target ID. If omitted, lists all team journeys. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It accurately describes a read-only listing operation and defines journeys, but doesn't disclose details like return payload shape or whether it includes archived/inactive journeys. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and scope, second provides useful domain context about journeys. No filler, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description covers what it does, scope, and what journeys are. It lacks explicit return format, but that's implied for a list operation; minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for targetId ('Filter by target ID. If omitted, lists all team journeys'). The tool description adds no additional parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (custom browser test flows/journeys), and scope (target or all team targets), effectively distinguishing it from create/get/update/delete journey siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for enumerating journeys but does not explicitly contrast with get_journey or trigger_journey, nor specify when not to use it. The schema's targetId description adds filtering context but no alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_keywordsList Target KeywordsAInspectList all SEO keywords tracked for a target, including latest Google rank position. Max 50 per target.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the max 50 keyword limit, which is useful behavioral context, but it does not explicitly state whether the operation is read-only or describe behavior with zero keywords or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences fully convey the purpose and a key limit without any fluff. Information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is fairly complete. It states what is listed and the 50-item cap, but could be improved by explicitly noting the response format or whether the result is a list of objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with targetId already described. The description adds minimal extra meaning by stating 'for a target', but this largely restates the schema. Baseline 3 is appropriate since the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all SEO keywords tracked for a target, with a specific verb and resource. It distinguishes itself from sibling tools like add_keyword/remove_keyword and from list_targets, which list targets rather than keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use to retrieve keywords for a specific target. It does not explicitly mention alternatives or when not to use, but the primary use case is obvious from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_load_testsList Load Test HistoryAInspectList recent load test runs for a target.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results | |
| targetId | Yes | The target ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds context by noting 'recent' and 'for a target', implying filtering and time-based ordering. However, it does not disclose ordering details, whether it is read-only, or any limits/pagination behavior 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that directly conveys the tool's purpose. No filler or redundant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits clarifications that would help an agent distinguish it from sibling list tools (e.g., how it relates to 'list_runs'). It also doesn't explain the meaning of 'recent' or return value structure, but given the simple schema and no output schema, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented. The description adds minimal value by reinforcing that 'targetId' is the target filter, but does not introduce any new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' with a specific resource ('load test runs') and scope ('for a target'). It distinguishes from siblings like 'list_runs' by being load-test-specific and target-scoped, and from 'get_load_test' which is singular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_runs' or 'active_runs'. The context is only implied by the name and description; there are no exclusionary or alternative-recommendation statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_maintenance_windowsList Maintenance WindowsAInspectList maintenance windows for a target. Shows scheduled and recurring maintenance periods that suppress alerts.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains that listed windows suppress alerts, which is useful behavioral context. Yet it does not explicitly confirm there are no side effects, though the verb 'List' implies a safe read operation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences fully describe the purpose and key behavior without any redundant wording. The description is front-loaded with the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description provides sufficient context: what is listed, scoping, and the alert-suppression effect. Since there is no output schema, a bit more detail on return values could help, but the description is adequate for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with targetId described as 'The target ID'. The description does not add additional parameter context, but the schema fully covers the single parameter, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (List) and resource (maintenance windows), scoped to a target. The added detail about showing scheduled and recurring periods that suppress alerts distinguishes it from general list tools and other maintenance operations like create_maintenance_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a target' implies the tool is used to retrieve maintenance windows associated with a specific target. However, it does not explicitly state when to use this tool versus alternatives like list_automation_rules or delete_maintenance_window, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_notification_channelsList Notification ChannelsAInspectList all notification channels (Email, Slack, Webhook, SMS, Web Push) configured for the team. Sensitive config values are redacted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that sensitive config values are redacted, which is valuable behavioral context. However, it does not explicitly state read-only behavior, output format, or whether inactive channels are included, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose and followed by a single behavioral note. Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list tool, the description provides sufficient context: scope (team), channel types, and a key output behavior (redaction). It could mention what fields are returned, but the lack of an output schema is offset by the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the schema is trivially covered. The description adds meaningful context by listing channel types, which helps the agent understand the resource domain. The baseline for zero parameters is 4, and the description earns that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists notification channels and enumerates the specific types (Email, Slack, Webhook, SMS, Web Push). This specific verb-resource pairing distinguishes it from sibling tools like list_notification_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (team-configured channels, read-only listing) but does not explicitly state when to use this over alternatives or when not to use it. Sibling tools like list_notification_rules are not mentioned, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_notification_rulesList Notification RulesAInspectList all notification alert rules for the team. Rules map event types + severity levels to notification channels.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the operation lists all rules for the team, implying a read-only, team-scoped behavior. However, it does not mention permissions, pagination, response format, or other behavioral specifics that would be useful for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized at two sentences. The first sentence front-loads the action and scope; the second adds useful context about rule composition. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description provides the core purpose and a conceptual model of the returned rules. It lacks explicit return format details, but given the simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter details, and it does not, but no parameter information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (notification alert rules), and the scope (for the team). The second sentence explains what rules are, distinguishing this from sibling tools like list_notification_channels and list_automation_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to see all notification rules, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No sibling tools are referenced for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_page_fragmentsList Page FragmentsAInspectList all reusable page fragments for the team. Fragments are shared step sequences (e.g. "Login", "Dismiss Cookies") that can be inserted into multiple Journeys via the use_fragment action.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, what the return format is, or whether any authentication or special permissions are required. For a simple list tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only two sentences. The first states the core purpose, and the second adds valuable context about what fragments are. Every sentence earns its place, and the main verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description provides sufficient context: it explains the scope ('for the team') and the domain concept (fragments as shared step sequences). However, it does not describe the return structure, which would be helpful but is not critical for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and per the rubric, a baseline of 4 applies for 0-parameter tools. The description rightly omits parameter details, and the schema already documents that there are no properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'List all reusable page fragments for the team.' It also explains what page fragments are and their purpose, distinguishing this from other fragment-related tools like create/delete/update_page_fragment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about fragments being reusable step sequences, implying this tool is for viewing existing fragments. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions (e.g., 'use create_page_fragment to add new ones'). The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_runsList RunsAInspectList recent test runs. Filter by target, status, or test slug. Returns run status, score, summary, duration, and finding count.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of runs to return | |
| status | No | Filter by run status | |
| targetId | No | Filter by target ID | |
| testSlug | No | Filter by test definition slug (e.g. "security-headers") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It clearly states the return fields (status, score, summary, duration, finding count), but does not disclose ordering, pagination limits, or access scope. It is adequate for a read-only list, but not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose and followed by return information. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description still manages to cover the main purpose, filters, and return fields, which is sufficient for a list operation. It could benefit from mentioning default ordering or pagination behavior, but it is largely complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% descriptive coverage for all parameters, so the description's mention of filters adds minimal value beyond what the schema already documents. The phrase 'recent' hints at a default ordering, but it does not provide additional parameter syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List recent test runs.' It also clarifies the allowed filters (target, status, test slug) and what is returned, making its purpose unambiguous. It distinguishes itself from siblings like get_run (single run) and active_runs (currently running runs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use it for recent runs and mentions filter capabilities, but it does not explicitly state when not to use it or suggest alternatives like active_runs. The context is present but exclusions are not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_scheduled_reportsList Scheduled ReportsAInspectList all scheduled reports for the team. Reports are automatically generated and emailed on a daily or weekly basis.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions that reports are automatically generated and emailed, which describes scheduled reports themselves, not the listing operation's behavior (e.g., read-only, return format, pagination). This is insufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and scope, and contains no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter list operation, the description provides enough context: it lists all reports for the team and notes the cadence. Lacking output schema, it could be more specific about return fields, but the complexity is low, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no responsibility to explain parameters. Baselines for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all scheduled reports for the team, using a specific verb ('List') and resource ('scheduled reports'). It is distinct from sibling tools like create/update/delete_scheduled_report and other list_* tools by specifying 'scheduled reports'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use case: when you need to see all scheduled reports. It doesn't explicitly mention when not to use or alternative tools, but context makes it clear. Since no other list_scheduled_reports exists, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_secretsList Target SecretsAInspectList secrets stored in a target's vault. Values are masked — only key names and labels are shown. Secrets are used by test plugins (e.g. LOGIN_EMAIL, LOGIN_PASSWORD for B2B shops, ga4_service_account for GA4).
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly states that values are masked and only key names/labels are returned, which is a key safety trait. It does not mention pagination or auth, but for a simple list operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function and masking, the second explains practical use with concrete examples. Every sentence contributes value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list with one parameter and no output schema, the description covers the purpose, output expectations (masked keys and labels), and usage rationale with examples. It does not describe potential errors or pagination, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes targetId ('The target ID'), so schema coverage is 100%. The description adds minimal extra meaning about the parameter by referencing the 'target's vault', but this is marginal. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('List') and resource ('secrets stored in a target's vault'), distinguishing it from secret-management siblings like delete_secret, store_secret, and rotate_secret. It also adds important scope ('target's vault') and result details (values masked, only key names and labels shown).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context about when this tool is relevant (secrets used by test plugins) and implies its role in inspecting available secret keys. However, it does not explicitly state exclusions or name alternative tools for different use cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_targetsList TargetsAInspectList all monitoring targets for your team. Returns name, URL, type, status, and uptime info for each target.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by target type | |
| limit | No | Max number of targets to return | |
| status | No | Filter by target status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It does disclose the return fields (name, URL, type, status, uptime), but it does not disclose that the limit parameter caps the result set, making the word 'all' potentially misleading. There is also no mention of pagination or other behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the action and immediately state the return contents. Every word is informative, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with three optional parameters, the description covers the essential return fields, but it omits that the default limit of 50 may prevent returning 'all' targets. It also does not clarify how filtering by type/status interacts with the result set, though the schema provides parameter details. The lack of an output schema makes the return-field disclosure useful, but the 'all' wording creates a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of the parameters (type, limit, status) with clear semantics, so the baseline is 3. The description does not add any parameter-related meaning beyond what the schema already provides; it only mentions return fields, which are not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and a clear resource ('monitoring targets for your team'), making the operation unambiguous. It distinguishes itself from sibling tools like get_target (single target), create_target, and delete_target by clearly indicating a bulk read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that get_target should be used for a single target, or that list_tests handles a different resource, nor does it state any exclusions or prerequisites. The reader must infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_testsList Test DefinitionsAInspectList all available test definitions (plugins). Shows slug, name, category, runner type, weight class, schedule, and enablement status. Useful for knowing which tests can be triggered.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by test category | |
| enabledOnly | No | Only show enabled tests. Default: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the output fields and general purpose, but does not clarify the default filtering behavior (enabledOnly=true) or explicitly state that it is a read-only operation. The phrase 'all available' could mislead given the default filter, so it provides some but not full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and output details, with no filler or redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and no annotations, the description is largely complete: it lists the output fields and states the use case. Minor ambiguity around 'all available' vs. the enabledOnly default prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already documents them. The description does not add extra meaning to the parameters, instead focusing on output fields. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all available test definitions (plugins)' with a specific verb and resource. It also lists the fields shown and distinguishes it from sibling tools like list_load_tests or trigger_test, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Useful for knowing which tests can be triggered.' This implies when to use it, but it does not explicitly contrast with alternatives or state when not to use it. No exclusions are mentioned, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mute_findingMute FindingAInspectMute an open finding to suppress it from dashboards and alerts. Status changes from OPEN to MUTED.
| Name | Required | Description | Default |
|---|---|---|---|
| findingId | Yes | The finding ID to mute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the status transition from OPEN to MUTED and the suppression effect, which is valuable. However, it omits other behavioral traits such as reversibility, idempotency, or permission requirements, which would be expected for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains zero filler. Every word contributes to understanding what the tool does and its outcome.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema and no annotations, the description provides the essential purpose and effect. It lacks some contextual detail (e.g., behavior when finding is not open), but the overall picture is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter (findingId) with 100% coverage: 'The finding ID to mute'. The description does not add any additional parameter-specific details beyond the implicit requirement that the finding must be open, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mute an open finding'), the resource (finding), and the intended effect (suppress from dashboards and alerts, status changes to MUTED). It distinguishes itself from sibling tools like get_finding, list_findings, and create_muting_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: only open findings should be muted, and the purpose is to suppress from dashboards and alerts. It does not explicitly mention alternatives or exclusions (e.g., for broader muting rules), but the 'open' condition and outcome give enough situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recompute_scoresRecompute Composite ScoresAInspectForce recompute all composite scores (Security, SEO, Performance, Accessibility) for a target. Useful after manual changes or when scores seem stale.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID to recompute scores for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is forced and affects all listed composite scores, and hints at a use case. However, it does not mention side effects (e.g., overwriting existing scores), asynchronous behavior, permissions, or other potential impacts of a 'force' operation, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the action and scope, the second gives practical usage. Every word earns its place; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter operation with no output schema or annotations, the description covers what, why, and when. It does not explicitly describe the return value or postconditions, but this is a minor gap given the simplicity and the action-oriented nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for targetId is 100% clear, so the description need only add context. The description references 'a target' but adds no new parameter-level detail beyond what the schema already provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Force recompute') applied to a resource ('all composite scores') and specifies which sub-scores (Security, SEO, Performance, Accessibility). It differentiates from sibling read-only tools like get_target_scores by emphasizing the recompute/refresh nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context ('after manual changes or when scores seem stale'), though it does not explicitly name alternatives or state when not to use it. This is sufficient for a straightforward recompute operation given sibling tools like get_target_scores exist for reading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_deploymentRecord DeploymentAInspectRecord a deployment event for a target. Deployments are auto-correlated with incidents created within 20 minutes. Useful for tracking releases and root-cause analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Version string, e.g. "v2.4.1" | |
| targetId | Yes | The target ID | |
| commitSha | No | Git commit SHA | |
| deployedBy | No | Who deployed (name, email, or system) | |
| description | No | Deployment description or changelog | |
| environment | No | Environment, e.g. "production", "staging" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It goes beyond a simple write operation by disclosing the key non-obvious side effect: deployments are auto-correlated with incidents created within 20 minutes. This is valuable behavioral context. It omits other details like idempotency or overwrite behavior, but the disclosed correlation is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the action, the second adds valuable context. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with full schema coverage and no output schema, the description is sufficient. It explains the purpose, the benefit, and a key behavior (incident correlation). The only gap is not specifying the return value, but that is not critical for a recording action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning, but the schema already documents all properties clearly. No compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Record' with a clear resource ('deployment event') and target scope. There is no other deployment-related tool among siblings, making this tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'useful for tracking releases and root-cause analysis,' implying when to use it, and the mention of incident correlation gives practical context. However, it does not explicitly name alternatives 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.
remove_keywordRemove KeywordBInspectRemove an SEO keyword from a target.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID (for access verification) | |
| keywordId | Yes | The keyword ID to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the basic removal action and does not mention irreversibility, side effects, access requirements, or return values, which would be relevant for a deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It conveys the essential purpose without unnecessary detail, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple delete with two well-documented parameters and no output schema, so the description is minimally adequate. However, it lacks usage guidance and behavioral transparency, which prevents it from being fully complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (keywordId and targetId), and the schema coverage is 100%. The tool description adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (remove), the object (an SEO keyword), and the context (from a target). This distinguishes it from sibling tools like add_keyword and list_keywords, which perform different actions on keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or preferred contexts, leaving the agent to infer usage solely from the action name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_incidentResolve IncidentAInspectResolve an incident to mark it as handled. Changes status to RESOLVED and sets the closed timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| incidentId | Yes | The incident ID to resolve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses the key state change (status becomes RESOLVED) and that a closed timestamp is set, which are crucial side effects. It does not mention permissions or reversibility, but for a simple state transition this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences to convey purpose and effects. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single required parameter, no output schema), the description is complete. It covers the action, the resource, and the state changes, which is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as incidentId is fully described. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to resolve an incident, marking it as handled. It names the specific resource (incident) and the action (resolve), and distinguishes it from sibling tools like acknowledge_incident by specifying the status change to RESOLVED and setting a closed timestamp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when an incident has been handled) and what it does, but it doesn't explicitly contrast with acknowledge_incident or other incident-related tools. It provides clear context for its use, though not explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rotate_secretRotate SecretCInspectUpdate the value of an existing secret.
| Name | Required | Description | Default |
|---|---|---|---|
| newValue | Yes | New secret value | |
| secretId | Yes | The secret ID to rotate | |
| targetId | Yes | The target ID (for access verification) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the mutation (updating a value) but does not mention permissions, side effects, reversibility, or return behavior. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action with zero waste. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema. The description does not explain the purpose of targetId beyond what the schema says, nor does it describe return values or side effects. Given the tool's complexity (3 required parameters) and the absence of structured safeguards, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides. The schema itself thoroughly documents each parameter, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing secret's value, using a specific verb and resource. It distinguishes itself from siblings like store_secret (creating new) and delete_secret (removing), though it does not explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The phrase 'existing secret' implies it is for updating, not creating, but there is no mention of alternatives or exclusions, leaving the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_load_testStart Load TestAInspectStart a load test against a target. Max 100 concurrent connections, max 5 min duration, 1 test at a time per target, 60s cooldown between tests. Modes: HTTP_FLOOD (autocannon), BROWSER_USERS (Playwright), COMBINED (both). OWNER/ADMIN only.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Load test mode | HTTP_FLOOD |
| rampUp | No | Ramp-up time in seconds | |
| duration | No | Test duration in seconds | |
| targetId | Yes | The target ID to load test | |
| targetUrl | No | Override URL (defaults to target URL) | |
| httpMethod | No | HTTP method | |
| concurrency | No | Number of concurrent connections | |
| acknowledgeSharedOrigin | No | Acknowledge blast radius if target shares a server with other monitored sites |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It effectively communicates safety limits (100 connections, 5 min duration, 1 test at a time, 60s cooldown), permission requirements (OWNER/ADMIN only), and mode-specific tooling (autocannon, Playwright). It stops short of describing response behavior or error scenarios, but covers critical operational boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense, purposeful sentences. Each sentence adds distinct information: action, limits, modes, and permissions. No fluff or repetition; front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 8-parameter tool with no output schema, the description covers key operational constraints, permissions, and modes. It doesn't elaborate on each parameter but the schema does. It could mention the response shape or next steps (e.g., get_load_test), but the description is sufficient for starting a load test.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds value by explaining mode enum values with underlying tools and mentioning real-world constraints (cooldown, one-at-a-time) not present in the schema. It also reinforces concurrency and duration limits aligned with schema min/max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Start a load test against a target', using a specific verb and resource. It clearly distinguishes from sibling tools like cancel_load_test or get_load_test by focusing on the initiation action, and further details modes and constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational context: max concurrency, duration, single test per target, cooldown, modes, and OWNER/ADMIN permission. It does not explicitly state exclusions or compare directly to alternatives like trigger_test, but the limits and constraints give strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
store_secretStore SecretAInspectStore an encrypted secret in a target's vault. Common keys: LOGIN_EMAIL, LOGIN_PASSWORD (B2B shop auth), ga4_service_account (GA4 monitoring). Values are AES-256-GCM encrypted at rest.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Secret key (e.g. LOGIN_EMAIL) | |
| label | Yes | Human-readable label | |
| value | Yes | Secret value (will be encrypted) | |
| targetId | Yes | The target ID | |
| description | No | Optional description | |
| environment | No | Environment scope | PRODUCTION |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds an important fact—values are AES-256-GCM encrypted at rest—which is non-obvious and useful. However, it does not mention whether storing a secret overwrites an existing one, required permissions, or any side effects, leaving notable gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately front-loads the core purpose, and every word earns its place. It avoids fluff and technical repetition while providing useful context about keys and encryption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description covers the core purpose, encryption, and common usage examples. It does not explain return values or address optional parameters like environment, but the schema descriptions fill some gaps, making it reasonably complete for a store operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by explaining common key names and their contexts (e.g., LOGIN_PASSWORD for B2B shop auth), which helps users choose appropriate parameter values beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores an encrypted secret in a target's vault, using a specific verb ('store') and resource ('encrypted secret' in 'target's vault'). This distinguishes it from sibling tools like delete_secret and rotate_secret, and the mention of common keys adds further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (storing secrets) and gives common key examples with context ('B2B shop auth', 'GA4 monitoring'), but it does not explicitly name alternatives or state when not to use it. Since no exclusions or comparisons to siblings are provided, it only offers implied usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
system_healthSystem HealthAInspectGet a comprehensive system health report: BullMQ queue depths, active/stuck runs, user sessions, notification delivery stats, and recent error counts. Requires admin scope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly implies a read-only operation ('Get') and adds the admin scope requirement. It also lists the types of data covered, which gives useful behavioral context. However, it does not disclose potential side effects (none expected), error behavior without admin scope, or response format, which keeps it from being fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and every phrase adds value. It lists the report contents in a compact, readable list and states the admin requirement without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the essential context: what the report includes and its access restriction. It does not describe the output structure, but since the report categories are enumerated, an agent can infer reasonable usage. The lack of output schema is offset by the clear enumeration of report sections.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters (empty schema), so the description is not required to elaborate on parameters. The baseline for zero parameters is 4, and the description correctly focuses on what the report contains rather than input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('comprehensive system health report'), and enumerates the specific content (BullMQ queue depths, active/stuck runs, user sessions, notification delivery stats, recent error counts). This distinguishes it from sibling tools like active_runs or list_runs, which are narrower in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (when a general health report is needed) and sets an important prerequisite ('Requires admin scope'). However, it does not explicitly mention when not to use it or point to alternatives for more specific metrics, leaving room for a bit more guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
target_statsTarget StatisticsAInspectGet statistics for a specific target: runs, pass rate, findings, duration. Supports lifetime, monthly, or weekly periods.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Period filter: "lifetime", "2026-04" (monthly), or "2026-W14" (weekly). Defaults to lifetime. | |
| targetId | Yes | The target ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavior disclosure. 'Get statistics' implies a read-only operation, and the description explicitly lists outputs and supported periods. While it does not mention rate limits or authentication, for a presumably stateless read endpoint, this is sufficient and clearly non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose and outputs, the second covers the period parameter. It is front-loaded with the key facts and has zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two params, no output schema), the description covers the essential use case: what it returns and the supported time periods. It stops short of describing return format or units, but with no output schema and the explicit list of metrics, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because both targetId and period have descriptions. The description adds no new parameter meaning beyond what the schema already specifies; mentioning 'lifetime, monthly, or weekly periods' merely restates the schema's period examples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'statistics for a specific target', listing the types of statistics returned (runs, pass rate, findings, duration). This distinguishes it from sibling tools like team_stats or get_target_scores by scoping to a specific target, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need aggregate statistics for one target, and it mentions the supported periods (lifetime, monthly, weekly). However, it does not explicitly differentiate from alternative tools like daily_trends or list_runs, nor does it state exclusions such as 'for team-wide stats, use team_stats'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
team_statsTeam StatisticsAInspectGet team-wide overview statistics: total runs, pass rate, open findings, open incidents, average duration. Supports lifetime, monthly, or weekly periods.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Period filter: "lifetime", "2026-04" (monthly), or "2026-W14" (weekly). Defaults to lifetime. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently lists the output fields and period formats, but does not mention potential caveats like default period behavior (already in schema) or any access/permission requirements. This is adequate for a simple read-only stats tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists the key statistics and period support without any filler. Every word earns its place, making it exceptionally concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description enumerates the returned metrics and defines the period argument. Combined with the schema's detailed parameter documentation, this fully covers what an agent needs to understand the tool's scope and invocation. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single 'period' parameter, including examples and a default. The description's mention of 'lifetime, monthly, or weekly periods' adds compatibility but not semantically new information beyond the schema. Per the rubric, high schema coverage yields a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'team-wide overview statistics' and enumerates the exact metrics returned. This distinguishes it from sibling tools like target_stats (target-specific) and daily_trends (trends over time), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool's scope ('team-wide') and the supported time periods ('lifetime, monthly, or weekly'), which implies when to use it for team-level overviews. However, it does not explicitly contrast with alternatives like target_stats or mention when not to use it, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trigger_all_testsTrigger All TestsAInspectRun all enabled tests against a target as a scan workflow. All tests in the target's test profile are queued. Returns the workflow ID and list of queued runs.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID to scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that tests are 'queued' and that it returns a workflow ID and list of queued runs, which gives useful behavioral insight. However, it does not explain permissions, potential side effects on the target, or what a 'scan workflow' entails beyond queuing, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and scope, and contains no filler. Every sentence adds value: what it does, how it behaves, and what it returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the trigger action, queuing behavior, and return values. It does not elaborate on the scan workflow concept or edge cases like disabled tests, but it provides enough information for correct invocation and expectation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter 'targetId' as 'The target ID to scan'. The description reinforces that the target is the one whose test profile is used but adds no new syntax or format details beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run all enabled tests against a target as a scan workflow', specifying the action, resource, and scope. It distinguishes itself from the sibling 'trigger_test' by indicating this triggers all tests in the target's test profile, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for running all enabled tests as a scan workflow, implying it is the bulk-action alternative to single-test triggers. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trigger_journeyTrigger JourneyAInspectExecute a journey (custom browser test flow) against its target. The journey runs asynchronously — use get_run to check progress.
| Name | Required | Description | Default |
|---|---|---|---|
| journeyId | Yes | The journey ID to trigger |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly discloses the asynchronous behavior and provides a follow-up action (use get_run). While it lacks details on side effects or permissions, the async disclosure is a significant behavioral trait that goes 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences. First sentence states the action and target, second gives the essential async caveat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-param tool with no output schema, the description explains the async behavior and next steps, but does not explicitly state what the tool returns (e.g., a run ID to pass to get_run). This is a gap given the output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (journeyId is described as 'The journey ID to trigger'), so the baseline is 3. The description does not add extra semantics beyond the schema, but the schema already fully explains the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Execute' and identifies the resource as 'a journey (custom browser test flow)', distinguishing it from siblings like trigger_test. It clearly states the action against the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: the journey runs asynchronously and directs the user to use get_run to check progress. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trigger_testTrigger TestAInspectRun a specific test against a target. Specify either the test definition ID or slug. The test is queued and executed asynchronously — use get_run to check status.
| Name | Required | Description | Default |
|---|---|---|---|
| testId | No | Test definition ID (use this or testSlug) | |
| targetId | Yes | The target ID to test | |
| testSlug | No | Test slug e.g. "security-headers" (use this or testId) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of revealing behavior. It discloses that the test is queued and executed asynchronously and points to get_run for status, which is a key behavioral trait. It could additionally state the return format or error conditions, but the core behavior is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler, immediately stating the action and then the key operational detail. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple trigger tool with no output schema, the description covers the main actions, parameter selection, asynchronous execution, and follow-up via get_run. Minor omissions like explicitly stating the required targetId or return value are covered by the schema or implied, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters with 100% coverage. The description's phrase 'Specify either the test definition ID or slug' reinforces the mutual exclusivity already stated in the schema but adds no new semantic nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a specific test against a target', identifying the action and resource. It distinguishes from siblings like trigger_all_tests by emphasizing 'specific test', and from get_run by positioning itself as the initiation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for running a single predefined test, and it directs the user to get_run for checking status. It does not explicitly mention alternatives like trigger_all_tests or trigger_journey, but the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_automation_ruleUpdate Automation RuleAInspectUpdate an existing automation rule. Any field not provided will remain unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Updated rule name | |
| ruleId | Yes | The automation rule ID to update | |
| actions | No | Updated actions | |
| trigger | No | Updated trigger event | |
| targetId | No | Updated target scope (null to remove target scoping) | |
| isEnabled | No | Enable or disable the rule | |
| conditions | No | Updated conditions | |
| priorityOrder | No | Updated priority order |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the important partial-update behavior ('Any field not provided will remain unchanged'), which is valuable context. However, it does not mention side effects, idempotency, return value, or authorization requirements, leaving gaps expected for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and every word earns its place. The partial-update clarification is concise and materially useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (8 params, nested objects, enums), the schema covers the parameter space well. The description adds the critical partial-update semantic, which is often omitted. No output schema exists, so return value explanation isn't required, but the description could still mention expected outcomes (e.g., success/failure behavior). Overall, it is sufficiently complete for a simple CRUD update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add parameter-specific semantics beyond the generic partial-update note, which is already clear from the schema and overall description. Baseline 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing automation rule'), using a specific verb+resource construction. It distinguishes itself from sibling tools like create_automation_rule, delete_automation_rule, and get_automation_rule by explicitly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this tool is for updating existing rules, which implies it should be used when a rule already exists, but it does not explicitly mention alternatives or exclusions (e.g., 'use create_automation_rule for new rules'). The partial-update behavior ('Any field not provided will remain unchanged') provides context on how to use it, but no explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_journeyUpdate JourneyAInspectUpdate a journey's name, settings, or steps. When steps are provided, all existing steps are replaced.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Updated name | |
| steps | No | Replacement steps (replaces all existing steps) | |
| isEnabled | No | Enable or disable the journey | |
| journeyId | Yes | The journey ID to update | |
| description | No | Updated description | |
| timeoutSeconds | No | Updated timeout |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the important destructive behavior of replacing all existing steps when steps are provided, but this info is already in the schema. It does not mention authentication, permissions, or whether other fields are partially updated, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the main action and then provides the critical side-effect of steps replacement. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters and no output schema, this description is minimal. It tells what the tool does and one behavior, but does not clarify the meaning of 'settings', partial update semantics, or required fields (journeyId is only shown in schema). It is adequate but lacks completeness for an agent to fully understand the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already provides; it mentions 'name, settings, or steps' but does not explain specific parameters like isEnabled, description, or timeoutSeconds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update a journey's name, settings, or steps.' It uses a specific verb ('update') and resource ('journey'), and distinguishes it from sibling tools like create_journey, delete_journey, and get_journey by indicating that it modifies an existing journey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing journey but does not explicitly state when to use it versus alternatives or provide exclusions. It only mentions a behavioral nuance ('When steps are provided, all existing steps are replaced'), without guidance on partial updates or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_notification_ruleUpdate Notification RuleBInspectUpdate a notification rule. Only provided fields are changed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| ruleId | Yes | The notification rule ID | |
| enabled | No | ||
| eventTypes | No | ||
| severities | No | ||
| channelTypes | No | ||
| quietHoursEnd | No | ||
| quietHoursStart | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that only provided fields are changed, which is valuable, but it does not mention permissions, errors, return value, or any side effects. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, both useful. It is appropriately concise, front-loaded with the core purpose, and contains no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no output schema, and no annotations, yet the description provides very little context about expected behavior beyond partial update. It does not explain what happens on success, whether validation occurs, or how to interpret any response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13% (only ruleId is described). The description does not compensate for the missing parameter details. 'Only provided fields are changed' implies that optional fields can be sent, but it adds no specific meaning to parameters like eventTypes, severities, or quietHours.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('notification rule'), which distinguishes it from sibling tools like create_notification_rule and delete_notification_rule. The added phrase 'Only provided fields are changed' further clarifies the partial-update semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives such as create_notification_rule or delete_notification_rule. The verb 'Update' implies its use, but there is no mention of prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_page_fragmentUpdate Page FragmentAInspectUpdate a page fragment. When steps are provided, all existing steps are replaced.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Updated name | |
| steps | No | Replacement steps | |
| fragmentId | Yes | The fragment ID | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the transparency burden. It discloses the critical behavior that providing steps replaces all existing steps, which is valuable. However, it does not clarify whether other fields are partially or fully replaced, nor does it mention permissions or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the key caveat front-loaded. Every word earns its place and there is no redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, so the description carries a heavy burden. It covers the steps replacement behavior and the schema details well, but lacks explicit partial-update semantics for other fields and any mention of response or prerequisites, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 75% of parameters, but the description adds key semantic value by explaining that steps replace all existing steps. This goes beyond the schema's 'Replacement steps' wording and clarifies behavior for the most complex parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Update a page fragment') and clearly distinguishes this from sibling tools like create_page_fragment and delete_page_fragment. The added sentence about steps replacement reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when modifying an existing page fragment, and the steps replacement note provides important context. However, it does not explicitly mention when not to use it or direct users to create_page_fragment for new fragments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_scheduled_reportUpdate Scheduled ReportAInspectUpdate an existing scheduled report. Any field not provided stays unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Updated name | |
| enabled | No | Enable or disable the report | |
| hourUtc | No | Updated hour UTC | |
| reportId | Yes | The scheduled report ID to update | |
| dayOfWeek | No | Updated day of week | |
| frequency | No | Updated frequency | |
| recipients | No | Updated comma-separated email list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. 'Any field not provided stays unchanged' discloses partial-update semantics, which is valuable. However, it doesn't disclose permissions, error behavior, or return format, leaving some gaps for an update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter update tool with no output schema, the description covers the core behavior but omits the return value and error handling. Given no annotations to supplement, it could be more complete, though the partial-update note helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning to optional parameters via 'Any field not provided stays unchanged,' clarifying that omitting a field preserves its current value, which is not evident from the individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing scheduled report,' using a specific verb and resource, and differentiates from create/delete/list siblings. The phrase 'existing' reinforces not-creating semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (modifying an existing report) but doesn't provide explicit alternatives or exclusions. It does add a usage hint with 'Any field not provided stays unchanged,' indicating partial updates, but does not contrast with create_scheduled_report or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_targetUpdate TargetCInspectUpdate a target's properties (name, URL, type, environment, business weight, tags, uptime toggle).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | New URL | |
| name | No | New display name | |
| tags | No | New tags (replaces existing) | |
| type | No | New target type | |
| weight | No | New business weight: REVENUE_PATH, PUBLIC or INTERNAL. Changing this rescores the target's open findings so the consequence ranking updates immediately. | |
| targetId | Yes | The target ID to update | |
| environment | No | New environment | |
| uptimeEnabled | No | Toggle uptime monitoring | |
| uptimeKeyword | No | Keyword to verify in response body during uptime checks. When set, every uptime ping GETs the page and verifies this text appears (case-insensitive). If missing, the site is treated as DOWN even on HTTP 200. Set to null to disable keyword verification. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description merely lists updatable properties and does not disclose side effects or behavioral traits. For example, the schema reveals that changing 'weight' rescopes the target's open findings, and that 'uptimeKeyword' affects uptime checks, but the description itself does not mention these consequences. It also does not state whether the update is partial or full replacement, required permissions, or return behavior. With no annotations, this lack of information is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with a clear action verb and a list of properties. It is front-loaded and contains no wasted words. However, it is almost too terse, as it omits important behavioral context that could be woven into a slightly longer description without sacrificing conciseness. It earns a 4 for being efficient and well-structured, but not a 5 because it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex mutation tool with 9 parameters, no annotations, and no output schema. The description is minimal and does not orient the agent on when to use it, what side effects to expect, or what the return value will be. Although the schema richly documents parameters, the description itself fails to provide the higher-level context needed for an agent to correctly select and invoke the tool, especially given the absence of annotations. The tool's complexity demands more than a single sentence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning every parameter already has a detailed description in the input schema. The tool description adds no semantic value beyond listing the property names (name, URL, type, etc.), which are already present in the schema. According to the rubric, when schema coverage is high, the baseline score is 3, and the description does not raise it by providing additional context or clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update a target's properties') and lists the specific properties (name, URL, type, environment, business weight, tags, uptime toggle). This is a specific verb+resource combination that distinguishes it from create/delete/get targets. However, it does not explicitly differentiate from sibling tools like update_test or update_journey, though the resource 'target' is clear. A score of 4 reflects clear purpose without explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusion criteria, or situations where another tool (e.g., create_target, delete_target, update_test) would be more appropriate. There is no context such as 'use this to modify an existing target' or 'for bulk changes, use import_targets.' The description is purely a statement of functionality without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_team_settingsUpdate Team SettingsAInspectUpdate team configuration. All fields are optional — only provided fields are changed. Covers: AI enrichment (model, temperature, auto-enrich, spending cap), uptime (timeout, thresholds), severity escalation (recurrence/age triggers), run policies (concurrency, timeouts), SEO (rank tracking, keyword strategy), notification coalescing (digest), and the kill switch (testsPaused).
| Name | Required | Description | Default |
|---|---|---|---|
| aiModel | No | OpenAI model for finding enrichment (e.g. gpt-4o-mini) | |
| aiEnabled | No | Enable/disable AI finding enrichment | |
| aiCapAction | No | Action when cap is reached | |
| testsPaused | No | Kill switch — pauses ALL scheduled and manual test runs | |
| aiAutoEnrich | No | Auto-enrich new findings with AI | |
| digestEnabled | No | Enable notification alert coalescing | |
| aiMonthlyCapUsd | No | Monthly AI spending cap in USD (null = unlimited) | |
| aiSourceReviewModel | No | Model for AI source review plugin | |
| defaultRunTimeoutMs | No | Default run timeout in ms | |
| digestWindowSeconds | No | Digest window duration in seconds | |
| escalateInfoAgeDays | No | Finding age in days before INFO→WARNING | |
| seoRankCheckEnabled | No | Enable Google rank tracking | |
| uptimeFailThreshold | No | Consecutive failures before DOWN | |
| uptimePingTimeoutMs | No | Uptime ping timeout in ms | |
| escalateInfoRecurrence | No | Finding recurrences before INFO→WARNING | |
| escalateWarningAgeDays | No | Finding age in days before WARNING→CRITICAL | |
| defaultScheduleMultiplier | No | Schedule frequency multiplier (< 1 = more frequent) | |
| escalateWarningRecurrence | No | Finding recurrences before WARNING→CRITICAL | |
| uptimeDegradedThresholdMs | No | Response time threshold for DEGRADED status | |
| maxConcurrentRunsPerTarget | No | Max concurrent test runs per target |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the partial-update behavior and the presence of a 'kill switch (testsPaused),' which adds important context. However, it doesn't mention permissions, reversibility, or side effects on running tests, so it's adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured despite covering 20 parameters. It front-loads the core purpose, then a key behavioral note, then a parenthetical list of categories, all in one efficient paragraph. Every sentence contributes meaningful info with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 optional parameters, no output schema), the description does a good job of outlining the full scope and the partial-update semantics. It doesn't mention return values or error behavior, but with no output schema and a clear field list, this is a minor gap. It provides enough context for an 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 20 parameters (100% coverage), so the baseline is 3. The description adds value by grouping parameters into meaningful categories (e.g., 'severity escalation (recurrence/age triggers)') and emphasizing the optionality of all fields, which clarifies the update model. This elevates it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update team configuration,' which is a specific verb+resource combination. It enumerates the exact categories (AI enrichment, uptime, escalation, run policies, SEO, notifications, kill switch), making it clear what this tool does and distinguishing it from sibling update tools like update_target or update_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the scope (team configuration) and notes that 'All fields are optional — only provided fields are changed,' which is essential usage guidance. However, it doesn't explicitly state when not to use this tool or name alternatives, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_testUpdate Test DefinitionAInspectEnable or disable a test definition globally, or update its schedule/timeout. Requires admin scope.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Test plugin slug (e.g. "http-protocol-check") | |
| enabled | No | Enable or disable the test globally | |
| timeout | No | Timeout in milliseconds | |
| defaultSchedule | No | Cron schedule (e.g. "0 */6 * * *") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does mention the admin scope requirement, a useful permission hint, but it fails to describe side effects like whether disabling a test affects currently running runs, idempotency, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action, enumerates the update axes, and ends with the permission requirement. Nothing is redundant or wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is adequate for initial selection but leaves gaps about update semantics: whether partial updates are allowed, whether changes take effect immediately, and what the tool returns on success. It provides essential purpose and permission context but not operational completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all four parameters at 100% coverage, so the baseline is 3. The description adds semantic grouping by mapping the action 'enable/disable' to the 'enabled' parameter and 'schedule/timeout' to 'defaultSchedule' and 'timeout', helping the agent understand how parameters relate to intended operations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a test definition and enumerates specific capabilities: enabling/disabling globally and updating schedule/timeout. This distinguishes it from sibling tools like update_target or trigger_test, and makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need to modify a test's enabled state, schedule, or timeout) but does not explicitly say when not to use it or mention alternatives such as enable_all_tests for bulk operations. Usage context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!