Provides tools to search and score local businesses for independence using the Google Places API, including discovering independent businesses, scoring specific businesses, finding farms with online stores, and calculating neighborhood independence indices.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LocalRoots MCP Find an independent coffee shop near Durham, NC."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The independent local businesses the algorithm buries.
Most local-search platforms rank by review volume and star rating. That math optimizes for businesses that already won the visibility game: chains with marketing teams, franchises with ad budgets, and the handful of independents that figured out review velocity. The businesses you actually want to find, the third-generation hardware store, the farm with a direct-to-consumer storefront, the diner that has been on the same corner since 1962, fall to page 4 because they never optimized for the algorithm.
LocalRoots inverts the scoring. It rewards long tenure, low marketing footprint, family ownership name signals, single-location operation, and category-specific markers like e-commerce platform fingerprints for direct-to-consumer farms. It disqualifies national chains. The result is a discovery layer that surfaces what mainstream local search hides.
This is also a counterculture move. The same algorithmic-intermediary dynamic that disadvantages small operators in commerce is the same one that disadvantages property owners in airspace, inventors in patent prosecution, and ordinary people in nearly every system where intermediary access decides who gets seen. LocalRoots applies that thesis to local commerce.
LocalRoots gives Claude five tools that wrap the Google Places API with an opinionated independence-scoring engine. Every result includes the tier (tier_1 = strong independent, tier_4 = chain), the total score, the signal breakdown that produced the score, and a plain-language practical_note so the user can see why a business ranked where it did.
Some things you can ask Claude when this MCP is connected:
"Find an independent coffee shop near Durham, NC."
"Is Maria's Bakery on Main Street actually independent?"
"Is Finca Coffee more independent than the Starbucks next door?"
"Find farms near the Hudson Valley that have a direct-to-consumer online store."
"How independent-business-heavy is East Nashville compared to Brentwood?"
The scoring breakdown is the differentiator. A user who reads it walks away understanding which signals matter for telling a real independent from a regional chain.
Related MCP server: discava – Business Directory for AI
In scope for v0.1:
discover_local_independents: text + location search, scored by LocalRoots' independence framework, chains filtered by default.
score_specific_business: deep-dive a single business by place_id or by name + near.
find_farms_with_online_store: farm search with direct-to-consumer e-commerce platform fingerprinting (GrazeCart, Local Line, Barn2Door, Harvie, Farmigo, GrownBy, LocalHarvest).
neighborhood_local_index: aggregate independence score for a neighborhood across six sample categories.
Out of scope for v0.1:
compare_local_vs_chain: deferred to v0.3 per roadmap (shipped in v0.3).
Wayback Machine integration for inferred founding date (shipped in v0.3).
Live page fetching to detect generic Shopify / Square Online storefronts that are not on the bundled farm-first platform list.
Non-NC Century Farm registries (only NC is tracked in the v0.1 placeholder).
Shipped in v0.2:
Place Details enrichment for discover_local_independents: each result is re-fetched with a Place Details call to fill in editorialSummary, websiteUri, and photo count before scoring. This unlocks tenure and family-ownership signals that searchText cannot surface.
low_digital_footprint signal (+12 points): fires when website, editorial summary, and photo count are all absent or minimal after enrichment, a compound marker that correlates strongly with single-location, marketing-free operators.
Tier threshold recalibration (tier_2: 40 → 25 → 18) based on live API calibration across three cities.
Shipped in v0.3:
compare_local_vs_chain tool: scores a local independent head-to-head against a national chain at the same location. Returns a side-by-side signal breakdown, a score delta, and a plain-language verdict. Includes Wayback Machine tenure inference for the independent.
Wayback Machine CDX tenure inference: checks the Internet Archive for the earliest snapshot of a business website and adds tenure_wayback_pre_2005 (+20), tenure_wayback_pre_2010 (+12), or tenure_wayback_pre_2015 (+6) signals when found. Applied in discover_local_independents, score_specific_business, and compare_local_vs_chain. Free, no API key required.
NC Century Farm sample data: 15 manually researched farms from NCDA&CS public records bundled as a fallback at data/century-farms-nc-sample.json. Schema updated to { name, county, city?, since_year, website? }.
Coming in v0.4:
Population of the full NC Century Farm registry (see CONTRIBUTING.md for the procedure).
Additional category bonuses for breweries, butchers, and tailors.
Optional live page fetch when a farm website looks like a generic storefront.
People who want to spend their money at the operator they will see again, not at a brand. Households trying to move grocery spend from aggregators to farms. Travelers who want to find the real neighborhood spot instead of the algorithm's. Anyone who treats local commerce as something worth defending.
You need a Google Places API key. The API is metered; new Google Cloud accounts include a $300 free trial credit (90-day window), which covers substantial experimentation with this MCP.
Create or pick a Google Cloud project at https://console.cloud.google.com.
Enable Places API (New) in that project. The legacy Places API will not work.
Generate an API key and restrict it to Places API (New) only. Consider also adding an IP or HTTP referrer restriction to prevent the key from being used outside your environment.
Set GOOGLE_PLACES_API_KEY in your MCP server environment.
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"local-roots": {
"command": "npx",
"args": ["-y", "@parissharpe/local-roots-mcp"],
"env": {
"GOOGLE_PLACES_API_KEY": "YOUR_KEY_HERE"
}
}
}
}Restart Claude Desktop. The five tools become available in any conversation.
git clone https://github.com/parissharpe/local-roots-mcp
cd local-roots-mcp
npm install
cp .env.example .env
# put your key in .env
npm run build
npm test
npm run smoke-testdiscover_local_independentsFind independent businesses for a query and location, ranked by LocalRoots' independence score.
Parameters:
query (required): plain English, e.g. "coffee", "hardware store".
near (required): a city, neighborhood, or "lat,lng".
radius_km (optional, default 8, max 50)
max_results (optional, default 10, max 20)
min_tier (optional): tier_1, tier_2, or tier_3.
include_chains (optional, default false): keep chains in the results, mostly for debugging.
Returns each result with place_id, name, formatted_address, tier, total_score, signal_breakdown, and a per-result practical_note. Use the place_id in score_specific_business for follow-up.
score_specific_businessScore a specific business. Either pass place_id (fetched from a previous result or from Google Maps), or pass name plus near. Returns the full signal breakdown and a practical note explaining the tier.
find_farms_with_online_storeFind independent farms within radius of a location and detect direct-to-consumer e-commerce by fingerprinting the farm's website against the bundled platform list. Farms with confirmed DTC are ranked first.
Parameters:
near (required)
radius_km (optional, default 80, max 200)
max_results (optional, default 10, max 20)
product_focus (optional, default "any"): one of meat, produce, dairy, csa, eggs, flowers, any.
neighborhood_local_indexSample a neighborhood across multiple categories (restaurant, coffee, grocery, hardware, bookstore, bakery by default), score each sampled business, and aggregate into a single Local Index plus per-category stats.
Parameters:
neighborhood (required)
radius_km (optional, default 3)
categories (optional): subset of the default list.
sample_size (optional, default 10, max 20): per-category cap.
The Local Index is best read relatively. Compare two neighborhoods rather than treating a single number as definitive.
compare_local_vs_chainScore a local independent directly against a national chain at the same location. Both businesses are resolved via Google Places and run through LocalRoots scoring. Returns a side-by-side breakdown, the score delta, and a plain-language verdict.
Parameters:
independent_name (required): name of the independent business.
chain_name (required): name of the chain to compare against.
near (required): a city, neighborhood, or "lat,lng".
category (optional): one of farm, restaurant, retail, service, other.
The chain will almost always be disqualified (tier_4, -100 points). A warning fires in the verdict if the chain scores higher than the independent, which usually means the chain name is not in the bundled database or the independent has a very thin Google profile. Checks the Wayback Machine for the independent's website to add tenure signals before 2005, 2010, or 2015.
Each tool uses Google Places API (New) calls. The call count matters for billing.
Tool | Call pattern | Default max calls |
| 1 Text Search + up to 10 Place Details (enrichment) + up to 5 Wayback CDX checks (free) | 11 per query |
| 1 Place Details (if | 1-2 per query |
| 1 Text Search | 1 per query |
| 1 Text Search per category (default 6 categories) | 6 per query |
| 2 Text Searches + optional 1 Wayback CDX check for the independent (free) | 2 per query |
Estimated cost per discover_local_independents call (default 10 results):
1 Text Search ($0.032) + 10 Place Details ($0.017 each) = ~$0.20 per call at current Google pricing. See Google Maps Platform pricing for current rates; prices change.
New Google Cloud accounts include a $300 free trial credit (90-day window). At ~$0.20 per discovery query, that covers roughly 1,500 calls before billing begins.
To reduce Place Details calls, lower max_results (e.g., max_results: 5 uses 1 Text Search + 5 Place Details = ~$0.12). The enrichment cap is always 10 regardless of max_results.
Every result carries a signal_breakdown with three sections: universal, category_bonuses, and negatives. Each line item shows the signal name, the points, and why those points were assigned. The total is the sum.
Universal positive signals
century_plus_in_text (+35): "Established 1899" or similar parsed from the name or editorial summary.
half_century_in_text (+25): "Since 1975" or similar.
established_25_plus (+15) / established_10_plus (+8): shorter tenure bands.
family_ownership_in_name (+10): name patterns like & Sons, Family, Maria's Bakery.
family_ownership_in_editorial (+8): explicit "family-owned" / "third-generation" in the editorial summary.
low_review_count (+15) / modest_review_count (+8): 0-49 / 50-199 reviews respectively. The algorithm rewards review velocity, so a sparse footprint correlates with operator-run discovery.
sparse_photo_presence (+5): fewer than 10 photos.
no_website (+5): often the strongest single signal that a business is single-location and word-of-mouth-driven.
low_digital_footprint (+12): website, editorial summary, and photo count are all absent or minimal after Place Details enrichment. Chains and franchises maintain robust Google profiles; this combination strongly correlates with single-location, operator-run businesses.
no_chain_signal (+10): no national-chain name match. The baseline assumption of independence.
Wayback Machine tenure signals (applied when a website is on file and the Wayback CDX API is reachable; free, no key required)
tenure_wayback_pre_2005 (+20): Wayback Machine shows an archived snapshot before 2005. A web presence before social media and review aggregators suggests the business predates the algorithmic-discovery era.
tenure_wayback_pre_2010 (+12): earliest snapshot before 2010.
tenure_wayback_pre_2015 (+6): earliest snapshot before 2015. A decade-plus web presence predates the mass adoption of business discovery apps.
wayback_no_snapshot (0, informational): CDX confirms no snapshot found. Not scored against the business; surfaced so you can see the check ran.
Category-specific bonuses
Farms: ecommerce_platform:* (+25 or +15 depending on platform signal strength) for a confirmed direct-to-consumer storefront on one of the seven bundled platforms; nc_century_farm (+30) for a registry match; century_farm_registry_pending (+0, NC addresses only) as a placeholder when the registry has not been populated yet.
Restaurants: independent_kitchen_signal (+12) for scratch / from-scratch / chef-owned mentions in the editorial summary.
Retail: independent_retail_signal (+10) for locally-owned / independent mentions in the editorial summary.
Negative signals
algorithmic_winner (-20): 2000+ reviews. Even if independent, the business does not need LocalRoots to find it.
algorithmic_well_known (-10): 800-1999 reviews.
national_chain_detected (-100): hard disqualification. The business gets tier_4 and is filtered from results unless include_chains: true.
Tier thresholds
tier_1 (≥70): strong independent. Requires tenure or compound ownership signals.
tier_2 (≥18): likely independent. At minimum: 50-199 reviews and no chain name match.
tier_3 (≥10): ambiguous. Insufficient signal to confidently call it independent.
tier_4: chain or chain-equivalent, disqualified.
The Google Places editorial summary is not always populated. When it is missing, tenure and family-ownership detection falls back to the business name alone, which is a weaker signal. Wayback Machine tenure inference partially compensates when a website is on file.
Tenure is inferred, not authoritative. A business that started in 2003 but rebranded with "Since 1924" marketing would score as if it has been there since 1924. The scoring is honest about this: it tells you which year string it parsed.
The NC Century Farm registry main file is bundled empty. A 15-entry sample from NCDA&CS public records is bundled as a fallback so the nc_century_farm bonus fires for testing. To get full coverage, populate data/century-farms-nc.json per the procedure in CONTRIBUTING.md.
The chain database is curated and not exhaustive. Regional chains are deliberately omitted so that, for example, a regional grocer that still feels local is not disqualified. Use include_chains: true to inspect.
Generic e-commerce platforms (Shopify, Square Online, custom) are not fingerprinted. A farm running its own Shopify store will not register a has_online_store even though it has one. v0.2 may add a live page fetch fallback.
Apache License 2.0
Score a local independent head-to-head against a national chain at the same location. Resolves both businesses via Google Places, runs LocalRoots scoring on each, and returns a side-by-side breakdown with a score delta and plain-language verdict. Use this when a user wants to understand exactly how much more independent a local spot is compared to the chain down the street, or to validate that a suspected chain is actually disqualified. National chains will score tier_4 (disqualified) in almost all cases. A warning fires if the chain somehow scores higher than the independent, which usually means the chain name is not in the bundled database or the independent has a very thin Google profile. Checks the Wayback Machine for the independent's website to infer tenure before 2005, 2010, or 2015.
| Name | Required | Description | Default |
|---|---|---|---|
| near | Yes | ||
| category | No | ||
| chain_name | Yes | ||
| independent_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the Google Places resolution, LocalRoots scoring, side-by-side output, warning behavior, and Wayback Machine tenure check. While it doesn't mention side effects or rate limits, it offers substantial behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At five sentences, the description is slightly long but every sentence adds useful information. The first sentence is a strong front-loaded summary, and the rest covers usage, edge cases, and the tenure check.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the key output elements (side-by-side breakdown, delta, verdict) and process steps. It also handles likely edge cases (chain scoring higher, thin Google profile) and the tenure check, making it quite complete for a comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explicitly name the parameters (independent_name, chain_name, near, category). It implies their roles contextually (independent vs chain, location) but leaves category unexplained and doesn't provide format details, so compensation is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Score a local independent head-to-head against a national chain.' It clearly distinguishes from siblings by focusing on comparison, and details the process and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this when a user wants to understand exactly how much more independent a local spot is compared to the chain down the street, or to validate that a suspected chain is actually disqualified.' This provides clear use cases, though it doesn't name alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find independent local businesses for a given query and location, ranked by LocalRoots' independence score instead of Google's review-volume default. The algorithm penalizes high review counts, disqualifies national chains, and rewards long tenure, family-ownership name signals, sparse marketing footprint, and (for farms) direct-to-consumer e-commerce. Use this when a user asks for local coffee, an independent bookstore, a real bakery, etc. Returns up to max_results businesses, each with a tier (tier_1 = strong independent, tier_4 = chain), the total score, the full signal_breakdown, and a per-result practical_note. Always include the place_id from results so follow-up tools can reference the specific business.
| Name | Required | Description | Default |
|---|---|---|---|
| near | Yes | ||
| query | Yes | ||
| min_tier | No | ||
| radius_km | No | ||
| max_results | No | ||
| include_chains | No | Override the chain filter. Default false: chains are removed. Set true if you want to see them ranked next to independents (rare, mostly for debugging the score). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and it delivers: it details the algorithm's penalties and rewards (high review counts, chain disqualification, tenure, etc.), explains the tier system (tier_1 through tier_4), and indicates it returns a score breakdown and practical_note. It also instructs the agent to always include place_id, which is practical behavioral guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: first gives purpose and ranking, second gives usage trigger and examples, third describes output and the place_id follow-up. It is front-loaded with the core purpose and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains what is returned (tier, total score, signal_breakdown, practical_note) and gives follow-up guidance about place_id. It is less complete on parameter details like radius_km and min_tier, but overall the tool has enough context for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (just include_chains), so the description must compensate. It does explain 'query' and 'near' as the query and location, mentions max_results explicitly, and touches on include_chains via chain disqualification and min_tier via tier definitions. However, it never clarifies the meaning or filtering behavior of radius_km or how min_tier values map to filtering, leaving a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Find' and a clear resource: 'independent local businesses for a given query and location,' with a differentiating ranking criterion ('LocalRoots' independence score instead of Google's review-volume default'). It distinguishes itself from siblings like find_farms_with_online_store by covering general local business discovery and from score_specific_business by focusing on a list of results rather than one business.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit trigger examples ('Use this when a user asks for local coffee, an independent bookstore, a real bakery, etc.'), which is strong guidance. However, it does not explicitly state when not to use the tool or point to alternative sibling tools for specific cases (e.g., farms or scoring a known business), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find independent farms near a location that have direct-to-consumer e-commerce. Detection works by fingerprinting the farm's website against the bundled list of farm-first DTC platforms (GrazeCart, Local Line, Barn2Door, Harvie, Farmigo, GrownBy, LocalHarvest). Farms confirmed to have a DTC store are ranked first, then other independent farms without a confirmed store. Use this when a user wants to buy direct from a farm without going through an aggregator or marketplace. Optional product_focus narrows by meat / produce / dairy / CSA / eggs / flowers.
| Name | Required | Description | Default |
|---|---|---|---|
| near | Yes | ||
| radius_km | No | ||
| max_results | No | ||
| product_focus | No | any |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it reveals the detection method (fingerprinting against a specific platform list), the ranking behavior (DTC-confirmed farms first, then unconfirmed), and the optional product_focus filter. It lacks details on error handling or result format, but it is far more transparent than typical tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded. Five sentences cover purpose, detection method, ranking, usage guidance, and parameter semantics, with no fluff. The structure flows logically from 'what' to 'how' to 'when'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters and no output schema, the description covers the core purpose, detection approach, ranking, and usage context. It does not explain return values or the three unspecified parameters, but these are somewhat secondary for a local search tool. Overall, it is more complete than average but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only explains product_focus (listing valid values) and leaves near, radius_km, and max_results undefined. While names are somewhat self-explanatory, 'near' format and radius_km units are not clarified. This is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (`Find`) and resource (`independent farms near a location`) and clearly states the unique capability: detecting direct-to-consumer e-commerce via website fingerprinting. It distinguishes from sibling tools by focusing on farm-first DTC platforms and ranking confirmed stores first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'when a user wants to buy direct from a farm without going through an aggregator or marketplace.' It does not list alternatives or exclusions, but the context is clear and actionable. No mention of sibling tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a neighborhood for its overall independent-business density. Samples each of a set of categories (restaurant, coffee, grocery, hardware, bookstore, bakery by default), runs LocalRoots scoring on each result, and aggregates into a single Local Index plus per-category stats. Use this when a user asks 'how local is X neighborhood' or wants to compare two areas. The per-category breakdown is the real signal; a neighborhood can be chain-dominant for restaurants and strongly independent for hardware, and surfacing that nuance is the point.
| Name | Required | Description | Default |
|---|---|---|---|
| radius_km | No | ||
| categories | No | ||
| sample_size | No | ||
| neighborhood | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the sampling methodology, LocalRoots scoring, aggregation into a Local Index, and the emphasis on per-category breakdown. However, it does not address potential external API calls, rate limits, or exact interpretation of the output score scale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 3 sentences, front-loads the main purpose, and includes a purposeful explanation of why per-category stats matter. It is concise without unnecessary filler, though the final sentence is more explanatory than operational.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description provides a reasonable overview of the tool's purpose, methodology, and use case, but it leaves gaps such as the default values for radius_km and sample_size, the expected output format details, and potential edge cases. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the default categories list, which is helpful, but it does not explain the semantics of radius_km, sample_size, or how the neighborhood parameter is used. This leaves users guessing about important parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Score a neighborhood'), the subject ('independent-business density'), and the output ('single Local Index plus per-category stats'). It also implicitly distinguishes itself from sibling tools by focusing on neighborhood-level aggregation, not individual business scoring or farm discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool 'when a user asks how local is X neighborhood or wants to compare two areas,' which provides clear usage context. It does not explicitly list when-not-to-use cases or alternative sibling tools, but the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a specific business by place_id, or by (name + near). Returns the same tier and signal_breakdown shape as discover_local_independents, but for a single place the user already has in mind. Use this when a user asks 'is X actually independent?' or wants to understand why a particular business ranked where it did. Will fetch Place Details from Google Places if a place_id is given, or run a top-1 text search if only name+near are given.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| near | No | ||
| place_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: fetching Place Details from Google Places when place_id is given, and running a top-1 text search when only name+near are given. It also mentions the return shape mirrors discover_local_independents, which sets expectations about the response. It doesn't cover side effects or rate limits, but for a scoring tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: it states the purpose, clarifies the return shape, provides usage context, and explains parameter behavior in a few sentences. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking annotations and output schema, the description covers the core aspects: inputs, behavior, usage scenario, and return shape reference. It relies on discover_local_independents for the exact shape, which is acceptable given sibling context. It could be more self-contained, but it's sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It does: 'by place_id, or by (name + near)' and details that place_id triggers a Places fetch while name+near triggers a text search. This gives meaningful semantics to all three parameters beyond bare names, though it doesn't address the case when both are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Score a specific business'. It clearly distinguishes from sibling tools by stating it's for a single place the user already has in mind, versus discovery-oriented siblings like discover_local_independents and find_farms_with_online_store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'Use this when a user asks "is X actually independent?" or wants to understand why a particular business ranked where it did.' It implies the tool is not for broad discovery, but does not explicitly state exclusions or name all alternative tools, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0compare_local_vs_chaindiscover_local_independentsfind_farms_with_online_storeneighborhood_local_indexscore_specific_businessEach tool targets a distinct scenario: specific business scoring, open-ended discovery, farm-specific search, neighborhood aggregation, and head-to-head comparison. No two tools have unclear boundaries or are likely to be confused.
Most names follow a verb_noun pattern (score_specific_business, discover_local_independents, find_farms_with_online_store, compare_local_vs_chain). 'neighborhood_local_index' is a noun phrase, which is a minor deviation from the otherwise consistent pattern.
Five tools is a compact, well-scoped set for the domain. Each tool serves a clear use case with no redundancy.
The server covers single-business scoring, discovery, comparison, and neighborhood aggregation, plus a niche vertical (farms). Minor gaps like accessing the category list for the index are workable around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Local business intel for AI agents: audits, lead scoring, tech stack, prospecting.
Google Maps places, reviews, contributor history, photos and posts as JSON. No Google Cloud.
Local business lead extraction with email + phone enrichment from Google Maps.
Verified directory of 44,000+ Black-owned U.S. businesses. Search, maps, loyalty rewards.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/parissharpe/local-roots-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server