GoVisit MCP

Get place overview

get_place_overview

Read-only

Return the published overview for this GoVisit place, including its published classifications with scheme, recipient, validity and available evidence, and its operating status: operatingStatus.code is operational, temporarily_closed or permanently_closed, and null when the status is unknown. Operating status says whether the place still operates, not whether it is open right now. The result excludes place spatial details, which are available from the Location section, and includes freshness metadata from the page snapshot. Owner, chain and operator are organization names, each null when unknown; operator identifies the company managing the facility, distinct from profile management.

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": {
      "pagePath": "<pagePath>"
    },
    "name": "get_place_overview"
  }
}

Input Schema

Name	Required	Description	Default
`pagePath`	Yes	Canonical GoVisit page path supplying this tool's published context; no origin, query or fragment.

Output Schema

Name	Required	Description	Default
`data`	Yes
`locale`	Yes
`pageId`	Yes
`pageType`	Yes
`freshness`	Yes
`updatedAt`	Yes
`canonicalUrl`	Yes
`completeness`	Yes
`schemaVersion`	Yes
`contentVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Adds substantial behavior beyond the read-only annotations: published classifications include scheme, recipient, validity and evidence; operatingStatus uses named codes plus null for unknown; and the description clarifies that operating status means whether the place still operates, not current open status. It also explains exclusions, freshness metadata, and null semantics for owner, chain and operator.

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?

The description is front-loaded with the purpose and then adds dense but useful semantic details. It is longer than a minimal definition, but each sentence contributes scoping, status meaning, exclusions, or null-field semantics rather than repeating annotations.

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 read-only, single-parameter tool with an output schema, the description supplies enough context about scope, status codes, exclusions, freshness metadata, and organization-name semantics. The output schema can carry structural return details, so no critical behavioral gap remains.

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?

The schema has 100% description coverage for pagePath, including format constraints and examples, so the structured field already carries the parameter meaning. The description does not add further parameter guidance, which is acceptable given the high coverage but does not exceed the baseline.

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?

States a specific verb and resource: returns the published overview for a GoVisit place, covering classifications and operating status. It also scopes the result by excluding spatial details, which helps distinguish it from a section-level tool, though it does not explicitly name sibling tools.

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?

The first sentence establishes the use case, and the description explicitly notes that spatial details are excluded and available from the Location section, giving one clear alternative. It stops short of explicit when-to-use guidance against other place-level siblings such as visit facts.

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

All GoVisit MCP 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?