CoreLoop Business Network

compare_business_services

Read-only

Compare one business's services within a category or keyword, with a price/duration summary. Each row reports match_type, so you can tell an exact category hit from an incidental keyword.

Input Schema

TableJSON Schema

Name	Required	Description
`business`	Yes	Which business to ask: its CoreLoop slug, or the `business_id` returned by search_businesses. `business_id` is an opaque, stable, public routing identifier — safe to store and re-use across sessions, unchanged by a rename or a slug change, and carrying no sensitive information. Pass back exactly the value search_businesses gave you: do not parse it, do not infer meaning from its format, and do not construct one.
`compare_by`	No	Restrict the comparison to these fields. Recognised values: price, duration, description, includes (name, category and match_type are always present; unrecognised values are ignored). Omit for the full comparison view.
`service_type`	Yes	Service category or keyword to compare. Matches category exactly first, then service name/description contains.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`locale`	No
`business`	No
`services`	No
`verified`	No
`suggestion`	No
`data_source`	No
`last_updated`	No
`service_type`	No
`business_name`	No
`comparison_summary`	No

Schema Changelog

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

Changed1 schema field changedAug 25, 2026

changedOutput schema / properties / services / items / properties / price_type / enum

Previous value: -[
-  "fixed",
-  "from",
-  "range",
-  "hourly",
-  "free",
-  "contact",
-  "by_quote",
-  "unpublished",
-  null
-]New value: +[
+  "fixed",
+  "from",
+  "range",
+  "hourly",
+  "free",
+  "contact",
+  "recurring",
+  "by_quote",
+  "unpublished",
+  null
+]

First observedAug 19, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent: 'Compare' and 'summary' are read-oriented operations, so there is no annotation contradiction. The description adds useful behavioral nuance beyond the annotations by explaining that each row reports match_type and that the results distinguish exact category hits from incidental keyword matches. It could disclose more (e.g., behavior when a business has no matching services), but for a read-only comparison tool the bar is met.

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?

Two sentences, each earning its place: the first delivers the tool's action and output type, the second highlights a distinguishing behavioral feature of the results. Information is front-loaded; the most decision-relevant detail ('Compare one business's services') comes first. There is no filler, tangential context, or repetition of schema content.

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?

Given the rich input schema, output schema presence, and read-only annotations, the description does not need to restate returns or parameter details. It meaningfully covers the usage scenario and the match_type nuance. Minor gap: the description does not explicitly indicate what happens when no services match or when compare_by is omitted, though the schema already covers the compare_by omission case.

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 input schema is 100% covered with rich per-parameter descriptions: business explains slug vs business_id semantics, service_type explains exact-match-then-containswith match order, and compare_by documents recognized values including omission behavior. The description itself adds only a high-level restatement of the 'category or keyword' concept and the price/duration summary, which echo what the schema already documents. With full schema coverage, baseline 3 is appropriate; the description does not meaningfully deepen parameter understanding.

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 states a specific verb ('Compare'), a precise resource (one business's services), a scoping dimension (category or keyword), and an explicit result type (price/duration summary), making the core purpose clear. It also adds the match_type detail, which meaningfully distinguishes exact category hits from incidental keyword matches. However, it does not explicitly name its closest sibling alternatives (e.g., get_business_services or search_businesses), so sibling differentiation relies on inference rather than statement.

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 description conveys clear context for when the tool is appropriate: when the agent needs a comparative price/duration view of one business's services within a category or keyword, distinguishing exact from incidental matches. It does not, however, provide explicit when-not-to-use guidance or explicitly name alternatives such as get_business_services or search_businesses. The usage scenario is clear enough that the agent is unlikely to misuse it, but exclusions are not stated.

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

All CoreLoop Business Network 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

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct aspect of a business: availability hours, service comparison, agent endpoint metadata, full profile, service catalogue, directory search, and sending inquiries. No two tools overlap in purpose; boundaries are clear.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, with most retrieval tools sharing the get_business_ prefix (get_business_info, get_business_services, get_business_agent) and clear verbs for actions (search, check, compare, send). The pattern is predictable and unambiguous.

Tool Count5/5

Seven tools is well within the ideal 3-15 range and aptly covers the core operations of a business directory: search, view details, services, availability, compare, and inquire. Each tool earns its place with no redundancy.

Completeness5/5

The set covers the full user journey from searching the directory, retrieving business profiles and service details, checking availability, comparing offers, and initiating contact. It also includes agent metadata for programmatic integration. No obvious missing operations for the stated purpose.

Resources

Need Help?