franchisedata-mcp

Describe Endpoint Schema and Pricing

describe_endpoint

Read-onlyIdempotent

Inspect any franchisedata.io REST API endpoint to verify required query parameters, authentication headers, and per-call pricing before calling fetch_franchise_data.

Instructions

FREE. Inspect technical documentation, supported query parameters, authentication methods, and per-call pricing for any REST API route on franchisedata.io. Read-only operation requiring no API key or balance. Rate limit: 60 req/min. Returns 404 if the endpoint route is unrecognized. WHEN TO USE: Use before calling 'fetch_franchise_data' to verify required query parameters, authentication headers, and per-request prices. WHEN NOT TO USE: Do not use to fetch actual brand data records; use 'fetch_franchise_data' or specialized shortcut tools instead. ALTERNATIVES: Use 'search_brands' to discover brand slugs; use 'fetch_franchise_data' to execute the request.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`endpoint`	Yes	Target REST API path to inspect (e.g. '/api/brands/mcdonalds/locations', '/api/brands/tacobell/operators').

Output Schema

TableJSON Schema

Name	Required	Description
`formats`	No	Supported response formats
`pricing`	Yes	Per-request pricing description
`endpoint`	Yes	Requested endpoint path
`authentication`	No	Accepted authentication headers
`supported_methods`	Yes	Supported HTTP methods

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.1Oct 6, 2026

changedInput schema / properties / endpoint / description

Previous value: -"Endpoint path, e.g. '/api/brands/mcdonalds/locations'"New value: +"Target REST API path to inspect (e.g. '/api/brands/mcdonalds/locations', '/api/brands/tacobell/operators')."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "authentication": {
+      "description": "Accepted authentication headers",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "endpoint": {
+      "description": "Requested endpoint path",
+      "type": "string"
+    },
+    "formats": {
+      "description": "Supported response formats",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "pricing": {
+      "description": "Per-request pricing description",
+      "type": "string"
+    },
+    "supported_methods": {
+      "description": "Supported HTTP methods",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "endpoint",
+    "supported_methods",
+    "pricing"
+  ],
+  "type": "object"
+}

First observedv1.0.0Oct 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only cover readOnly/idempotent/closed-world; the description adds the traits that actually matter for calling it: free of charge, no API key or balance required, a 60 req/min rate limit, and explicit 404 behavior for unrecognized routes. This is well beyond what the structured fields provide.

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?

Front-loads the most decision-relevant fact ('FREE') and then chunks behavior and routing into labeled sections. Dense with no filler sentences; each clause carries a distinct operational fact.

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?

An output schema exists, so return-value description is unnecessary. With the cost, auth, rate-limit, and error behavior all stated, an agent has everything needed to invoke this correctly.

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% and the single 'endpoint' parameter is already documented with examples in the schema. The description restates the target as 'any REST API route' but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb (Inspect/Describe) and resource (REST API route schema, auth, pricing) and explicitly scopes it to franchisedata.io endpoints. It clearly distinguishes itself from 'fetch_franchise_data' and the shortcut tools, so an agent can route between them without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Contains explicit WHEN TO USE, WHEN NOT TO USE, and ALTERNATIVES sections naming the sibling tools and the conditions that select them. Nothing about tool selection is left to inference.

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

Deploy Server