Website traffic, human vs bot split, realtime visitors, breakdowns and site health for your DevDome sites. Hosted remote MCP server (streamable HTTP), authenticated with a DevDome API key.
Scored across 10 tools
Most tools are clearly scoped to distinct analytics views, but get_stats and get_timeseries both expose similar KPI names, and get_realtime versus get_visitors could be confused by an agent. The descriptions are specific enough to disambiguate in practice.
All tools follow a consistent verb_noun snake_case pattern: list/add/verify for site lifecycle and get_* for every analytics view. There are no mixed conventions or vague verbs.
Ten tools is well-scoped for an analytics server: three site-management actions and seven read-only data views. The count feels intentional and each tool has a clear purpose.
The core workflow is covered well: add a site, verify it, list sites, then query health, stats, timeseries, breakdowns, realtime, visitors, and bot reports. Minor lifecycle gaps like removing or updating a site are absent, but agents can work around them.
Add a website to the account. Returns the tracking snippet to install; 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 already indicate this is a mutating operation (readOnlyHint=false). The description adds valuable context beyond annotations: the site remains pending until verified, and the tool returns a tracking snippet. This discloses the post-condition and the return payload. It doesn't contradict 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 is a single, front-loaded sentence that states the action, the return value, and the pending state. No filler or redundant information. Every clause 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 tool with one required parameter and no output schema, the description covers the essential facts: what it does, what it returns, and the pending state. It doesn't mention error cases or verification process details, but those are likely handled by sibling tools. Adequate for an agent to call 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 single parameter 'domain' has 100% schema description coverage, and the schema already provides an example. The description adds no additional meaning about the parameter, 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 verb 'Add' and the resource 'website to the account'. It also distinguishes itself from the sibling get/list/verify tools by describing a unique return value (tracking snippet) and the pending state. This is a specific and unambiguous 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 implies usage by stating it adds a website, and the sibling set clearly separates this as the only add operation. However, it doesn't explicitly mention when not to use it or reference alternatives like verify_site for post-add actions. Still, the context is strong 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.
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 |
|---|---|---|---|
| days | No | ||
| kind | No | ||
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, so the description does not need to dwell on side effects. It adds useful behavioral context by explaining that DevDome separates every hit into human vs bot and what the two kind values represent. It does not disclose output format or pagination, but that is a minor gap given the read-only nature.
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 short, front-loaded with the main subject, and contains no filler. Each sentence contributes either the report scope or the kind semantics. It could be slightly more polished grammatically, but it is appropriately 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?
With no output schema and a low-information description, the agent is left without a clear statement of what the report returns or how the optional 'days' parameter behaves. The kind definitions help, but the missing time-range semantics and lack of any return-value description make the definition incomplete for reliable 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?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does fully explain the kind enum, but it says nothing about the meaning or expected format of 'days', which is not self-evident from the schema alone. 'site' is reasonably inferable from the name, but the description still leaves a meaningful parameter gap.
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 resource as bot traffic on a site and explains the two kind categories, which gives the agent a concrete sense of what this tool returns. It does not explicitly use a verb like 'get' or contrast itself with sibling report tools, so it stops short of full 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 phrase 'Bot traffic on a site' implies this tool is for bot-focused reporting, and the kind definitions help the agent choose between 'bots' and 'threats'. However, there is no explicit guidance about when to use this over get_stats, get_visitors, or get_breakdown, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
The annotations already declare readOnlyHint=true, which covers the read-only nature. The description adds nothing beyond that—no mention of pagination, data limits, or how the 'limit' parameter behaves. It doesn't contradict annotations, but it adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it is under-specified for a tool with six parameters and no output schema. It earns no credit for wasted words, but it also doesn't earn credit for being appropriately sized given the complexity.
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 six parameters, no output schema, and no mention of return format or parameter meanings, the description is incomplete. An agent would need to inspect the schema and still might not know how to construct a valid request (e.g., date range vs. days, required fields).
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%, and the description does not explain any of the six parameters. It only hints at 'Top-N' which likely maps to the 'limit' parameter, and 'by one dimension' which maps to the enum. This is thin compensation for a tool with a complex 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 states the tool produces a 'Top-N breakdown' by a dimension, which clearly indicates a ranked list for a site. This distinguishes it from siblings like get_timeseries (trend over time) or get_stats (aggregate metrics), though it doesn't explicitly name an alternative.
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 guidance on when to use this tool versus siblings like get_stats or get_timeseries. The description does not mention prerequisites, typical use cases, or any exclusions, leaving the agent to infer from the name and schema alone.
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.
| 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 cover the read-only and closed-world nature, so the bar is lower. The description adds a useful behavioral detail: it defaults to full retained history. It does not disclose aggregation behavior, bot filtering, or date-range edge cases, but that is acceptable given the annotation coverage.
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: the first lists the KPI set, and the second states the default range behavior. No filler, and the most important scoping information 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 read-only stats tool with no output schema, the description gives the headline metrics and default range, but it does not describe the response format or clarify how date parameters combine (e.g., whether `days` overrides `from`/`to`). It is minimally adequate but not comprehensive.
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 the schema handles most parameters. The description contributes the site scope and the 'omit days for full history' default, which adds meaning for the `days` parameter. The `site` parameter itself remains undocumented, and interactions between `from`, `to`, and `days` are not explained.
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 tool's output as headline KPIs for a site and enumerates the specific metrics returned (visits, visitors, pageviews, etc.). It distinguishes this from more specialized siblings like get_timeseries or get_breakdown, though it does not name them explicitly.
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 guidance about when to use this tool versus alternatives such as get_timeseries, get_realtime, or get_breakdown. The only contextual hint is the default full-history behavior, which says nothing about selecting this tool over others.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| days | No | ||
| from | No | ||
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes safety, so the description only adds modest behavioral context: daily granularity, metric set, and interpretation in the site's timezone. It does not disclose defaults, date-range behavior, or what the returned series looks like, but there is no contradiction 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?
The description is a single front-loaded sentence with no filler. The core action ('Daily traffic series') comes first, followed by a compact parenthetical listing metrics and the timezone behavior.
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 parameter descriptions, an agent needs at least the date-range semantics and the shape of the returned series to call this correctly. The description provides only the high-level metric list and time grain, leaving important invocation details unspecified.
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%, yet the description does not explain the date-range parameters (from, to, days) or their defaults. It only names the site and the metric set; an agent cannot infer parameter formats, optionality beyond the schema, or how days interacts with from/to.
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 tool as retrieving a daily traffic series for a site and enumerates the metrics included (visits, visitors, pageviews, clicks, bots). It does not explicitly name a sibling for contrast, so it stops short of a 5, but it conveys the resource and the time grain.
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 'daily traffic series' and 'per day' imply this is for daily aggregated traffic rather than real-time or breakdown views, and the site-timezone note narrows usage. However, there is no explicit guidance about when to prefer get_timeseries over get_stats, get_breakdown, or get_realtime, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent individual visits: entry page, path taken, country, device, human/bot.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| site | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds that results are per-visit and include a human/bot field, which is useful behavioral context. However, it does not disclose defaults for days/limit, ordering, pagination, or whether bot visits are included by default.
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 compact sentence with a clear front-loaded scope and a colon-separated field list. It is free of filler, though very terse.
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 three-parameter tool with no output schema, the description omits essential input semantics (especially required 'site' and the meaning of 'days'/'limit') and does not position the tool against its siblings. The returned-field list helps, but it is not enough 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?
Schema description coverage is 0%, so the description carries the full burden for explaining the parameters. It does not explain 'site', 'days', or 'limit' beyond a vague sense of 'recent' and 'individual visits'. The description mostly enumerates output fields 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 identifies the resource as recent individual visits and enumerates the fields returned (entry page, path, country, device, human/bot). This distinguishes it from aggregate siblings like get_stats or get_timeseries, but it does not explicitly name any alternative.
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 given on when to use this tool versus siblings such as get_breakdown, get_realtime, or get_bot_report. The only implied signal is 'individual' versus aggregate reports, but there are no explicit conditions, exclusions, or alternatives.
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.
add_siteget_bot_reportget_breakdownget_realtimeget_site_healthget_statsget_timeseriesget_visitorslist_sitesverify_site
Add one secure layer between your agents and this server.