Continuous website testing by Validoria — monitor security, SEO, performance, and accessibility.
Scored across 3 tools
The guest_start_scan/guest_get_scan pair is clearly split by action (start vs. poll), and discover_tools is a distinct meta-tool. However, discover_tools references call_read_tool and call_tool (plus a hidden mass of area tools) that are not part of this surface, so an agent cannot tell whether to use the dispatcher, the named tool, or a tool it cannot see.
All names are snake_case and follow a verb_noun shape (discover_tools, guest_start_scan, guest_get_scan), with a clean guest_ family prefix for the scan pair. The only oddity is that discover_tools is a generic meta-tool while the other two are domain-specific, but that is a minor deviation.
Only three tools are exposed, yet the description of discover_tools reveals a very large domain (automation rules, journeys, load tests, notifications, reports, secrets, SLA, admin, etc.) accessed through a generic dispatcher. That mismatch makes the surface both too thin and opaque relative to the server's apparent scope.
The guest flow is complete for a start/poll lifecycle, but there is no cancel/stop, no authenticated scan or target-creation tool (create_target is referenced but absent), and the many tool areas mentioned by discover_tools are not actually represented. Notable gaps remain for anything beyond a one-off anonymous scan.
Only everyday tools are listed; the rest (automation rules, journeys, load tests, maintenance, notifications, reports, secrets, keywords, SLA, settings, admin …) are found here. No arguments: every tool you can run, by area. query: matching tools with a summary, effect and parameters. tools: their full input schemas. Run one with call_read_tool (reads) or call_tool (changes), or by its own name.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | What you want to do, e.g. "maintenance window" or "mute alerts" | |
| tools | No | Tool names whose full input schema to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only (readOnlyHint=true). The description adds useful behavioral detail: query returns matching tools with summaries, effects, and parameters; tools returns full input schemas. It also indicates how to invoke discovered tools, which is helpful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the distinction between everyday and other tools, but the long parenthetical list of areas is somewhat cluttered. The parameter explanations and invocation guidance are useful but could be more tightly 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 discovery meta-tool with no output schema, the description does a good job explaining the output for each parameter mode and how to proceed after discovery. It does not mention limits like maxItems (e.g., 10 tools) or pagination, but those are covered by 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?
Schema coverage is 100%, but the description goes further by explaining what the query parameter yields (matching tools with summary, effect, and parameters) and what the tools parameter returns (full input schemas). This adds semantic value beyond the schema's brief 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 identifies this as a discovery tool for tools not in the everyday list, and explains what query and tools return. The opening sentence is a bit ambiguous about where tools are 'listed', but the overall purpose is clear enough for an agent to understand it as a tool search.
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 states that no arguments returns every tool by area, and explains how to run a discovered tool via call_read_tool, call_tool, or by name. This gives clear usage context, though it doesn't explicitly contrast with just calling tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll 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?
Annotations already declare readOnlyHint and openWorldHint=false, so the description is not carrying the safety burden. It does add genuinely non-obvious context beyond the annotations: that no API key is required and that the two ids come from the start response. It stops short of saying what a poll returns or whether an incomplete result is possible.
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?
Three short sentences, front-loaded with the action, then the inputs, then the auth note. Every sentence carries distinct information and nothing is padded.
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 should indicate what a poll returns (status field, completion indicator, partial results). It says only "poll results," leaving the return shape and polling-termination semantics to inference — a meaningful gap for a polling 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% — both scanId and guestSessionId are documented in the schema, including that they come from guest_start_scan. The description repeats that provenance but adds no new detail such as format, lifetime, or whether guestSessionId is optional in practice.
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?
States a specific verb and resource ("Poll results") and ties it directly to guest_start_scan, so the agent understands this is the retrieval counterpart to the start tool. It is not an explicit contrast with siblings (discover_tools is unmentioned), but the start/get pairing is clear enough to route correctly.
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?
"Poll results for a guest_start_scan" implies the tool is called after starting a scan and may be called repeatedly, but there is no explicit guidance on retry cadence, when to stop polling, or what to do if results are not yet ready. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run 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?
Goes well beyond the annotations: annotations only say it is non-read-only, open-world, non-idempotent and non-destructive, while the description discloses concrete rate limits (5/IP/hour, 3/session/day), the absence of an API key requirement, the fact that it is asynchronous, and that it returns a scanId requiring polling. Those are exactly the operational facts an agent needs before calling.
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 tight sentences, front-loaded with purpose, then limits, then the return/polling contract, then the upgrade path, and finally a docs pointer. No sentence is filler; each carries a distinct decision-relevant fact.
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, and the description compensates by stating the return value (scanId) and the follow-up call needed to retrieve results. Combined with the rate limits and the anonymous-access condition, nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%, so the schema already documents 'url' with format and an example. The description's phrase 'against a public URL' reinforces the constraint but adds no format, syntax, or validation detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run a free 6-test HTTP scan against a public URL') with the qualifying constraint 'without an API key'. It also distinguishes itself from siblings by naming guest_get_scan for polling and create_target for monitoring, so an agent can route correctly without opening any schema.
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?
Explicitly gives the when (free, anonymous, one-off scan of a public URL), the alternative (create_target for continuous monitoring), and the follow-up path (poll with guest_get_scan). It also states the exclusion implied by 'public URL' plus the rate-limit ceiling, which tells the agent when this tool will fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
accept_visual_baselineacknowledge_incidentactive_runsadd_keywordanalyze_targetcancel_load_testcreate_automation_rulecreate_journeycreate_maintenance_windowcreate_muting_rulecreate_notification_rulecreate_page_fragmentcreate_scheduled_reportcreate_targetdaily_trendsdelete_automation_ruledelete_journeydelete_maintenance_windowdelete_notification_ruledelete_page_fragmentdelete_scheduled_reportdelete_secretdelete_targetdisable_all_testsdiscover_toolsenable_all_testsget_automation_ruleget_findingget_incidentget_journeyget_load_testget_runget_site_mapget_targetget_target_scoresget_target_slaget_team_settingsimport_targetslist_automation_ruleslist_findingslist_incidentslist_journeyslist_keywordslist_load_testslist_maintenance_windowslist_notification_channelslist_notification_ruleslist_page_fragmentslist_runslist_scheduled_reportslist_secretslist_targetslist_testslist_visual_baselinesmute_findingrecompute_scoresrecord_deploymentremove_keywordresolve_incidentrotate_secretset_target_teststart_load_teststore_secretsystem_healthtarget_statsteam_statstrigger_all_teststrigger_journeytrigger_testupdate_automation_ruleupdate_journeyupdate_notification_ruleupdate_page_fragmentupdate_scheduled_reportupdate_targetupdate_team_settingsupdate_testaccept_visual_baselinelist_visual_baselinesupdate_target1 field changedInput schema / properties / uptimeKeyword / descriptionPrevious value: -"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."New value: +"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 (reported as \"keyword not found\"). Saving a keyword fetches the page once and is refused when the keyword is not on it. Set to null to disable keyword verification."update_team_settings1 field changedInput schema / properties / maxDailyRunsPerTarget / descriptionPrevious value: -"Max test runs per target per day (0=unlimited). Prevents overwhelming hosted sites with limited request budgets."New value: +"Max scheduled and adaptive test runs per target per UTC day (0=unlimited). Runs started by hand (app, MCP, API) are not counted or stopped. Prevents overwhelming hosted sites with limited request budgets."create_notification_rule1 field changedInput schema / properties / eventTypes / items / enumPrevious value: -[
- "INCIDENT_OPENED",
- "INCIDENT_RESOLVED",
- "INCIDENT_ACKNOWLEDGED",
- "FINDING_CREATED",
- "FINDING_RESOLVED",
- "FINDING_ESCALATED",
- "TARGET_DOWN",
- "TARGET_RECOVERED",
- "TEST_FAILED",
- "TEST_RECOVERED",
- "SCAN_COMPLETED",
- "BILLING_LIMIT_REACHED",
- "ACTION_REQUIRED"
-]New value: +[
+ "INCIDENT_OPENED",
+ "INCIDENT_RESOLVED",
+ "INCIDENT_ACKNOWLEDGED",
+ "FINDING_CREATED",
+ "FINDING_RESOLVED",
+ "FINDING_ESCALATED",
+ "TARGET_DOWN",
+ "TARGET_RECOVERED",
+ "TEST_FAILED",
+ "TEST_RECOVERED",
+ "SCAN_COMPLETED",
+ "BILLING_LIMIT_REACHED",
+ "ACTION_REQUIRED",
+ "SLA_BUDGET"
+]get_target_slaupdate_notification_rule1 field changedInput schema / properties / eventTypes / items / enumPrevious value: -[
- "INCIDENT_OPENED",
- "INCIDENT_RESOLVED",
- "INCIDENT_ACKNOWLEDGED",
- "FINDING_CREATED",
- "FINDING_RESOLVED",
- "FINDING_ESCALATED",
- "TARGET_DOWN",
- "TARGET_RECOVERED",
- "TEST_FAILED",
- "TEST_RECOVERED",
- "SCAN_COMPLETED",
- "BILLING_LIMIT_REACHED",
- "ACTION_REQUIRED"
-]New value: +[
+ "INCIDENT_OPENED",
+ "INCIDENT_RESOLVED",
+ "INCIDENT_ACKNOWLEDGED",
+ "FINDING_CREATED",
+ "FINDING_RESOLVED",
+ "FINDING_ESCALATED",
+ "TARGET_DOWN",
+ "TARGET_RECOVERED",
+ "TEST_FAILED",
+ "TEST_RECOVERED",
+ "SCAN_COMPLETED",
+ "BILLING_LIMIT_REACHED",
+ "ACTION_REQUIRED",
+ "SLA_BUDGET"
+]update_team_settings4 fields changedInput schema / properties / aiVisibilityMonthlyCapUsdAdded value: +{
+ "description": "AI visibility: monthly USD cap for all probes of the team (default 25)",
+ "maximum": 10000,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / aiVisibilityOpperModelAdded value: +{
+ "description": "AI visibility: Perplexity model through Opper (default sonar)",
+ "enum": [
+ "sonar",
+ "sonar-pro",
+ "sonar-reasoning-pro"
+ ],
+ "type": "string"
+}Input schema / properties / aiVisibilityOpperMonthlyCapUsdAdded value: +{
+ "description": "AI visibility: monthly USD cap for Perplexity through Opper, on top of the AI visibility cap (default 5)",
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / aiVisibilityOpperScheduledAdded value: +{
+ "description": "AI visibility: include Perplexity through Opper (US-routed, no zero-data-retention; probes send only public brand questions) in scheduled and full runs. Off (default) = asked only on demand with \"Ask Perplexity now\"",
+ "type": "boolean"
+}update_team_settings2 fields changedInput schema / properties / scoreGradedCoveragePctAdded value: +{
+ "description": "Composite scores: % of a category's test weight that must be freshly measured for the score to be GRADED (default 80)",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / scoreProvisionalCoveragePctAdded value: +{
+ "description": "Composite scores: below this % of fresh evidence a category is INSUFFICIENT and shows no number (default 60)",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+}set_target_testadd_keyword1 field changedInput schema / properties / pageUrlAdded value: +{
+ "description": "The page this keyword is written for (absolute URL on the site)",
+ "format": "uri",
+ "maxLength": 2048,
+ "type": "string"
+}update_team_settings1 field changedInput schema / properties / aiModel / descriptionPrevious value: -"OpenAI model for finding enrichment (e.g. gpt-4o-mini)"New value: +"Model id on the AI gateway for finding enrichment (e.g. mistral/mistral-small-2603, an EU route)"update_team_settings1 field changedInput schema / properties / maxDailyRunsPerTargetAdded value: +{
+ "description": "Max test runs per target per day (0=unlimited). Prevents overwhelming hosted sites with limited request budgets.",
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+}acknowledge_incidentactive_runsadd_keywordanalyze_targetcancel_load_testcreate_automation_rulecreate_journeycreate_maintenance_windowcreate_muting_rulecreate_notification_rulecreate_page_fragmentcreate_scheduled_reportcreate_targetdaily_trendsdelete_automation_ruledelete_journeydelete_maintenance_windowdelete_notification_ruledelete_page_fragmentdelete_scheduled_reportdelete_secretdelete_targetdisable_all_testsenable_all_testsget_automation_ruleget_findingget_incidentget_journeyget_load_testget_runget_site_mapget_targetget_target_scoresget_team_settingsguest_get_scanguest_start_scanimport_targetslist_automation_ruleslist_findingslist_incidentslist_journeyslist_keywordslist_load_testslist_maintenance_windowslist_notification_channelslist_notification_ruleslist_page_fragmentslist_runslist_scheduled_reportslist_secretslist_targetslist_testsmute_findingrecompute_scoresrecord_deploymentremove_keywordresolve_incidentrotate_secretstart_load_teststore_secretsystem_healthtarget_statsteam_statstrigger_all_teststrigger_journeytrigger_testupdate_automation_ruleupdate_journeyupdate_notification_ruleupdate_page_fragmentupdate_scheduled_reportupdate_targetupdate_team_settingsupdate_testWebsite performance monitoring: scans, Core Web Vitals, RUM data and alerts.
Website monitoring: uptime, checkout, SEO (Search Console, Bing), security, speed, DNS, compliance.
Security, SEO and AI-visibility scanner for web apps · free scans and focused checks via MCP.
Scan and monitor websites for leaked keys, exposed files, security headers, SEO issues and uptime.
Add one secure layer between your agents and this server.
