66 technical SEO and AI-readiness checks: what each looks at, why it matters, how to fix it
Scored across 3 tools
The three tools have clearly distinct purposes: explain_check retrieves details for a known check, list_checks enumerates all checks with optional filters, and search_checks finds checks by keyword. There is no meaningful overlap between them.
All tool names consistently follow a snake_case verb_noun pattern: explain_check, list_checks, search_checks. The convention is predictable and readable.
Three tools is well-scoped for a check reference server: lookup by code, browse/filter, and search. Each tool earns its place without redundancy or thinness.
The surface covers the core read-only needs of a check reference: browse, filter, search, and explain. It lacks batch lookup or direct check execution, but such operations may be out of scope for this reference-style server.
The full explanation of one Trakis check: what it looks at, why it matters, where the problem usually comes from, how to fix it (with a worked example when there is one), how to verify it without Trakis, and how an audit counts it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The check's code, e.g. "CRAWL-008" or "onpage-005". Case does not matter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is its disclosure of the return payload: root cause, fix with a worked example, verification without Trakis, and audit counting. That is meaningful behavioral context beyond the annotations, though it says nothing about error handling for unknown codes.
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, front-loaded with the core purpose and then a compact enumeration of the explanation's sections. Slightly list-heavy but every clause maps to real returned content, so little is wasted.
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 carries the burden of explaining what comes back, and it does so thoroughly. Safety is covered by annotations and the lone parameter by the schema; only failure behavior for an unrecognized check code is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'id' parameter is already documented with format examples ('CRAWL-008') and case-insensitivity. The description adds nothing about the parameter, 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 ('The full explanation of one Trakis check') and enumerates exactly what that explanation contains. The singular scope implicitly separates it from the plural list_checks/search_checks siblings, but neither sibling is named, so differentiation is inferred rather than explicit.
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 never says when to reach for this tool versus list_checks or search_checks, nor any prerequisite (e.g. 'after finding a check code with search_checks'). It only describes the content payload, leaving the selection decision to the caller.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every check a Trakis audit runs, optionally only one category or one severity, with its code, title and a link to its explanation.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Only the checks of this category. | |
| severity | No | Only the checks of this severity. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so safety behavior is covered. The description goes beyond that by disclosing what is returned (code, title, link to the explanation), which matters because there is no output schema, and by noting the filters are optional. It omits pagination/volume behavior for what could be a long catalog.
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 front-loaded sentence with no filler: the unfiltered case is stated first, the optional narrowing second, and the returned fields last. 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?
With no output schema, the description usefully enumerates the returned fields, and both optional parameters are covered by the schema. It is close to complete for a simple read-only listing tool, though it could note result size or ordering for a full-catalog listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both enum parameters are fully documented in the schema, so the baseline is 3. The description reinforces the filter semantics ('optionally only one category or one severity') and hints at the mutually exclusive single-filter nature, but adds no format or syntax detail 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 (list) and resource (checks) plus scope: every check a Trakis audit runs, optionally narrowed to one category or one severity. It is distinguishable in practice from search_checks and explain_check by its 'all checks' framing, but neither sibling is named, so differentiation is inferred rather than stated.
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 this tool is appropriate (you want the full catalog or a single-dimension filter), but it never says when to prefer search_checks or explain_check. No prerequisites or exclusions are stated, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Trakis checks by a word or a problem, when you do not know the check's code. Searches titles, what each check looks at, why it matters and where the problem usually comes from. Returns up to 10 checks, best matches first.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A word or short phrase, e.g. "canonical", "robots.txt", "duplicate title", "structured data". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: the search spans four content fields (not just titles) and results are capped at 10 with best-match ranking. It stops short of saying what happens with zero hits or whether more than 10 can be retrieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler: purpose first, then what is searched, then the return shape. Everything is front-loaded and each sentence carries distinct information.
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 search with no output schema, the description covers scope, matching fields, result cap and ordering, which is enough to call it correctly. It leaves the no-results behavior and any way to exceed 10 results unstated, 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 coverage is 100% and the single param is already documented with examples, so the baseline would be 3. The description adds semantic reach by saying the query may be 'a word or a problem', signalling fuzzy/problem-description matching rather than a bare keyword, which usefully shapes how the agent writes the query.
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 ('Find Trakis checks') and goes further by naming what is searched (titles, what each check looks at, why it matters, where the problem comes from). It implicitly separates itself from explain_check by scoping to cases where 'you do not know the check's code', but it never names the siblings, so differentiation is inferred rather than stated.
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 a clear trigger condition: use this when you do not know the check's code, which contrasts with the code-driven sibling explain_check. It does not name alternatives explicitly or state exclusions (e.g., 'use list_checks to browse everything'), so the agent has context but must infer the routing.
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.
explain_checklist_checkssearch_checksTechnical SEO and AI-readiness audits for any page, plus a check that your fix worked.
AI visibility tracking & website fixes for better AI search presence
Free AI-readiness audit of any URL: AI crawler rules, JS-free text, JSON-LD, llms.txt. Tool catalog.
Check whether AI agents can read any website: 18 deterministic checks, each with its fix.
Add one secure layer between your agents and this server.
