ranked

One Ranked place page, with its rank and register matches

ranked_place

Read-onlyIdempotent

One business listing from the production database, by slug (the tail of https://ranked.ng/place/) or by name + city. Returns name, category, city, state, address, phone (business phones are public), website, Google rating/review count, the evidence-only verified tier, its rank on its primary PUBLISHED facet if any, regulator-register matches (with 'as accessed on' provenance), the canonical url, data_as_of (when Ranked last fetched the listing), and observations: the dated record of what changed on the listing (name, address, phone, website, business status, opening hours), newest first, each with the source that reported it. Places that are not OPERATIONAL are excluded unless includeClosed=true.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	city slug or name (used with name)
`name`	No	business name (used with city when slug is absent)
`slug`	No	place slug, e.g. 'abbey-mortgage-bank-plc-k5mjcu'
`includeClosed`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond readOnly/idempotent annotations, the description reveals meaningful behavior: business phones are public, verified tier is evidence-only, ranks apply only to the primary PUBLISHED facet, register matches carry 'as accessed on' provenance, and non-OPERATIONAL places are excluded unless includeClosed=true. This gives the agent a realistic model of what the data means and its freshness semantics.

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?

Three dense sentences with the core purpose front-loaded before field enumeration. The field list is long but necessary because there is no output schema; however, a single monolithic sentence makes it slightly harder to scan than structured bullets would.

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?

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: identity, category, location, contact, ratings, verification, rank, regulator provenance, data freshness, and observation history. Parameter semantics are covered, and the closed-place exclusion closes the main behavioral gap.

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 already describes city, name, and slug; the description adds the URL-tail interpretation of slug, the slug-or-name+city combination rule, and explains includeClosed's effect (include non-operational places), which is not documented in the schema. Since coverage is 75%, this extra semantic filler is valuable.

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?

Description begins 'One business listing from the production database' and immediately specifies lookup keys (slug or name + city), making the resource and action unambiguous. It also summarizes the specific returned payload (rank, register matches, observations), clearly distinguishing it from sibling search/ranking 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?

Clear usage context: fetch a single place by slug URL tail or by name+city, with includeClosed controlling closed-place visibility. It doesn't explicitly name sibling alternatives or state when to prefer this over ranked_find_business, but the single-page scope and lookup keys provide strong situational guidance.

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

All ranked tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct query type: bulk regulator lists, single-name licence checks, single-product payment eligibility, multi-product comparison, dataset search, place details, rankings, hub browsing, and stats. Descriptions explicitly cross-reference the related tools (e.g., find_business directs users to rankings/place), so an agent should not confuse them.

Naming Consistency4/5

All tool names share the consistent ranked_ prefix and snake_case style, which is predictable. However, the suffix mixes clean verb-object forms (check_licence, find_business, compare) with other patterns (by_regulator, can_nigerian_pay, place, rankings, hubs), so it is not a uniform verb_noun convention.

Tool Count5/5

Nine tools is well within the ideal range for a read-only Nigerian business/regulator data server. Each tool earns its place by covering a distinct query workflow: register lookups, licence checks, payment eligibility, comparison, search, place details, rankings, hub navigation, and dataset stats.

Completeness4/5

The surface covers the core domain thoroughly: bulk regulator access, name-based licence checking, product usability, place details, rankings, search, and provenance stats. Minor gaps remain, such as no explicit state-level ranking endpoint and limited ability to list every place in a category beyond the top-25 published ranking, but there are no obvious dead ends.

Resources

Need Help?