Maps Agent

Read a page in full

get_article

Read-onlyIdempotent

The full text of one maps-agent.com page as markdown: title, canonical URL, last-updated date, the answer-first opening, the body with tables, FAQs and numbered sources. Works for any public page on the site, by URL, path or slug. The structured result carries the whole page in body_markdown, with faqs and sources as lists.

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": {
      "ref": "<ref>"
    },
    "name": "get_article"
  }
}

Input Schema

Name	Required	Description	Default
`ref`	Yes	A maps-agent.com page URL (https://maps-agent.com/answers/how-to-get-more-google-reviews), a site path (/glossary/citation) or a slug from search_knowledge / list_articles.
`form`	No	Which form a bare slug belongs to, when the same slug exists in more than one.

Output Schema

Name	Required	Description
`url`	Yes	The page on maps-agent.com — cite it.
`faqs`	Yes	The page's FAQ, also at the end of body_markdown.
`form`	Yes	The page's form.
`slug`	Yes	Its slug inside the form.
`title`	Yes	The page title.
`topic`	No	Grouping inside the form: answer cluster, guide kind, trade, blog vertical.
`sources`	Yes	The sources the page cites; `key` is the footnote marker [^key] in body_markdown.
`summary`	No	One or two plain sentences: the page's description or opening.
`updated`	No	The page's own last-updated day, YYYY-MM-DD.
`markdown_url`	No	The page's markdown twin.
`body_markdown`	Yes	The whole page as markdown: title, URL, date, answer-first opening, body with tables, FAQ and numbered sources. Answer from it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "body_markdown": {
+      "description": "The whole page as markdown: title, URL, date, answer-first opening, body with tables, FAQ and numbered sources. Answer from it.",
+      "type": "string"
+    },
+    "faqs": {
+      "description": "The page's FAQ, also at the end of body_markdown.",
+      "items": {
+        "properties": {
+          "answer": {
+            "type": "string"
+          },
+          "question": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "question",
+          "answer"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "form": {
+      "description": "The page's form.",
+      "enum": [
+        "answer",
+        "guide",
+        "research",
+        "glossary",
+        "blog",
+        "industry",
+        "comparison",
+        "changelog",
+        "page"
+      ],
+      "type": "string"
+    },
+    "markdown_url": {
+      "description": "The page's markdown twin.",
+      "type": "string"
+    },
+    "slug": {
+      "description": "Its slug inside the form.",
+      "type": "string"
+    },
+    "sources": {
+      "description": "The sources the page cites; `key` is the footnote marker [^key] in body_markdown.",
+      "items": {
+        "properties": {
+          "key": {
+            "type": "string"
+          },
+          "label": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "label",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "summary": {
+      "description": "One or two plain sentences: the page's description or opening.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "title": {
+      "description": "The page title.",
+      "type": "string"
+    },
+    "topic": {
+      "description": "Grouping inside the form: answer cluster, guide kind, trade, blog vertical.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "updated": {
+      "description": "The page's own last-updated day, YYYY-MM-DD.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "url": {
+      "description": "The page on maps-agent.com — cite it.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "form",
+    "slug",
+    "title",
+    "url",
+    "body_markdown",
+    "faqs",
+    "sources"
+  ],
+  "type": "object"
+}

First observedNov 9, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld=false, so the safety profile is covered and the description is not burdened there. The description still adds useful behavior: it restricts scope to public pages on one site and tells the agent the page comes back whole in body_markdown with faqs and sources as lists. It stops short of noting what happens for missing pages or slugs that exist in multiple forms, though the latter is delegated to the form parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with what is returned, then scope, then result shape — no filler. The final sentence about body_markdown/faqs/sources mildly overlaps the output schema, but it is short and frames what to expect before reading it.

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 two-parameter, read-only tool with full schema coverage, complete annotations, and an output schema, the description covers purpose, scope and return shape adequately. The only meaningful gap is failure behavior (invalid ref, non-public page, ambiguous slug without form), which is worth one line given the tool resolves references.

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 description coverage is 100%, so both ref and form are already documented, including the URL/path/slug forms and when the form enum applies. The description restates the accepted reference types but adds no syntax, normalization, or precedence guidance beyond the schema, so the baseline 3 is appropriate.

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 description names a specific resource and operation: 'The full text of one maps-agent.com page as markdown', then enumerates the parts returned (title, canonical URL, last-updated date, opening, body with tables, FAQs, sources). Combined with the title 'Read a page in full' and the scope statement 'Works for any public page on the site', an agent can distinguish this fetch-one-page tool from search/discovery siblings 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 Guidelines3/5

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

Usage is only implied: the description establishes scope ('any public page on the site, by URL, path or slug') and the schema's ref field points to slugs from search_knowledge / list_articles, which hints at a discover-then-read flow. It never states when to prefer this over search_knowledge or list_articles, or that it requires an already-known reference, so an agent must infer the sequencing.

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

All Maps Agent 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.