Search Accent's public website and get non-binding budgetary estimates from published plan prices.
Scored across 4 tools
site_get (fetch one record), site_search (query the corpus), and site_status (version metadata) target clearly separate operations with little overlap. get_budgetary_quote is a computational pricing tool that a naive agent might confuse with fetching the plans-pricing page via site_get, but its description explicitly frames it as an estimate generator rather than a content read.
Three tools follow a clean `site_<verb>`-style prefix convention (site_get, site_search, site_status), but get_budgetary_quote uses a bare verb_noun pattern with no prefix, breaking the pattern. The split is still readable, but it is a visibly mixed convention within a four-tool set.
Four tools is lean but each one maps to a real capability: search the content, read a record, quote pricing, and check the served schema version. The only thinness is the absence of any enumeration/browse tool, which pushes it slightly under-scoped for a content site.
Reading coverage (search + get) and pricing coverage are solid, but there is no way to list routes, collections, or sitemap entries, so discovery depends entirely on site_search returning something useful before site_get can be used. There is also no tool for the referenced next-step actions (e.g. formal quote request), leaving a dead end the agent must punt to a URL.
Non-binding monthly estimate for Accent cloud phone and team messaging plans at the published 36-month rates on https://www.accentvoice.com/plans-pricing/ (users × per-user plan price, plus published add-ons). Month-to-month, other terms and annual-billing online-order pricing are not quoted here: request a formal quote. Omit plan to get every plan; monthly.low_from / high_from name the plan behind each end of the range (each plan carries its tagline, e.g. Team is team messaging). Excludes taxes, fees, usage and one-time charges. Each estimate lists the plan's included features as published on the Plans & Pricing page. No personal data needed. For a binding price, send the person to next_steps.formal_quote_url.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | team = Team (Team Messaging); pro = Pro (Cloud Phone, Team Messaging); pro-plus = Pro+ (Phone, Message + Bring Your Own VoIP Phone); premium = Premium (Phone, Message with a VoIP Phone Included) | |
| term | No | 36_month (default) = the published plan-card price. month_to_month is not quoted by this tool: it returns term_not_supported with a formal-quote link. | |
| users | Yes | Number of users. Above the service limit the tool answers formal_quote_required. | |
| addons | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds real behavioral detail on top: no personal data required, taxes/fees/usage/one-time charges excluded, included features listed per plan, and specific non-success responses (term_not_supported, formal_quote_required).
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 dense paragraph, but front-loaded with the core definition and zero purely decorative sentences. The clause about taglines and the feature-list sentence are secondary detail that slightly dilutes an otherwise tight block.
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 compensates by explaining returned fields, caveats, exclusions, and the escalation path. An agent has everything needed to call it correctly and to interpret or reroute an unsupported request.
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 75%, and the description adds default/omission semantics that the schema does not spell out (omitting plan returns every plan) plus the meaning of the returned monthly.low_from / high_from endpoints. It says less about the addons object, which the schema already enumerates.
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 first sentence names a specific verb (estimate), the exact resource (Accent cloud phone and team messaging plans), and the pricing basis (published 36-month rates). It is unmistakably a read-only pricing tool, easily distinguished from the site_get/site_search/site_status 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?
It states when to use it (36-month published rates, add-ons included), when not to (month-to-month, other terms, annual-billing online-order pricing), how to widen scope (omit plan), and hands off explicitly to next_steps.formal_quote_url for binding prices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one published record in full. Pass exactly one of route (e.g. "/cloud-phone-system/") or slug (looked up as product, then post, then page, then story). Returns a not_found error if nothing is published there.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Record slug, e.g. gxp1625-ip-phone. | |
| route | No | Site route with a trailing slash, e.g. /cloud-phone-system/. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral facts: only published records are returned, unpublished lookups yield not_found, and slug resolution follows a product→post→page→story order.
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 tight sentences, front-loaded with the core action, then the argument rule, then the failure behavior. No filler or repetition of 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?
No output schema exists, and the description covers what comes back (the full record) and the error case, which is adequate. It could say more about pagination or absent-record edge cases, but nothing essential to correct invocation is missing.
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 100% schema coverage the baseline is 3, and the description exceeds it by adding the XOR constraint ('exactly one of') that the schema does not encode, plus the slug resolution precedence order. It cites an example route and slug too.
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 ('Fetch') and resource ('one published record in full'), and the title enumerates the record types. It is clearly distinguishable from site_search/site_status in intent, though it never names a sibling to route between 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?
Gives an important call constraint ('Pass exactly one of route or slug') and a failure condition ('Returns a not_found error if nothing is published there'), which is useful context. However, it never says when to prefer this over site_search for retrieval, so alternative-selection 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.
Search the published content of www.accentvoice.com (pages, blog posts, products, customer stories). Plain questions work: filler words are ignored, results are ranked by how many terms match (title first), and broad questions return the overview pages. Returns up to limit results with collection, slug (absent for pages), route, title and score. Use site_get to read a result in full.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search terms. | |
| type | No | Restrict to one collection. | |
| limit | No | Maximum results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly/idempotent/non-destructive), it discloses ranking behavior (term-match count, title weighted first), filler-word handling, and the exact result shape returned (collection, slug absent for pages, route, title, score). These are behavioral traits an agent cannot infer from structured fields.
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 dense sentences with no waste: purpose first, then ranking/query behavior, then return shape and the hand-off to site_get. Front-loaded and appropriately sized.
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 compensates by naming the returned fields and noting the page slug omission. Combined with the collection enumeration and site_get hand-off, an agent has everything needed to call and interpret 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?
Schema coverage is 100%, so baseline is 3; the description adds meaning by clarifying that `limit` bounds the number of results returned and that slug is absent for page-type results. The `type` enum values map to the collections listed, though the description does not explicitly tie them together.
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 (search the published content of www.accentvoice.com) and enumerates the collections covered (pages, blog posts, products, customer stories). It is clearly distinguishable from the sibling site_get, which it names as the follow-up for full reads.
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 useful invocation guidance ('plain questions work', broad questions return overview pages) and explicitly routes to site_get for full content. It does not state any when-not-to-use condition or contrast with site_status/get_budgetary_quote, so it falls short of full alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The schema version and release stamp (git, build time, digest) of the content being served. It equals the stamp in /agent/content-index.json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that: it enumerates the returned fields (git, build time, digest) and notes equivalence to the stamp in /agent/content-index.json, which helps the agent interpret the value.
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 with the payload described first. The second sentence about equaling the stamp in /agent/content-index.json is a cross-reference of marginal actionable value to an agent, but it is not padding.
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 carry the return-value burden, and it does by naming the fields returned. For a zero-parameter read-only status tool this is nearly complete; only the practical purpose of the stamp is left unstated.
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 zero parameters, so the baseline is 4. The description correctly implies no input is needed, and there is nothing further for it to clarify about arguments.
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 resource and payload: the schema version and release stamp (git, build time, digest) of the content being served. That is clearly distinct from the fetch/search behavior implied by siblings site_get and site_search, though it never explicitly names or contrasts 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?
There is no when-to-use guidance at all. Nothing tells the agent whether to call this to verify cache freshness, before a content-index lookup, or how it relates to site_get and site_search. Usage must be entirely inferred.
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_budgetary_quotesite_getsite_searchsite_statusScans any public website for SEO, AI search, trust, conversion and speed, and lists our prices.
Search and read National Digital's website, see pricing and estimate a project.
Compute and verify prices from an agent, metered per call. Works keyless on a demo tenant.
Check what an AI assistant tells buyers about a company against the company's own pricing pages.
Add one secure layer between your agents and this server.