DogPolicies MCP Server

Get place details

dogpolicies_get_place

Read-onlyIdempotent

Retrieve the full dog-rule record for a known place id, including each rule's display text, source URLs, publisher, capture date and quote, plus I-5 axis position and nearby people-stops for paired highway stops.

Instructions

The full record for one place you already know by id: every dog rule with its display text, the rules list, and each source with its URL, publisher, capture date and quote. A place on I-5 in California also carries its axis position (s meters from San Ysidro on the I-5 centerline, Caltrans mile, meters off the road, side of northbound travel, road elevation, strip) and, when it is the dog side of a paired stop, that pair: the exit and the people-stops near it (counted from OpenStreetMap, never named, not verified for restrooms).

Takes a place id, as returned in every search result. Example: id="carmel-beach".

Input Schema

Name	Required	Description	Default
`id`	Yes	Place id, e.g. "fort-funston"
`response_format`	No	'markdown' for readable text, 'json' for structured data	markdown

Output Schema

Name	Required	Description
`id`	Yes
`uid`	Yes	Stable id that survives a rename
`url`	Yes
`axis`	Yes	Where the place sits on the I-5 axis: s meters from San Ysidro, Caltrans mile, meters off the road, side of northbound travel, road elevation, strip; null off I-5
`name`	Yes
`type`	Yes
`as_of`	Yes	Date the data was built (YYYY-MM-DD)
`facts`	Yes
`rules`	Yes
`answer`	Yes
`status`	Yes
`license`	Yes
`sources`	Yes
`citation`	Yes	Copy-ready citation: answer, source, date checked, record URL, license
`freshness`	Yes	fresh: inside its review interval; due: past it; stale: past twice it, confirm before you go; unreadable: the last check could not read the source
`confidence`	Yes	stated: the place's own source says it; inferred_from_agency: an agency-wide rule; inherited_brand: the chain's policy, not confirmed by this hotel
`not_stated`	Yes	Expected facts the sources do not state; never guess these
`review_due`	Yes
`paired_stop`	Yes
`source_urls`	Yes
`verified_at`	Yes
`confirmed_by`	Yes
`rule_records`	Yes
`record_license`	Yes
`attribution_url`	Yes
`attribution_text`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.0Nov 6, 2026

addedOutput schema / properties / axis

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "properties": {
+        "ele": {
+          "type": "number"
+        },
+        "mile": {
+          "type": "number"
+        },
+        "offM": {
+          "type": "number"
+        },
+        "route": {
+          "type": "string"
+        },
+        "s": {
+          "type": "number"
+        },
+        "side": {
+          "type": "string"
+        },
+        "strip": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "route",
+        "s",
+        "mile",
+        "offM",
+        "side",
+        "ele",
+        "strip"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Where the place sits on the I-5 axis: s meters from San Ysidro, Caltrans mile, meters off the road, side of northbound travel, road elevation, strip; null off I-5"
+}

addedOutput schema / properties / paired_stop

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "properties": {},
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "uid",
-  "name",
-  "type",
-  "status",
-  "answer",
-  "citation",
-  "confidence",
-  "confirmed_by",
-  "freshness",
-  "verified_at",
-  "url",
-  "source_urls",
-  "record_license",
-  "as_of",
-  "license",
-  "attribution_text",
-  "attribution_url",
-  "facts",
-  "rule_records",
-  "not_stated",
-  "rules",
-  "sources",
-  "review_due"
-]New value: +[
+  "id",
+  "uid",
+  "name",
+  "type",
+  "status",
+  "answer",
+  "citation",
+  "confidence",
+  "confirmed_by",
+  "freshness",
+  "verified_at",
+  "url",
+  "source_urls",
+  "record_license",
+  "as_of",
+  "license",
+  "attribution_text",
+  "attribution_url",
+  "facts",
+  "rule_records",
+  "not_stated",
+  "rules",
+  "sources",
+  "review_due",
+  "axis",
+  "paired_stop"
+]

First observedv0.2.0Oct 31, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent safety, and the description goes further by disclosing data provenance and caveats an agent must not over-claim: OSM-derived stop counts are "never named, not verified for restrooms." It also describes conditional payload enrichment (I-5 axis fields, paired-stop data) that annotations cannot convey; the only softness is that return-content detail overlaps with the output schema.

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 in the first clause, then the id-acceptance note at the end where it belongs. The intermediate I-5/paired-stop sentence is dense and parenthetical-heavy, but every clause carries real information rather than restating the name.

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?

With a full output schema and rich annotations, the description's remaining job is to flag provenance, caveats, and conditional fields, and it does so. The one gap is that response_format selection is left entirely to the schema default with no guidance on when structured output matters.

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%, so both parameters are already documented, and the description only reinforces the id's origin ("as returned in every search result") with an example. It says nothing about response_format or when to prefer json over the markdown default.

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?

"The full record for one place you already know by id" names a specific verb (retrieve full record), a specific resource (one place), and the exact scope condition (id already known), which cleanly separates it from search_places and get_rule. An agent can tell what this returns without opening 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?

"one place you already know by id" plus "Takes a place id, as returned in every search result" gives a clear prerequisite and implicitly routes the agent through search first. It stops short of naming dogpolicies_search_places as the alternative or saying what to do when the id is unknown.

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

Deploy Server