Dedica tests your website the way AI agents use it, then gives your team a fix for every place they fail. Muse, Instinct, GrokBot and other agents now browse, compare and sign up on people's behalf. Dedica runs 125 checks (for free) and gives a fix for every issue to hand to your coding agent.
Scored across 2 tools
The two tools have clearly distinct purposes: checking a cached readiness score versus running a fresh scan. The descriptions explicitly explain when to use one versus the other, including the fallback from cache miss to fresh scan.
Both names use snake_case and follow a verb + website + agent_readiness pattern. The minor inconsistency is that one includes 'for' while the other omits it, but the relationship remains easy to parse.
The server is narrowly scoped to website agent-readiness, so two tools are reasonable. It is slightly below the typical 3-15 range, but each tool maps to a distinct operation rather than being redundant.
The surface covers both cached lookup and fresh scanning, which are the core workflows for this domain. Minor gaps exist, such as no history or batch operations, and the scan result description mentions fewer detail fields than the cached check.
Get the public agent-readiness score, grade, layer breakdown and top findings for a public website domain, from Dedica's cache. Returns a not-scanned message if the domain has never been checked; use scan_website_for_agent_readiness to run a fresh check.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | A public website domain, e.g. stripe.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world behavior. The description adds meaningful context beyond that: results come from a cache, and an unchecked domain returns a not-scanned message rather than an error. It stops short of describing cache staleness or refresh semantics, which would be the next level of detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler, front-loaded with what is returned and followed by the edge case and the sibling routing. 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?
No output schema exists, so the description compensates by enumerating the return payload (score, grade, layer breakdown, top findings) and the not-scanned case. Combined with the annotations and a fully documented parameter, nothing an agent needs 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 a single parameter and 100% schema description coverage (e.g. stripe.com), the schema already carries the specification. The description's 'public website domain' wording is consistent but adds no format constraints, validation rules or edge cases beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: fetch the cached agent-readiness score, grade, layer breakdown and findings for a public website domain. It explicitly frames the result as coming from Dedica's cache, which separates it from the sibling scan tool.
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?
Names the alternative (scan_website_for_agent_readiness) and the condition that selects it: run a fresh check. It also states the fallback behavior when a domain has never been checked, so the agent knows what to expect without a separate call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a fresh agent-readiness scan of a public website domain and return its score, grade and top findings once the scan finishes. Can take up to a few minutes for a domain that has never been scanned.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | A public website domain, e.g. stripe.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond the annotations: the latency characteristic ("up to a few minutes" for unscanned domains) and what the response contains (score, grade, top findings). This is genuinely useful since readOnlyHint=false and idempotentHint=false already flag that it is a non-read-only, repeatable-cost operation, but the description doesn't explain what the scan creates or whether results are persisted.
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, zero waste, with the action and return values front-loaded and the latency caveat placed where it will actually influence the agent's decision to call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly compensates by naming the returned fields and the expected wait time. The only material gap is that it doesn't differentiate itself from its single sibling, which for a scan tool is important for selection.
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% and the single domain parameter is documented with an example in the schema, so the description adds nothing parameter-specific. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: "Run a fresh agent-readiness scan of a public website domain," plus what it returns. It doesn't name the sibling check_website_agent_readiness, so the agent must infer that "fresh" is the distinguishing trait rather than being told 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?
"Fresh" and "a domain that has never been scanned" imply this tool initiates a new scan and is appropriate for cold domains, but the description never states when to prefer it over check_website_agent_readiness. Usage is implied rather than directed.
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.
check_website_agent_readinessscan_website_for_agent_readiness
Add one secure layer between your agents and this server.