Skip to main content
Glama
Sign In

Kashif

by com.kashifaudit
OverviewDiscussionsAdmin

Collect the result of a website scan

get_scan_result
Read-onlyIdempotent

Collect the result of a scan that scan_website started but had not finished when it answered. Call scan_website first; if its status is "processing", wait a little (about 30 seconds) and call this with the scanId it returned. Returns the same result as scan_website: "processing" (ask again shortly), "ready" (the 0-100 score and top issues) or "failed". It only reads: it never starts a scan. A scanId stops working 7 days after it was issued.

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": {
      "scanId": "<scanId>"
    },
    "name": "get_scan_result"
  }
}

Input Schema

NameRequiredDescriptionDefault
scanIdYesThe scanId that scan_website returned with status "processing".
waitSecondsNoOptional: how many seconds to wait for a scan that is still running before answering (0-20, default 0 = answer now).

Output Schema

NameRequiredDescriptionDefault
noteYesPlain-language context about the score.
scoreYes0-100 online-presence score, or null until the quick pass finishes.
scanIdNoPresent while status is "processing": pass it to get_scan_result to collect the finished result.
statusYes"ready" = quick score below; "processing" = still running, collect it with get_scan_result; "failed" = site could not be checked.
websiteYesThe website that was scanned.
findingsYesThe top issues to fix first, most urgent first.
whatsappYesA WhatsApp link to reach the Kashif team about this business.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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."
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations, it discloses the returned status states ('processing'/'ready'/'failed'), that a 'processing' answer means ask again, and a hidden constraint that scanIds expire after 7 days — none of which is in the annotations. The only blemish is a mild internal inconsistency: it advises waiting 'about 30 seconds' while the schema caps waitSeconds at 20.

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 core purpose, then preconditions, then return values, then the expiry caveat — a sensible order with little filler. Minor waste from restating the read-only property already carried by readOnlyHint, plus the 30s-vs-20s muddle.

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?

For a two-parameter polling tool with full annotations and an output schema, nothing an agent needs to call it correctly is missing: origin of the ID, timing behavior, possible outcomes, and ID lifetime are all covered.

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 coverage is 100%, with scanId's origin and waitSeconds' range/default already documented in the schema, so the baseline is 3. The description reinforces where scanId comes from but adds no new semantics for waitSeconds and its 30-second advice slightly conflicts with that parameter's 0-20 bound.

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 (collect the result of a scan) and immediately frames it as the polling counterpart to scan_website, so an agent can distinguish it from the sibling without opening either schema. It also explicitly rules out the sibling's behavior: 'it never starts a scan.'

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 an explicit precondition (call scan_website first), the exact trigger for using this tool (its status is 'processing'), and a concrete retry cadence. It also states what the tool does not do, which is an effective when-not clause.

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

All Kashif toolsInspect
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