Iron Canyon Website Punch List

Website Punch List

get_website_punch_list

Read-only

Runs Iron Canyon Co's Website Punch List on a contractor's website. Our server fetches public pages of the address given (the home page, up to two more pages, the robots file and sitemap, and public domain and email records) and returns a score out of 100, a verdict, and up to three of the biggest problems with why each matters. It does not say how to fix them. Phone speed is not measured. No contact details are needed or saved.

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": {
      "website": "<website>"
    },
    "name": "get_website_punch_list"
  }
}

Input Schema

Name	Required	Description	Default
`website`	Yes	The address of the website to check, for example example.com.

Output Schema

Name	Required	Description	Default
`areas`	Yes
`notes`	Yes
`score`	Yes
`counts`	Yes
`refusal`	Yes
`verdict`	Yes
`readable`	Yes
`next_step`	Yes
`top_problems`	Yes
`not_read_reason`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Well beyond the annotations, it discloses exactly what the server fetches (home page, up to two more pages, robots, sitemap, public domain and email records), the shape of the result, and two important limits: it will not explain remediation, and phone speed is not measured. It also confirms no contact data is stored. It stops short of addressing caching or repeat-run behavior, leaving the idempotentHint=false implication unexplained.

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?

Four short sentences, front-loaded with what the tool does, then scope, then exclusions. Every sentence carries information; only the phrasing 'Phone speed' is slightly imprecise.

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

Completeness4/5

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

For a single-parameter read-only tool with an output schema, the description covers scope, result shape, and negative constraints adequately. Minor gaps remain around cost/rate limits and why repeated calls may not be idempotent.

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?

There is a single parameter with 100% schema coverage, and the description adds little beyond the schema's own example: 'the address of the website to check' is already documented. The note that only public pages are fetched adds mild framing but no new input syntax or constraints.

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

Purpose4/5

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

The description names a specific verb-and-resource pair ('Runs ... Website Punch List on a contractor's website') and spells out the scope: public pages, robots, sitemap, domain/email records. It is clear what the tool produces (score out of 100, verdict, top three problems). It never references the sibling describe_website_punch_list, so the agent gets no explicit disambiguation between the two.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: you call it to check a contractor's website, and it notes that no contact details are needed. There is no explicit when-to-use versus when-not, and no mention of the sibling tool that presumably describes (rather than runs) the punch list.

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

All Iron Canyon Website Punch List 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?