Verified Texas business records for AI agents: entities, licenses, openings and enforcement history.
Scored across 7 tools
Each tool has a distinct primary purpose: resolving an entity, retrieving profile, locations, licenses, timeline, affiliates, or geographic new activity. There is some overlap because get_entity returns summary counts and permits while get_licenses gives license detail, and get_locations has an include_affiliates option that touches find_affiliates, but descriptions generally make boundaries clear.
All seven tools follow a consistent snake_case verb_noun pattern: find_affiliates, find_new_activity, get_entity, get_licenses, get_locations, get_timeline, resolve_business. The convention is predictable and readable throughout.
Seven tools is well-scoped for a Texas business intelligence server. Each tool corresponds to a meaningful retrieval task, and the set is neither thin nor bloated.
The core surface covers entity resolution, profiles, locations, licenses, timelines, affiliates, and new-activity discovery. However, get_entity explicitly references get_motor_carriers and get_labor_record for full records, but those tools are absent from the set, creating dead ends for agents following the descriptions.
Which other entities are likely under common control with this one, and who did it take over from or hand over to? Returns affiliates with relation_type (shared trade name, shared mailing address, similar name in the same city), confidence and the evidence that matched; plus took_over_from and taken_over_by: businesses that followed one another at the same premises under the same or a similar trade name (a sale or a reorganisation, not common control), each handover dated. Texas only; businesses registered with the Texas Comptroller or TABC, refreshed nightly from Texas state datasets. Inferred links, not ownership records. Example: {"entity_id": "32057926266"}.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | entity_id from resolve_business (11-digit Texas taxpayer number), or a 10-digit SOS file number. | |
| min_confidence | No | Only affiliates at or above this confidence, 0.5-1. Default 0.5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the readOnlyHint/openWorldHint annotations: it discloses geographic scope (Texas only), data provenance (Texas Comptroller or TABC), refresh cadence (nightly), and a critical epistemic caveat ('inferred links, not ownership records'). It also characterizes what the two relationship categories mean (common control vs. handover/sale), which prevents misreading the results.
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 answer returned is front-loaded and the caveats follow, with a concrete example at the end. It is dense — nested parentheticals and a long second sentence — but essentially every clause carries distinct information about outputs or limitations.
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?
There is no output schema, so the description carries the full burden of describing returns (relation_type, confidence, evidence, took_over_from/taken_over_by, dates) and it does so. Scope, provenance, refresh, and the inferred-not-ownership limitation round out what an agent needs to call and interpret this 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 description coverage is 100%, with both entity_id formats and the min_confidence range/default already documented in the schema. The description adds no extra meaning for the parameters themselves, so the baseline of 3 applies.
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?
Opens with the exact question the tool answers and names the resource: other entities under common control, plus predecessor/successor handovers. It distinguishes itself from get_entity/resolve_business by framing an inference task (affiliate discovery) rather than a lookup.
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?
Framing the tool as the answer to 'which other entities are likely under common control' gives clear context for when to reach for it, and the entity_id provenance (from resolve_business) is stated. It doesn't explicitly exclude cases (e.g. use get_locations when you want a single address, or get_entity for direct record data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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"}.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ZIP code, e.g. "76104". | |
| city | No | Texas city, e.g. "Fort Worth". Omit city and zip for all of Texas. | |
| limit | No | Addresses to return, 1-50. Default 25. | |
| naics | No | NAICS code or prefix, e.g. "722511" (full-service restaurants). | |
| since | No | Earliest signal date, YYYY-MM-DD, within the last two years (31 days statewide). Default 90 days ago (7 statewide). | |
| category | No | Business category. Ignored when naics is given. | |
| opening_types | No | Keep only these kinds of opening, e.g. ["takeover", "ownership_change"]. Drops rows with no opening_context (owned by individuals). | |
| min_confidence | No | Keep only rows whose opening_context confidence is at least this. |
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.
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.
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.
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.
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.
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.
What is this business legally, and is it in good standing? Returns the legal profile for an entity_id: legal name, organization type, SOS file number, charter date, SOS status, right to transact business (forfeited means franchise tax forfeiture), mailing address, and counts of locations, TABC licenses and affiliates. Also returns state_permits (Comptroller fuels, IFTA, interstate trucker, tobacco, hotel occupancy tax and direct-pay permits, flagging suspended permits and hotel locations gone out of business) and tabc_credit_law_delinquency (appearances on TABC's Credit Law Delinquent List: a wholesaler reported unpaid alcohol deliveries, so the retailer may buy for cash only while listed), federal_exclusions (active SAM.gov debarments and suspensions, shown only where the excluded firm has this entity's exact name and street address; an empty list is not a clearance), motor_carriers (FMCSA USDOT numbers with the same name and street address, each flagging an out-of-service order in force; get_motor_carriers has the full record), and labor_summary (five-year OSHA and wage-and-hour totals for records with the same name and street address; get_labor_record has the records). Texas only; businesses registered with the Texas Comptroller or TABC, refreshed nightly from Texas state datasets. Example: {"entity_id": "32057926266"}.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | entity_id from resolve_business (11-digit Texas taxpayer number), or a 10-digit SOS file number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them: nightly refresh from state datasets, Texas-only coverage, the meaning of 'forfeited' (franchise tax), what appearing on the credit-law delinquency list implies for the retailer, and the crucial caveat that federal_exclusions matches on exact name AND street address so an empty list is not a clearance. That last point materially changes how an agent should interpret the result.
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?
Front-loaded with the core question and the primary return fields, then grouped by sub-section (state_permits, tabc_credit_law_delinquency, federal_exclusions, motor_carriers, labor_summary). It is dense and long, and the run-on structure makes it easy to skim past the important caveats, but essentially every clause carries semantic weight.
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?
There is no output schema, so the description must carry the return-value burden, and it does so exhaustively, including per-section interpretation rules and disclaimers. Combined with readOnly/openWorld annotations, an agent has everything needed to call and interpret this 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 100% and the single entity_id parameter is fully documented in the schema, so the baseline is 3. The description adds a worked call example and reinforces that the id originates from resolve_business, giving practical call-site value, though it does not restate the schema's 10-digit SOS file number alternative.
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?
Opens with the actual question the tool answers ('What is this business legally, and is it in good standing?') and then enumerates the exact fields returned, so an agent knows precisely what resource it is fetching. It also draws the boundary against siblings by pointing to get_motor_carriers and get_labor_record for full records.
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?
Clearly scopes applicability (Texas only, Comptroller/TABC-registered businesses, refreshed nightly) and routes sub-question depth to get_motor_carriers and get_labor_record. It implies but never explicitly states the sibling relationship to resolve_business or when to prefer this over get_licenses/get_locations, so it is strong but not a complete when/when-not map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What alcohol licenses does this business hold or has it held? Returns TABC licenses with type, trade name, status and issue, status-change and expiration dates, each with how it was linked to the entity and the link's confidence, and any TABC Credit Law Delinquent List appearances (unpaid wholesaler credit). Texas only; businesses registered with the Texas Comptroller or TABC, refreshed nightly from Texas state datasets. Example: {"entity_id": "32057926266", "active_only": true}.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Licenses to return, 1-50. Default 50. | |
| entity_id | Yes | entity_id from resolve_business (11-digit Texas taxpayer number), or a 10-digit SOS file number. | |
| active_only | No | Only licenses whose primary status is Active. Default false. | |
| include_affiliates | No | Also include affiliated entities (likely common control, confidence >= 0.5). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and closed-world behavior, and the description adds real context beyond them: nightly refresh from Texas state datasets (staleness expectations), link method plus confidence per license, and inclusion of Credit Law Delinquent List appearances. It does not cover pagination or ordering, but for a read tool this is solid added value.
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?
Front-loads the purpose question, then the returned fields, then scope and freshness, ending with a concrete call example. Slightly dense and the example partly duplicates schema knowledge, but there is no wasted preamble.
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?
With no output schema, the description compensates by enumerating the returned fields (type, trade name, status, dates, link method/confidence, delinquent-list appearances) and states scope and data freshness. An agent has enough to call and interpret results 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 description coverage is 100%, so all four parameters are already documented in the schema; the description only restates active_only through its example call. No syntax or edge-case detail (e.g., how include_affiliates interacts with the confidence threshold) is added beyond the schema.
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?
States a specific verb and resource ('What alcohol licenses does this business hold or has it held?') and enumerates the returned record content, so an agent distinguishes it from get_locations or find_affiliates immediately. The Texas-only scope is stated up front.
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?
It establishes the applicable domain (Texas entities registered with Comptroller or TABC) and ties entity_id to resolve_business, which implies the calling sequence. However, it never says when to prefer this over siblings like get_entity or find_affiliates, nor any exclusion conditions, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where does this business operate? Returns its locations (sales-tax outlets, plus closed ones known from mixed-beverage receipts) with trade name, address, NAICS code, permit and first-sale dates, and whether each is current or ended. Texas only; businesses registered with the Texas Comptroller or TABC, refreshed nightly from Texas state datasets. Example: {"entity_id": "32057926266", "include_affiliates": true}.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Locations to return, 1-50. Default 50. | |
| status | No | Only current or only ended locations. Default both. | |
| entity_id | Yes | entity_id from resolve_business (11-digit Texas taxpayer number), or a 10-digit SOS file number. | |
| include_affiliates | No | Also include affiliated entities (likely common control, confidence >= 0.5). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the data is refreshed nightly, comes from Texas state datasets, and includes ended locations discovered via mixed-beverage receipts — provenance and staleness an agent cannot get from the schema.
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?
Front-loads the core question and answer, then layers scope, provenance and return fields. The rhetorical 'Where does this business operate?' opener earns its place as a framing device, and the example is compact, though the sentence enumerating returned fields is dense.
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?
With no output schema, the description carries the return-value burden and does so by listing trade name, address, NAICS code, permit and first-sale dates, and current/ended status. Geographic scope, sources and freshness are covered; pagination/limit behavior is left entirely to the schema, which is acceptable.
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 100%, so all four parameters (limit, status, entity_id, include_affiliates) are already documented in the schema, including the 1-50 range, the status enum and the affiliate confidence threshold. The description's example call adds only marginal value, so the baseline 3 is appropriate.
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?
States a specific verb and resource ('Returns its locations') plus the exact composition of those locations (sales-tax outlets plus closed mixed-beverage-receipt locations) and the fields returned. It also fixes the domain ('Texas only') and the sourcing, which separates it cleanly from siblings like get_licenses and find_affiliates.
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?
Gives clear qualifying context (Texas-only; businesses registered with the Texas Comptroller or TABC) and implies the prerequisite by noting entity_id comes from resolve_business. It does not, however, explicitly say when to prefer this over get_licenses or find_affiliates, so the routing is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What has happened to this business, and when? Returns dated events, newest first: formed, location opened or closed, licensed, license surrendered or expired, location transferred between entities, license applied for. Texas only; businesses registered with the Texas Comptroller or TABC, refreshed nightly from Texas state datasets. Each event names its source record. Example: {"entity_id": "32057926266", "include_affiliates": true}.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Events to return, 1-50. Default 50. | |
| since | No | Only events on or after this date, YYYY-MM-DD. | |
| entity_id | Yes | entity_id from resolve_business (11-digit Texas taxpayer number), or a 10-digit SOS file number. | |
| include_affiliates | No | Also include affiliated entities (likely common control, confidence >= 0.5). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses ordering (newest first), data freshness (refreshed nightly from Texas state datasets), and provenance (each event names its source record). That is meaningful context the annotations do not carry, though it omits anything about empty results or truncation behavior.
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?
It is front-loaded with the guiding question and the event list, then adds scope and freshness in tight sentences. The enumerated event types and the example make it slightly long, but each clause carries information an agent needs.
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?
With no output schema, the description correctly describes the return shape (dated events, newest first, source-record attribution) and notes the Texas-only, nightly-refreshed dataset. It is nearly complete, missing only notes on empty results or how limit/since interact with the return.
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 100%, so all four parameters are already documented in the schema; the baseline is 3. The example invocation shows a realistic entity_id plus include_affiliates, but adds no format or edge-case meaning beyond what the schema already states.
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 opening line states the exact verb and resource (dated events about a business) and enumerates the event kinds returned (formed, opened/closed, licensed, surrendered, transferred, applied). This clearly separates it from siblings like get_entity, get_licenses, and get_locations, which cover current state rather than history.
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?
It gives clear context for use (asking what happened to a business and when), states the scope constraint (Texas only, Comptroller/TABC-registered businesses), and implies the prerequisite by noting entity_id comes from resolve_business. It stops short of naming an explicit alternative or a when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which Texas business is this? Turns a brand, trade name or legal name into ranked candidates with entity_id, legal name, trade names, an address, confidence (0-1) and match_reasons. Texas only; businesses registered with the Texas Comptroller or TABC, refreshed nightly from Texas state datasets. status is match, possible, ambiguous (add a city or address) or not_found; weak guesses are never returned. Example: {"name": "Heim Barbecue", "city": "Fort Worth"}. Pass the entity_id to the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ZIP code, e.g. "76104". | |
| city | No | Texas city, e.g. "Fort Worth". Strongly improves ranking. | |
| name | Yes | Business, brand or legal name, e.g. "Heim Barbecue". | |
| limit | No | Candidates to return, 1-25. Default 10. | |
| address | No | Street address, e.g. "1109 W Magnolia Ave". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only readOnly/openWorld, so the description carries real weight and delivers: nightly refresh cadence, data-source scope, an explicit negative guarantee ('weak guesses are never returned'), and the full status vocabulary including the remediation hint for 'ambiguous'. This is behavior an agent could not infer from the schema or annotations.
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?
Front-loaded with the core question, then scope, provenance, return fields, statuses, and an example — every sentence does work. It is dense and slightly list-like in the return-field enumeration, but nothing is padded.
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?
With no output schema, the description compensates by enumerating the returned fields (entity_id, legal name, trade names, address, confidence, match_reasons) and the status enum. For a 5-param resolution tool this is complete enough to call blind.
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 100% so the baseline is 3, but the description adds meaning the schema does not: that city/address are disambiguation levers tied to the 'ambiguous' status, plus a concrete example invocation. It stops short of explaining limit/zip interplay, so not a full 5.
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?
Opens with a specific question ('Which Texas business is this?') and precisely states the transformation: brand/trade/legal name → ranked candidates with named output fields. The Texas-only scope and the data provenance (Comptroller/TABC) distinguish it clearly from siblings like get_entity or find_affiliates.
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?
Gives actionable routing context: 'add a city or address' when status is ambiguous, and 'Pass the entity_id to the other tools' to chain into the rest of the toolset. It stops short of naming a specific alternative tool (e.g. use get_entity when you already have an ID), so it is clear context rather than explicit when/when-not.
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.
find_new_activity2 fields changedInput schema / properties / min_confidenceAdded value: +{
+ "description": "Keep only rows whose opening_context confidence is at least this.",
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+}Input schema / properties / opening_typesAdded 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"
+}find_new_activity2 fields changedInput schema / properties / city / descriptionPrevious 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."Input schema / properties / since / descriptionPrevious 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)."get_environmental_recordget_labor_recordget_motor_carrierssearch_federal_exclusionsget_labor_recordget_motor_carrierssearch_federal_exclusionsget_environmental_recordfind_affiliatesfind_new_activityget_entityget_licensesget_locationsget_timelineresolve_businessSearch source-linked Dallas-Fort Worth local-government records for AI agents.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
Registry of companies selling AI agents identity, phone, email, addresses, money, legal, insurance
Verified DFW home-services directory. AI agents submit listings and find bookable pros.
Add one secure layer between your agents and this server.
