US legal-market research by county and practice: demand, lawyer supply, ad rules. Sources, DOIs.
Scored across 8 tools
Most tools are clearly distinct: compare_markets, demand_trend, market_profile, rank_markets, supply_gap, and supply_trend each serve a different research operation. There is some potential overlap among compare_markets, rank_markets, and supply_gap because all involve cross-market analysis, but the descriptions make their boundaries reasonably clear.
The names are readable but mix conventions: compare_markets and rank_markets are verb-first, while demand_trend, market_profile, supply_gap, and supply_trend are noun-first, plus the standalone resolve. This is not chaotic, but it is not a single predictable pattern either.
Eight tools is well-scoped for a legal-market research server. Each tool covers a distinct research need, and none appears redundant or purely filler.
The surface covers key workflows: key resolution, market profiles, comparisons, rankings, demand trends, supply trends, supply gaps, and advertising-rule checks. Minor gaps may exist around explicitly listing all supported practices or datasets, but resolve likely handles lookup needs.
The same practice-area figures for up to 10 states or counties side by side to compare, plus per-100. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| detail | No | summary | |
| places | Yes | States (TX, Florida) or counties (48201, "Cook County, IL") | |
| practice | Yes | Practice id (personal-injury, truck-accidents, employment-law… |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds a normalization detail ('plus per-100') and a legal disclaimer, which are genuinely beyond the structured fields, but says nothing about how the comparison is computed or ordered.
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?
A single compact sentence with the key constraint (up to 10) front-loaded and no padding. It is grammatically fragmentary, which slightly hurts readability, but nothing is wasted.
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?
An output schema exists, so return values need not be explained, and annotations cover safety. However, with four parameters and two of them (lang, detail) undocumented in both schema and description, an agent cannot fully understand the tool's call surface.
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 only 50%: places and practice are documented in the schema, while lang and detail are documented nowhere. The description restates the 'up to 10' cap and 'states or counties' examples that the schema already provides, so it does not compensate for the undocumented language and detail parameters.
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 states a specific operation — putting the same practice-area figures for up to 10 states/counties side by side — which distinguishes it from single-market tools like market_profile. It does not name any sibling explicitly, so a reader has to infer that rank_markets orders rather than juxtaposes.
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 only hint of usage is the phrase 'side by side to compare' embedded in the purpose statement. There is no statement of when to prefer this over market_profile, rank_markets, or demand_trend, nor any exclusion or prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The time series each linked demand dataset holds for a state or county. Answers "are filings going up or down". Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | any | |
| lang | No | en | |
| sort | No | change | |
| limit | No | ||
| place | Yes | A state (CA), a county FIPS (06037) or "County, ST" | |
| dataset | No | Only this dataset id or measure key (optional) | |
| minValue | No | Leave out changes whose larger value is below this | |
| practice | Yes | Practice id (personal-injury, truck-accidents, employment-law… | |
| direction | No | any |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the description carries a lighter burden. It adds the demand-dataset scope and a legal-advice disclaimer, but says nothing about pagination, ordering, or caveats around the trend data.
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?
Two sentences, front-loaded with the core resource and no obvious padding. The first sentence is slightly awkward but still efficient.
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 nine-parameter tool with under-half schema description coverage, this description is too thin. The output schema exists, but key parameter semantics and selection guidance are missing.
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 44% across nine parameters, so the description should compensate but does not. It only loosely gestures at place ("state or county") and dataset; required practice, direction, kind, sort, limit, minValue, and lang get no added meaning.
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 names a specific resource, the time series in linked demand datasets, and frames the question it answers ("are filings going up or down"). It implicitly contrasts with supply-oriented siblings but does not explicitly name an alternative.
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 the question the tool answers but no explicit when-to-use, when-not-to-use, or alternative such as supply_trend or compare_markets. An agent must infer selection from the question phrase alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All the figures, the whole picture, of one state or county and one practice area from the linked open datasets. Results are not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| state | Yes | Two-letter state code (TX), a state name, or DC | |
| county | No | Optional county: five-digit FIPS (48201) or name ("Harris") | |
| detail | No | summary | |
| practice | Yes | Practice id (personal-injury, truck-accidents, employment-law… | |
| dimensions | No | Only these dimensions (default all) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive, and non-open-world behavior, so the safety profile is clear. The description adds only provenance ("linked open datasets") and a legal disclaimer, without explaining limitations, coverage, or output detail levels such as summary versus full.
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 two short sentences with the scope placed first and no unnecessary exposition. "All the figures, the whole picture" is slightly redundant, but overall it is efficient.
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?
An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. Still, for a six-parameter tool with multiple siblings, the description leaves gaps around when to use this versus compare/rank/trend tools and how detail/lang affect results.
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 67%, with state, county, practice, and dimensions described in the schema, but lang and detail are undocumented beyond enums and defaults. The description reinforces state/county/practice scope and "all the figures" loosely maps to dimensions, but it does not clarify lang or detail 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 identifies the resource as a market profile covering all figures for one state or county plus one practice area, and the scope distinguishes it from broader comparison or trend siblings. It does not explicitly name or differentiate against compare_markets, rank_markets, demand_trend, or supply_trend, so it stops short of a 5.
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 scope implies this is the tool for a single-place, single-practice profile rather than for comparing, ranking, or trending markets. However, it gives no explicit when-to-use guidance, no exclusions, and no named alternatives despite seven sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks the states (state "US") or one state's counties by one demand count for the practice. A count, not a score. Results are not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| limit | No | ||
| state | Yes | Two-letter state code to rank its counties, or US to rank the… | |
| metric | No | Optional demand measure key (e.g.… | |
| per100k | No | Rank by the count per 100,000 residents instead of the count | |
| minValue | No | Leave out units whose count is below this (small counts make… | |
| practice | Yes | Practice id (personal-injury, truck-accidents, employment-law… |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-obvious semantics beyond them: results are raw counts rather than scores, and the output carries a legal-advice disclaimer.
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?
Three short sentences with the core action front-loaded and no redundant restatement of the name. The trailing 'Results are not legal advice' is boilerplate, but it is brief and plausibly load-bearing for a demand-estimate tool.
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?
An output schema exists and the annotations are rich, so the description needn't explain return values, and it adequately covers the state-scope decision. It is still missing explanations of sort order, what happens when `metric` is omitted, and the effect of `per100k`/`minValue`, which matter for correct invocation of a 7-parameter 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?
With 71% schema description coverage the schema does most of the work. The description adds meaning for the `state` parameter's special 'US' sentinel (rank states vs that state's counties) but says nothing about `per100k`, `minValue`, `metric`, or `limit`, leaving the normalization and filtering behavior undocumented in prose.
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 concrete verb+resource ('Ranks the states ... or one state's counties by one demand count') and clarifies the output kind is a count rather than a score. It does not explicitly name the sibling compare_markets or market_profile as the alternative, so the differentiation is inferential rather than stated.
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 implies usage through the 'state "US" vs a two-letter code' branching, which tells the agent how to pick state-level versus county-level ranking. It gives no explicit when-to-use/when-not guidance and never names compare_markets or supply_gap as alternatives for related questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turns a place and/or practice phrase into the keys every other tool takes. Only for turning words into keys; the other tools answer the questions.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | A place and/or practice phrase, EN or ES ("Condado de Los… |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world and non-destructive behavior, so the safety profile is covered. The description usefully frames the tool as a key-producing precursor rather than an answer tool, but says nothing about ambiguity handling, no-match behavior, or normalization across EN/ES.
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?
Two short sentences, front-loaded with the core transformation and followed by the scoping contrast. Every sentence earns its place with no filler.
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 an output schema present and one fully documented parameter, the description needn't explain return values, and it correctly positions the tool in the workflow. Only the failure/ambiguity path is unaddressed, which is a minor gap for a resolver.
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?
Single parameter with 100% schema description coverage, so the schema already explains the accepted phrase (including the EN/ES note and length bounds). The description restates the same idea ('place and/or practice phrase') without adding format or matching semantics, so the baseline 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?
States a specific verb and resource ('turns a place and/or practice phrase into the keys') and explicitly contrasts itself with the siblings ('the other tools answer the questions'). An agent can tell this is a lookup/resolution step, not an analysis tool.
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?
'Only for turning words into keys; the other tools answer the questions' clearly scopes when to use it versus the seven analytical siblings, and 'keys every other tool takes' implies it is a precursor step. It stops short of stating an explicit sequencing rule or what to do when resolution fails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The lawyer advertising rules (filing, required content, waiting periods, claims, referral, language, recording, texting, privacy). Results are not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| state | Yes | Two-letter state code (TX), a state name, or DC | |
| practice | Yes | Practice id (personal-injury, truck-accidents, employment-law… |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive, closed-world lookup, so the safety profile is covered. The description adds useful context by listing the covered rule topics and stating that results are not legal advice, but it does not disclose other behavioral traits such as rate limits, freshness, or citation 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?
The description is a single compact sentence followed by a short disclaimer, with the rule categories front-loaded. Every phrase contributes to scope or caveat, and there is no wasted text.
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 simple read-only lookup with an output schema and annotations covering safety, the description is largely complete: it states the domain, enumerates covered topics, and includes the legal disclaimer. It is only missing explicit parameter usage guidance and any note on result interpretation, which are minor here.
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?
The description does not mention the state, practice, or lang parameters at all. Schema coverage is only 67%, and while the two required parameters have schema descriptions, the description itself adds no meaning beyond what the schema already provides.
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 title and description together make clear that this tool returns lawyer advertising rules for a given state and practice, and the parenthetical enumerates the rule categories covered. It is not a generic verb-first statement, but the resource and scope are specific enough to distinguish it from the market-analysis siblings.
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 offers no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The only usage-related note is the disclaimer that results are not legal advice, which is a caveat rather than selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks the states (state "US") or one state's counties by demand for each law office. No composite score. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Rank only the N units with the most demand (e.g. 25) | |
| lang | No | en | |
| limit | No | ||
| state | Yes | Two-letter state code to rank its counties, or US to rank the… | |
| metric | No | Optional demand measure key from options (e.g.… | |
| practice | Yes | Practice id (personal-injury, truck-accidents, employment-law… | |
| minDemand | No | Leave out units whose demand count is below this (small counts… |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description contributes two real behavioral facts: results are not a blended/composite score, and the output is not legal advice. It says nothing further about ordering, tie-breaking, or the fact that 'demand per law office' is a normalized ratio, which is the tool's core behavioral trait.
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?
Three terse sentences with the verb and scope front-loaded and no filler or repetition. The final disclaimer is short but borders on boilerplate; one more sentence about the practice/metric parameters would have been a better use of the space.
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?
An output schema exists and annotations are rich, so return values and safety need no prose. But for a 7-parameter tool with only 2 required, the description leaves the agent without guidance on how to choose a `metric` (it references 'options' that are never identified) or how `top` and `limit` interact. Adequate to call the tool, not adequate to call it well.
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 71% and the schema text for `state` is truncated ('or US to rank the…'), so the description usefully completes that dual-mode semantics — a big win for the most confusing required parameter. However, `practice`, `metric`, `top`, `minDemand`, `limit`, and `lang` get no mention, and 'metric ... from options' implies a discovery step (likely the resolve sibling) that is never explained.
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 scope: it ranks states (when state="US") or one state's counties by demand per law office. That is concrete enough to distinguish it from a generic listing tool, and the title reinforces the per-lawyer normalization. It stops short of naming how it differs from siblings like rank_markets or supply_trend, so an agent must infer the boundary.
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?
There is no statement of when to use this tool versus compare_markets, rank_markets, demand_trend, or supply_trend, all of which plausibly overlap. The clarifications given ('No composite score', 'Not legal advice') are disclaimers about output, not selection guidance. The agent is left to guess from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The time series of lawyer supply (private law offices, and any other supply count with two periods) for a state or county. Results are not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| sort | No | change | |
| limit | No | ||
| place | Yes | A state (CA), a county FIPS (06037) or "County, ST" | |
| dataset | No | Only this dataset id or measure key (optional) | |
| minValue | No | Leave out changes whose larger value is below this | |
| practice | Yes | Practice id (personal-injury, truck-accidents, employment-law… | |
| direction | No | any |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds domain context that it covers private law offices and other supply counts with two periods, plus a legal disclaimer, but it does not discuss ordering, pagination, or result handling.
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 two tightly written sentences with the core data scope front-loaded. The legal disclaimer is brief and does not obscure the primary purpose.
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?
Although an output schema and rich annotations reduce the burden on the description, this is an 8-parameter analytical tool surrounded by related siblings. The description does not explain when to choose it over supply_gap or demand_trend and leaves several parameters undocumented, so an agent is not fully equipped to select and invoke it 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?
The description adds no parameter-level meaning despite 8 parameters and only 50% schema description coverage. Required place and practice are described in the schema, but sort values such as change versus pct, direction, limit, lang, and minValue behavior are not explained in either place.
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 states a specific resource and operation: a time series of lawyer supply for a state or county. It is clear enough to distinguish a supply-trend query from demand-oriented or market-profile tools, but it does not explicitly differentiate itself from siblings such as supply_gap or demand_trend.
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 gives no explicit when-to-use guidance, no exclusions, and no alternatives among the sibling tools. The geographic scope is mentioned, but eligibility is not the same as guidance on selecting this tool versus compare_markets, demand_trend, rank_markets, or supply_gap.
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.
rank_marketsresolve1 field changedInput schema / properties / text / descriptionPrevious value: -"A place and/or practice phrase, EN or ES (\"drug injury Texas\"…"New value: +"A place and/or practice phrase, EN or ES (\"Condado de Los…"supply_trendmarket_profile1 field changedOutput schema / requiredPrevious value: -[
- "meta",
- "provenance",
- "place",
- "practice",
- "figures",
- "gaps"
-]New value: +[
+ "meta",
+ "provenance",
+ "place",
+ "practice",
+ "figures"
+]compare_marketsdemand_trendmarket_profileresolverules_checksupply_gapFree, cited reference data for US law-firm marketing: lawyer advertising rules for all 50 states and DC, bar ad-filing fees, contingency fee caps, ethics opinions (incl. AI), ad-platform policies, federal MDL dockets, federal civil filings, statutes of limitations, law-office competition and legal deserts by county, lawyer wages, fatal crashes, CFPB, EEOC and FCC complaint data. Every answer carries its source, DOI and the date it was checked. Main server: 24 tools; one more server per dataset at /mcp/<dataset>. Read-only, no sign-in, CC BY 4.0. Published by Probative Growth, a marketing agency for law firms. Not legal advice.
Free, cited reference data for US law-firm marketing: lawyer advertising rules for all 50 states and DC, bar ad-filing fees, contingency fee caps, ethics opinions, ad-platform policies for legal services, federal MDL dockets and California courts. Every answer carries its source and the date it was checked. Read-only, no sign-in, CC BY 4.0. Published by Probative Growth, a marketing agency for law firms. Not legal advice.
Verified lawyer and attorney search, discovery, and matching for AI — 991K+ US profiles.
Verified lawyer and attorney search, discovery, and matching for AI — 991K+ US profiles.
Add one secure layer between your agents and this server.
