Analyze URL for on-page SEO quality: score, readability, technical checks, recommendations
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "content_score"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to analyze | |
| keyword | No | Target keyword to check optimization |
Changes observed during successful MCP inspections.
Input schema / additionalPropertiesAdded value: +falseDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states that the tool analyzes and returns a score, readability, technical checks, and recommendations, which implies a read-only operation. However, it does not mention potential prerequisites, such as the URL being publicly accessible, or any rate limits or output response format, leaving moderate gaps.
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 concise sentence beginning with the action verb 'Analyze', immediately naming the resource (URL) and summarizing deliverable categories. Every word contributes value, with no filler or redundant 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?
The description covers the core functionality and high-level output components, which is adequate for basic selection. However, it lacks usage criteria relative to siblings, behavioral caveats, and details about the return structure (since no output schema exists). Overall, it provides moderate but not comprehensive 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 schema provides 100% coverage of the two parameters (url and keyword) with descriptions. The tool description adds no additional meaning about how the keyword influences analysis or expected URL format. Since schema coverage is high, the baseline score of 3 applies without enrichment from the description.
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 tool's function: 'Analyze URL for on-page SEO quality' and lists concrete outputs (score, readability, technical checks, recommendations). This is a specific verb+resource construction that distinguishes it from more targeted sibling tools like heading_analysis or title_optimizer.
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 for evaluating on-page SEO performance of a URL, but provides no explicit guidance on when to choose this tool over alternatives such as health_check or competitor_gap. There are no exclusions or comparative statements, leaving the agent to infer appropriate use from the general wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.