Website traffic, bot reports, realtime visitors and site health for your DevDome sites
Scored across 10 tools
The tools are mostly distinct: each get_* tool targets a different analytics view (real-time, timeseries, stats, visitors, bots, health, breakdown). However, the number of similarly prefixed reporting tools creates slight potential for confusion about which report answers a given high-level question.
All tool names follow a consistent snake_case verb_noun pattern (add_site, list_sites, verify_site, get_stats, etc.). The convention is predictable and readable throughout.
Ten tools is well within the ideal range and each tool covers a distinct site-management or analytics-reporting operation. The set is scoped appropriately for a website analytics service.
The surface covers site onboarding, verification, listing, and a solid range of traffic/health reports. Minor gaps exist, such as removing or updating a site and more advanced analytics features like goals or funnels, but core workflows are covered.
Add a website to the account. Returns the verification file to upload (verify_file_path + verify_content, served at /.well-known/devdome-analytics.txt); the site stays pending until verified.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The bare domain, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description goes beyond them by disclosing the state transition (site stays pending), the artifact returned (verify_file_path + verify_content), and where that artifact is served (/.well-known/devdome-analytics.txt) — real behavioral context. It stops short of mentioning idempotency or what happens on a duplicate domain.
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 compact sentences, front-loaded with the action and followed by the post-condition and return artifact. No filler or restatement of the title.
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 naming the returned verification fields and their serving path, plus the pending-until-verified state. It omits auth/permission requirements and behavior on an already-registered domain, but for a one-parameter create tool this is nearly 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?
With a single parameter at 100% schema description coverage, the schema already carries the meaning of 'domain' including the bare-domain format example. The description adds no syntax, normalization, or constraint detail beyond what the schema provides, so the 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?
States a specific verb and resource ('Add a website to the account') and immediately differentiates itself from the read-oriented siblings (list_sites, get_stats) by describing the create action and its verification lifecycle. An agent can tell this is the entry point for onboarding a new domain without opening the 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?
The lifecycle clause ('the site stays pending until verified') gives clear context that this is the first step of a two-step flow, implicitly routing to verify_site. However, it never names verify_site as the alternative/next tool, so the routing is left to inference rather than stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bot traffic on a site - DevDome separates every hit into human vs bot. kind 'bots' = known-bot catalog activity; 'threats' = suspicious/behavioral detections.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| days | No | ||
| from | No | YYYY-MM-DD | |
| kind | No | ||
| site | Yes | ||
| limit | No | Row cap for kind bots; ignored for threats |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, non-open-world operation, lowering the bar. The description adds the human-vs-bot separation model, which is meaningful context, but says nothing about default timeframes, pagination, or result size beyond what the schema's limit note carries.
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 compact sentences with no filler, and the core subject is front-loaded. The dashed fragment structure is terse but readable.
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?
A six-parameter report tool with 33% schema coverage and no output schema leaves real gaps: no default date range, no explanation of how days interacts with from/to, and no hint at what the report returns. Comparable to a mid-grade tool with partial coverage.
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 33% (site, to, and days are undocumented). The description compensates for kind by explaining 'bots' vs 'threats' beyond the bare enum values, but the date-window parameters (from/to/days interplay) remain unexplained anywhere.
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 resource (bot traffic for a site) and clarifies the two data slices via kind. It does not explicitly differentiate itself from siblings like get_breakdown or get_visitors, but the resource is concrete enough to distinguish it.
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 kind enum semantics imply when to pick 'bots' vs 'threats', which is useful selection guidance. However, there is no statement of when to use this tool over get_breakdown/get_stats, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top-N breakdown of a site's traffic by one dimension.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| days | No | ||
| from | No | ||
| site | Yes | ||
| limit | No | ||
| dimension | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds only that results are ranked ('Top-N'), but says nothing about default limit, sorting order, tie behavior, or return shape for a 6-parameter tool. Little beyond the annotations and title.
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 with zero filler, so nothing is wasted. It is arguably too terse for the parameter surface, but the structure dimension rewards tight, non-redundant 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?
For a 6-param tool with no output schema and 0% parameter documentation, the one-line description leaves major gaps: date-range semantics (from/to vs days), default and max limit, and expected result ordering are all unstated. Annotations cover safety but not the calling contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 6 parameters, so the description must compensate and largely does not. 'One dimension' loosely points at the dimension enum, and 'Top-N' hints at limit, but site, from, to, and days are entirely unexplained, and the enumeration values are never characterized.
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 verb ('breakdown') and resource ('a site's traffic') and adds the top-N-by-one-dimension scope, which is more specific than a bare name. However, it never distinguishes itself from siblings like get_stats, get_timeseries, or get_visitors, which plausibly also report traffic, so an agent cannot route confidently among them from the description alone.
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, no when-not-to-use, and no named alternative. The reader must infer that this is the tool for ranked/top-N lists versus get_timeseries or get_stats. No prerequisites (auth, date-range requirements) are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Visitors active on the site in the last 5 minutes, with their current page and path.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, so the description's main addition is the 5-minute freshness window and the page/path fields it returns. That is useful context that goes beyond the annotations, though it does not discuss list shape, counts, or any operational quirks.
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 compact sentence with no filler; the defining temporal constraint is front-loaded and every word adds meaning.
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-only tool, the description covers what is returned (active visitors with page/path) and the relevant time window. It does not detail the site parameter or return format, but no output schema exists and the tool's complexity is low, so the remaining gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole required parameter, site, has no schema description, and the description only refers to 'the site' in passing. At 0% schema coverage, the description needed to define the parameter but does not, leaving the agent to infer that site is a site identifier.
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 the resource (visitors) and a unique temporal scope (active in the last 5 minutes), plus the fields (current page and path), which distinguishes it from tools like get_visitors and get_stats. It is phrased as a noun phrase rather than an explicit verb, but the title 'Get Realtime Visitors' supplies the action, so the purpose is 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 'last 5 minutes' phrasing implies this is the realtime/current-visitors option rather than a historical tool, but it never names get_visitors or get_timeseries as alternatives or states when not to use it. The guidance is limited to inferred context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uptime/health summary for a site: status, response time, TLS/domain checks, open incidents.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only. The description adds useful context about the checks included (status, response time, TLS/domain, incidents), but it does not disclose return format, pagination, or error behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the core purpose and packs in the key output details without 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?
Adequate for a simple read-only tool: it states the purpose and the data returned. However, without an output schema and with an undocumented 'site' parameter, the agent still lacks the identifier format and any invocation caveats.
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 only parameter, 'site', has zero schema description coverage and the tool description never clarifies whether it expects a site ID, domain, or URL. The description adds no meaning beyond the property name.
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 a health summary resource and lists its contents: status, response time, TLS/domain checks, and open incidents. This differentiates it from sibling report tools like get_realtime, get_breakdown, and get_stats.
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 health-summary framing, but the description never explicitly states when to choose this tool over siblings or provides exclusions. There is no alternative routing or 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.
Headline KPIs for a site: visits, visitors, pageviews, outbound clicks, bots, CTR, bounce rate, session duration. Defaults to the full retained history. new_visitors is null (and returning_visitors 0) when the site's Cookieless tracking setting is on: the daily id cannot tell a return visit, do not report them. If new_visitors is almost equal to visitors, the tracker runs cookieless but the dashboard switch is off: tell the user to turn on Website Settings > Cookieless tracking for that site. visitors includes redirect-only hops, so it can exceed pageviews.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD | |
| days | No | Window in days (omit for full history) | |
| from | No | YYYY-MM-DD | |
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe read-only operation, but the description adds substantial behavioral context beyond that: default full-history retention, cookieless-tracking effects on new_visitors and returning_visitors, a diagnostic rule for near-equal new_visitors and visitors, and the fact that visitors can exceed pageviews due to redirect hops. This is rich, actionable disclosure for interpreting results.
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 front-loaded with the metric list and then layers in important edge-case behavior. It is appropriately sized for the complexity, though the multi-sentence prose is slightly dense and could be tightened with bullet-like 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?
There is no output schema, so the description should carry more of the return-value burden. It lists the headline metrics and critical caveats, but it does not describe the response shape or fully clarify date-range parameter interactions, leaving a 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 description coverage is 75%, so most parameters are already documented in the schema. The description adds the default full-history behavior, but this is already implied by the days parameter description, and it does not clarify how from, to, and days interact beyond that default.
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 a specific verb and resource ("Headline KPIs for a site") and enumerates the metrics returned. It does not explicitly distinguish this tool from siblings such as get_breakdown or get_timeseries, so it is clear but not sibling-differentiating.
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 by the phrase "Headline KPIs for a site" and the default date-range note. However, the description gives no explicit when-to-use guidance or alternatives, so the agent must infer when to choose this over get_timeseries, get_breakdown, or get_visitors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily traffic series for a site (visits, visitors, pageviews, clicks, bots per day, in the site's timezone). Window by days, or from and to (YYYY-MM-DD); omit both for the full history the plan retains.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Window end, YYYY-MM-DD (inclusive) | |
| days | No | ||
| from | No | Window start, YYYY-MM-DD | |
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context the annotations don't carry: results are in the site's timezone, and omitting the window returns only the history the plan retains — a retention caveat an agent would otherwise miss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the resource and payload, followed immediately by the windowing contract. Every clause carries information an agent needs.
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 no output schema, the description correctly enumerates what a row of the series contains and notes the timezone, so an agent knows what it gets back. Only the shape/ordering and volume of the series is left implicit, which is a minor gap for a read-only 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 50%, with 'days' and 'site' undocumented in the schema. The description compensates by explaining the days-vs-from/to windowing contract and the omit-both behavior, which is exactly the undocumented part of the schema. 'site' is self-evident from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (daily traffic series for a site) and enumerates the exact metrics returned (visits, visitors, pageviews, clicks, bots per day), which meaningfully separates it from siblings like get_stats, get_breakdown and get_realtime. It never names which sibling to prefer, 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?
Gives real guidance on how to scope the query (use days, or from/to, omit both for full retained history), but frames it entirely around parameters rather than when to choose this tool over get_stats or get_breakdown. Usage is implied by the metric list rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent individual visits: entry page, path taken, country, device, human/bot.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| days | No | ||
| from | No | YYYY-MM-DD | |
| site | Yes | ||
| limit | No | ||
| before | No | Page further back: the last_seen of the last row you got; a page shorter than limit is the end |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description contributes the output content (per-visit fields including bot detection), which is genuinely useful since no output schema exists, but it says nothing about ordering, default time window, or rate/volume 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?
A single compact fragment with the resource front-loaded and no wasted words. It is efficient, though arguably under-specified rather than truly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter, no-output-schema tool, the description omits the meaning of the time window ('recent'), the default and role of limit, and the pagination contract (only documented inside the 'before' schema field). It covers the return fields but not the invocation details an agent needs.
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 33% (six parameters, only 'from' and 'before' documented), so the description is expected to compensate and does not. The word 'Recent' loosely gestures at the days/from/to window but gives no default or syntax, and site, limit, and to are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (recent individual visits) and enumerates the returned attributes (entry page, path, country, device, human/bot), which clearly separates it from aggregate siblings like get_breakdown and get_stats. It is clear rather than vague, though it relies on the tool name for the verb and never explicitly contrasts itself with get_realtime.
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 when-to-use guidance, no prerequisites, and no mention of alternatives such as get_realtime or get_stats. The agent must infer from the field list alone that this is the raw-visit-log tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the websites on this DevDome account with their verification status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds that it returns verification status, which is useful context about the output. However, it does not disclose any additional behavioral traits like sorting, pagination, or potential rate limits. With annotations covering the read-only nature, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundant information. It front-loads the action and resource, making it easy to parse. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema, no output schema, and overall low complexity, the description is complete. It states what the tool returns (websites with verification status) and needs no further explanation. An agent can call this tool without additional 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 tool has zero parameters and the schema coverage is 100% (empty). Per the baseline rule for 0 params, the description does not need to compensate for parameter documentation. The description adds value by indicating the output includes verification status, which is relevant to the no-parameter call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('websites on this DevDome account') with an additional detail ('verification status'). It distinguishes this tool from siblings like add_site or verify_site, which perform different actions. The purpose is 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 explicit guidance on when to use this tool versus alternatives. While it is implied that this is the default listing tool, there is no mention of when not to use it, or any alternative such as get_breakdown or get_stats. The agent must infer usage context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify ownership of a pending website (checks the installed snippet or DNS TXT record).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, lowering the burden. The description adds meaningful behavioral detail beyond annotations: it discloses that verification works by checking a snippet or DNS TXT record and targets pending sites. No contradictions with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, parenthetical clarification, and zero filler. The verb and resource are front-loaded, and each word contributes meaning.
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 one-parameter tool with no output schema and safety annotations present, the description covers purpose, target state, and method. It does not explain what happens on success or failure, but this is minor for a simple verification 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?
The schema provides 0% description coverage for the single 'domain' parameter, so the description must compensate. It implies domain refers to the pending website's domain, but it does not specify expected format (e.g., with or without protocol) or any constraints beyond 'string'. Partial compensation for a simple one-parameter tool.
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 ('Verify'), a clear resource ('ownership of a pending website'), and the exact mechanism (checks the installed snippet or DNS TXT record). This clearly distinguishes it from sibling tools like add_site and get_stats, which serve different purposes.
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: for a 'pending website' whose ownership needs confirmation, with the method listed. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent can decide when verification is the right step.
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.
get_bot_report2 fields changedInput schema / properties / fromAdded value: +{
+ "description": "YYYY-MM-DD",
+ "type": "string"
+}Input schema / properties / toAdded value: +{
+ "type": "string"
+}get_breakdown1 field changedInput schema / properties / dimension / enumPrevious value: -[
- "pages",
- "referrers",
- "countries",
- "devices",
- "browsers",
- "os",
- "dates",
- "keywords",
- "products",
- "redirects"
-]New value: +[
+ "pages",
+ "referrers",
+ "countries",
+ "devices",
+ "browsers",
+ "os",
+ "dates",
+ "keywords",
+ "products",
+ "redirects",
+ "campaigns"
+]get_bot_report1 field changedInput schema / properties / limitAdded value: +{
+ "description": "Row cap for kind bots; ignored for threats",
+ "type": "number"
+}get_timeseries2 fields changedInput schema / properties / from / descriptionAdded value: +"Accepted, not applied: use days"Input schema / properties / to / descriptionAdded value: +"Accepted, not applied: use days"get_visitors2 fields changedInput schema / properties / fromAdded value: +{
+ "description": "YYYY-MM-DD",
+ "type": "string"
+}Input schema / properties / toAdded value: +{
+ "type": "string"
+}add_siteget_bot_reportget_breakdownget_realtimeget_site_healthget_statsget_timeseriesget_visitorslist_sitesverify_siteYour website analytics as read-only tools: traffic, pages, errors, speed and AI-assistant visits.
Real-time web analytics for AI agents: query traffic, funnels, revenue, and manage your sites.
Privacy-first web analytics. Query pageviews, referrers, trends, and AI insights.
Web analytics for AI agents: realtime visitors, revenue, funnels and AI-detected site issues
Add one secure layer between your agents and this server.
