Skip to main content
Glama

Audit prospect

audit_prospect
Read-onlyIdempotent

Audit a business the agency does NOT manage yet, from public data: Google Business Profile completeness, reviews against nearby competitors, the website (speed, titles, broken links), tracking tags, and where it appears in Google Maps-style searches for its core terms. The pitch tool: a scorecard with the three fixes most worth making, in a few minutes, with nothing connected. A section it could not check is marked unverified and claims nothing. Free plan: 5 audits a month; paid plans unlimited. Nothing is sent to the prospect. A website alone is enough; name and city are optional.

Input Schema

NameRequiredDescriptionDefault
cityNoCity and state/region, e.g. Wauseon, OH. Needed only without a website.
nameNoBusiness name, e.g. Smith Plumbing. Needed only without a website, or if the listing is under another name.
speedNoRun Google's mobile speed check on the site (best of two runs, with what slows it; adds 20-60 s)
termsNoUp to 5 'service + city' searches to check, e.g. ['plumber wauseon oh']. Default: built from trade and city.
tradeNoWhat they do, in two or three words, e.g. plumber, fence contractor. Used for the competitor comparison and the search terms.
websiteNoThe business's website. Enough on its own: name, city and trade are then read off its Google listing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / speed / description
      Previous value: -"Run Google's mobile speed check on the site (adds 10-40 s)"New value: +"Run Google's mobile speed check on the site (best of two runs, with what slows it; adds 20-60 s)"
  2. Changed6 schema fields changed
    • changedInput schema / properties / city / description
      Previous value: -"City and state/region, e.g. Wauseon, OH"New value: +"City and state/region, e.g. Wauseon, OH. Needed only without a website."
    • removedInput schema / properties / city / minLength
      Removed value: -2
    • changedInput schema / properties / name / description
      Previous value: -"Business name as the agency says it, e.g. Smith Plumbing"New value: +"Business name, e.g. Smith Plumbing. Needed only without a website, or if the listing is under another name."
    • removedInput schema / properties / name / minLength
      Removed value: -2
    • changedInput schema / properties / website / description
      Previous value: -"Their website if known; otherwise taken from the Google listing"New value: +"The business's website. Enough on its own: name, city and trade are then read off its Google listing."
    • removedInput schema / required
      Removed value: -[
      -  "name",
      -  "city"
      -]
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the annotations: discloses the free-plan rate limit, that unverified sections 'claim nothing' rather than guessing, that nothing is sent to the prospect (no side effects on the target), and that the speed check adds 20-60s. These are exactly the operational traits an agent needs before calling and that readOnlyHint/idempotentHint 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 core action and the checked dimensions before commercial details. Some mild redundancy between 'with nothing connected' and 'Nothing is sent to the prospect,' and the quota detail could sit later, but every sentence carries usable 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?

For a zero-required-param, open-world read tool with no output schema, the description supplies the return shape ('a scorecard with the three fixes most worth making'), the failure mode (unverified sections), timing ('in a few minutes'), and quota limits — nothing an agent needs to decide or call 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%, so the baseline would be 3, but the description adds real meaning: website alone is sufficient, name/city are only needed absent a website or when the listing is under another name, and trade drives both competitor comparison and default search terms. It explains parameter interdependence rather than restating field docs.

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?

Specific verb + resource + scope: 'Audit a business the agency does NOT manage yet, from public data,' then enumerates exactly what is checked (GBP completeness, competitor reviews, site speed/titles/broken links, tracking tags, map rankings). The 'does NOT manage yet' qualifier cleanly separates it from audit_client without needing the schema.

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?

States the context clearly ('The pitch tool'), the prerequisites ('with nothing connected', 'a website alone is enough; name and city are optional'), and the quota (5/month free, unlimited paid). It implies but never names audit_client as the alternative for already-managed businesses, so an agent must infer the boundary.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.