Kashif

Score a business’s online presence

scan_website

Score how well a business shows up online, out of 100, and name what is hurting it most. Give it a website (and an email, so the Kashif team can follow up) and it runs Kashif's audit of the business's online presence: whether customers can find them in search, whether AI assistants can read them, how fast the site feels on a phone and the first impression it makes, how trustworthy it looks, and how easy the business is to reach (WhatsApp, phone, a contact form). Returns a 0-100 score with the top issues to fix first. Use it whenever someone asks to audit, check, review, grade or improve a company's website or online presence. This starts a live scan and creates a lead for the Kashif team, who may follow up by email. If the result comes back with status "processing", the scan is still running: wait about 30 seconds, then call get_scan_result with the scanId it returned to collect the score.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "email": "<email>"
    },
    "name": "scan_website"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	The business’s website, e.g. example.com or https://example.com.
`name`	No	Optional: the person or business name, used to label the lead.
`email`	Yes	Your email, so the Kashif team can follow up. Required — this is a lead for the team.
`language`	No	Report language: "en" (default) or "ar" for Arabic.

Output Schema

Name	Required	Description
`note`	Yes	Plain-language context about the score.
`score`	Yes	0-100 online-presence score, or null until the quick pass finishes.
`scanId`	No	Present while status is "processing": pass it to get_scan_result to collect the finished result.
`status`	Yes	"ready" = quick score below; "processing" = still running, collect it with get_scan_result; "failed" = site could not be checked.
`website`	Yes	The website that was scanned.
`findings`	Yes	The top issues to fix first, most urgent first.
`whatsapp`	Yes	A WhatsApp link to reach the Kashif team about this business.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 7, 2026

changedInput schema / properties / email / description

Previous value: -"An email address to send the full written report to. Required — this is a lead for the team."New value: +"Your email, so the Kashif team can follow up. Required — this is a lead for the team."

changedOutput schema / properties / note / description

Previous value: -"Plain-language context about the score and the full report to come."New value: +"Plain-language context about the score."

changedOutput schema / properties / status / description

Previous value: -"\"ready\" = quick score below; \"processing\" = still running, report follows; \"failed\" = site could not be checked."New value: +"\"ready\" = quick score below; \"processing\" = still running, collect it with get_scan_result; \"failed\" = site could not be checked."

Changed1 schema field changedOct 20, 2026

addedOutput schema / properties / scanId

Added value: +{
+  "description": "Present while status is \"processing\": pass it to get_scan_result to collect the finished result.",
+  "type": "string"
+}

First observedSep 10, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say readOnlyHint=false and openWorldHint=true; the description goes further by disclosing that this starts a live scan, creates a lead for the Kashif team, that the team may follow up by email, and that the call may return asynchronously with status "processing". Those side effects and the async contract are exactly what the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the outcome (a 0-100 score plus top issues), then inputs, then the async handoff. It is somewhat longer than needed, with mild repetition between 'Give it a website (and an email...)' and the later lead/follow-up sentence, but every block carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description still covers what an agent needs that structure cannot: the side effect of lead creation, the possibility of an email follow-up, and the exact recovery path for a "processing" response. Nothing material is missing for a 4-parameter, non-idempotent scanning tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so url, name, email and language are already fully documented including the en/ar enum. The description restates the email's purpose ('so the Kashif team can follow up') but adds no format, validation or usage detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Score how well a business shows up online, out of 100') and enumerates the audit dimensions covered (search findability, AI readability, mobile speed, trust, contactability). It also distinguishes itself from its only sibling by naming get_scan_result as the follow-up collector rather than the scanner.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger phrasing ('audit, check, review, grade or improve a company's website or online presence') and an explicit conditional handoff: if status is "processing", wait ~30 seconds then call get_scan_result with the scanId. Both the entry condition and the alternative path are spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Kashif tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?