xfix

Check nonprofit website for Google Ad Grants

check_ad_grants_website

Read-only

Checks a nonprofit's public website against the visible parts of Google's Ad Grants website policy: the domain serving the site itself, HTTPS, a findable mission, a physical address and registration number, real content on the key pages, working links and donate buttons, a mobile viewport and no ad-serving code. Reads the homepage, About, Programs, Contact and the donate destination without running JavaScript or submitting anything. Returns each policy rule as pass, fail or not checked, with what was seen and the fix. Does not access any Google account; passing does not guarantee approval. Use when the user asks about Google Ad Grants eligibility or their nonprofit website's readiness for it.

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": {
      "domain": "<domain>"
    },
    "name": "check_ad_grants_website"
  }
}

Input Schema

Name	Required	Description	Default
`domain`	Yes	The nonprofit's domain, for example example.org.

Output Schema

Name	Required	Description	Default
`url`	Yes
`tool`	Yes
`cached`	Yes
`limits`	Yes
`status`	Yes
`verdict`	Yes
`findings`	Yes
`ad_grants`	No
`checked_at`	Yes
`report_url`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: names the exact pages read (homepage, About, Programs, Contact, donate destination), discloses no JavaScript execution and no form submission, explains the pass/fail/not-checked result shape, and warns that passing does not guarantee approval.

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-loads the policy checklist, then constraints, then the disclaimer and usage trigger; nearly every clause is load-bearing. The rule enumeration is a long run-on list, but no sentence is filler.

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 no explanation, and the description still covers inputs read, execution limits, result semantics and the approval disclaimer. Nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100% and there is only one required parameter, so the schema already carries the baseline. The description adds real meaning by clarifying that the domain policy is judged on the domain actually serving the site, which tells the agent what value to supply.

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 (checks) and resource (nonprofit public website) and enumerates exactly which policy rules are evaluated, so an agent can distinguish it from the sibling readability/visibility/crawler tools immediately.

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

Usage Guidelines4/5

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

Explicitly says 'Use when the user asks about Google Ad Grants eligibility or their nonprofit website's readiness for it,' and scopes it out from account-level checks ('Does not access any Google account; passing does not guarantee approval'). It does not name a sibling alternative for overlapping 'is my site OK' questions, so it stops short of full routing guidance.

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

All xfix 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?