Skip to main content
Glama
Sign In

Trudex

by dev.trudex
OverviewDiscussionsAdmin

New and opening businesses in a Texas area

find_new_activity
Read-only

What is opening in this Texas city or ZIP? Returns pre-opening and new-outlet signals since a date, one row per address, each with a stage (applied, licensed, permitted, opened) and its source records. With no city or zip it searches all of Texas over the last 7 days (31 at most). Texas only; businesses registered with the Texas Comptroller or TABC, refreshed nightly from Texas state datasets. Filter by NAICS code or category (restaurant, bar, liquor_store, convenience_store, brewery_winery_distillery). Each row carries opening_context: what kind of opening it is (takeover of a closed business's site, ownership_change, expansion by an owner with other locations, existing_business, new_owner, ...), a confidence (high, medium, low) and a plain-language reason. Filter with opening_types and min_confidence. entity_id is null on rows owned by an individual or not linked to a taxpayer. Example: {"city": "Fort Worth", "since": "2026-07-01", "category": "restaurant", "opening_types": ["takeover"], "min_confidence": "high"}.

Input Schema

NameRequiredDescriptionDefault
zipNoZIP code, e.g. "76104".
cityNoTexas city, e.g. "Fort Worth". Omit city and zip for all of Texas.
limitNoAddresses to return, 1-50. Default 25.
naicsNoNAICS code or prefix, e.g. "722511" (full-service restaurants).
sinceNoEarliest signal date, YYYY-MM-DD, within the last two years (31 days statewide). Default 90 days ago (7 statewide).
categoryNoBusiness category. Ignored when naics is given.
opening_typesNoKeep only these kinds of opening, e.g. ["takeover", "ownership_change"]. Drops rows with no opening_context (owned by individuals).
min_confidenceNoKeep only rows whose opening_context confidence is at least this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / min_confidence
      Added value: +{
+  "description": "Keep only rows whose opening_context confidence is at least this.",
+  "enum": [
+    "high",
+    "medium",
+    "low"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / opening_types
      Added value: +{
+  "description": "Keep only these kinds of opening, e.g. [\"takeover\", \"ownership_change\"]. Drops rows with no opening_context (owned by individuals).",
+  "items": {
+    "enum": [
+      "ownership_change",
+      "takeover",
+      "existing_business",
+      "possible_takeover",
+      "expansion",
+      "shared_site",
+      "first_location",
+      "established_owner",
+      "new_owner"
+    ],
+    "type": "string"
+  },
+  "maxItems": 9,
+  "minItems": 1,
+  "type": "array"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / city / description
      Previous value: -"Texas city, e.g. \"Fort Worth\". Give a city or a zip."New value: +"Texas city, e.g. \"Fort Worth\". Omit city and zip for all of Texas."
    • changedInput schema / properties / since / description
      Previous value: -"Earliest signal date, YYYY-MM-DD, within the last two years. Default 90 days ago."New value: +"Earliest signal date, YYYY-MM-DD, within the last two years (31 days statewide). Default 90 days ago (7 statewide)."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover read-only and closed-world; the description adds the behavior an agent actually needs: nightly refresh from state datasets, one row per address, the stage enumeration, that statewide queries cap at 31 rows and two years of history, and that entity_id is null when an owner is an individual or unlinked. The caveat that opening_types filters drop rows lacking opening_context is a genuine non-obvious side effect.

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?

Front-loaded with the question it answers and the return shape, and nearly every clause carries information. The parenthetical enumeration of opening_context kinds ("takeover of a closed business's site, ownership_change, expansion by an owner with other locations, existing_business, new_owner, ...") is a bit sprawling, but it is the only place those semantics are explained.

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 8 all-optional parameters, no output schema, and a non-obvious result model, the description covers coverage limits, defaults, row shape, confidence, and the null-entity edge case. An agent can call this correctly and interpret the response without further documentation.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: what opening_context values represent, the confidence tiers, the interaction between naics and category, and the truncation window on since. It also supplies a worked example call that shows parameter composition, though individual field formats are left to the schema.

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?

The opening line states a specific verb and resource ("What is opening in this Texas city or ZIP? Returns pre-opening and new-outlet signals since a date, one row per address") and pins the geography and data provenance (Texas Comptroller/TABC, refreshed nightly), which cleanly separates it from siblings like get_licenses or get_locations.

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?

It gives concrete operating guidance: omit city and zip to search all of Texas, category is ignored when naics is given, defaults of 90 days (7 days and 31 rows statewide), and filtering via opening_types/min_confidence. It stops short of explicitly naming which sibling tool to use instead when you want raw licenses or entity details.

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

All Trudex toolsInspect
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