Mogean POI data store

Catalog overview

mogean_catalog_info

Read-onlyIdempotent

Describe the catalog: the current data release and how fresh it is, sellable totals, the provenance tiers, what each kind of product contains, and the limits and tools that apply to this connection.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "mogean_catalog_info"
  }
}

Input Schema

Name	Required	Description	Default
`response_format`	No	concise (default) returns a short summary; detailed adds the full structured result as text.	concise

Output Schema

Name	Required	Description	Default
`data`	No
`tool`	Yes
`limit`	No
`errors`	No
`status`	Yes
`message`	Yes
`drop_date`	No
`permalink`	No
`attribution`	No
`response_format`	Yes
`manifest_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine content-scope disclosure beyond that — freshness of the release, provenance tiers, per-product contents, and connection-level limits/tools. It stops short of describing how these are organized or any caveats on staleness, which keeps it at 4 rather than 5.

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?

One sentence, front-loaded with the verb and resource, with the content list following immediately. Every clause corresponds to something the tool actually reports, so nothing is padding, though the enumerations run long for what is essentially a single informational call.

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?

The tool is a simple, no-required-parameter read with an output schema and full schema coverage, so the description needn't explain return structures. It adequately conveys the breadth of the overview. The remaining gap is operational placement — whether an agent should call this before the sibling query tools — which the description leaves unstated.

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% and the single optional parameter's enum values are documented in the schema itself, so the baseline of 3 applies. The description never mentions response_format or how verbosity affects the returned detail, so it adds nothing on top of the structured field.

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?

The description pairs a specific verb ("Describe") with a specific resource ("the catalog") and enumerates exactly what the overview covers: current data release and freshness, sellable totals, provenance tiers, product contents, and connection limits/tools. That is far more concrete than a tautological restatement of the title. It doesn't explicitly contrast with siblings (fetch, count, preview, search), but the metadata-vs-data distinction is inferable from the content list.

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: an agent can infer this is the orientation/metadata call before using the data-querying siblings, especially from the phrase "the limits and tools that apply to this connection." There is no explicit "call this first" instruction, no when-not-to-use case, and no sibling named as an alternative.

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

All Mogean POI data store 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?