Duplicate listing. The maintained listing for this server is Probative legal-marketing data, synced with the official MCP Registry entry com.probativegrowth/legal-marketing-data. Same endpoint: https://probativegrowth.com/mcp
get_spanish_demand_supplySpanish speakers with limited English per Spanish-speaking lawyer in one US state, DC, the US or a metro area (Census ACS). Results are not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | A state code (TX), DC, US, a metro code (26420), or a metro… | |
| response_format | No | concise |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / area / descriptionPrevious value: -"A state code (TX), DC, US, a metro code (26420), or a metro name (\"Houston\")"New value: +"A state code (TX), DC, US, a metro code (26420), or a metro…"Input schema / properties / detailRemoved value: -{
- "default": "summary",
- "description": "summary (default): each record as its id, a 1-2 sentence text, status, date checked, one source URL and the page to cite. full: every field, every source and the per-record provenance.",
- "enum": [
- "summary",
- "full"
- ],
- "type": "string"
-}Input schema / properties / response_formatAdded value: +{
+ "default": "concise",
+ "enum": [
+ "concise",
+ "detailed"
+ ],
+ "type": "string"
+}Output schema / propertiesRemoved value: -{
- "meta": {
- "description": "Credit line (attribution), citation, DOI, version, license (CC BY 4.0), disclaimer, notice and the page to cite",
- "required": [
- "attribution",
- "license",
- "disclaimer",
- "notice"
- ],
- "type": "object"
- },
- "nextCursor": {
- "description": "Pass as `cursor` to get the next page; null on the last page",
- "type": [
- "string",
- "null"
- ]
- },
- "provenance": {
- "description": "Where this came from: the publisher of the dataset, the dataset and its version DOI, the record id, the original source (who published it and its URL), the day that source was last checked, and when this answer was retrieved",
- "properties": {
- "citeUrl": {
- "description": "The page to cite",
- "type": [
- "string",
- "null"
- ]
- },
- "dataset": {
- "description": "Dataset id",
- "type": "string"
- },
- "datasetTitle": {
- "type": "string"
- },
- "dateChecked": {
- "description": "YYYY-MM-DD the record was last checked against its source",
- "type": [
- "string",
- "null"
- ]
- },
- "doi": {
- "description": "Version DOI",
- "type": [
- "string",
- "null"
- ]
- },
- "doiUrl": {
- "type": [
- "string",
- "null"
- ]
- },
- "line": {
- "description": "The same facts as one sentence, to quote under an answer",
- "type": "string"
- },
- "publisher": {
- "description": "Publisher of the dataset",
- "type": "string"
- },
- "recordId": {
- "description": "Stable id of the record",
- "type": [
- "string",
- "null"
- ]
- },
- "retrievedAt": {
- "description": "ISO 8601 time this answer was served",
- "type": "string"
- },
- "source": {
- "description": "The original source: statute, rule, bar opinion, court report, agency table or platform policy",
- "type": [
- "string",
- "null"
- ]
- },
- "sourceKind": {
- "description": "primary or secondary",
- "type": [
- "string",
- "null"
- ]
- },
- "sourceUrl": {
- "type": [
- "string",
- "null"
- ]
- },
- "status": {
- "description": "P primary source, S secondary, D default (no specific rule found), U open question",
- "type": [
- "string",
- "null"
- ]
- },
- "version": {
- "description": "Dataset version",
- "type": "string"
- }
- },
- "required": [
- "publisher",
- "dataset",
- "version",
- "retrievedAt"
- ],
- "type": "object"
- }
-}Input schema / properties / detailAdded value: +{
+ "default": "summary",
+ "description": "summary (default): each record as its id, a 1-2 sentence text, status, date checked, one source URL and the page to cite. full: every field, every source and the per-record provenance.",
+ "enum": [
+ "summary",
+ "full"
+ ],
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuine context beyond that: the upstream source (Census ACS) and a framing constraint ('Results are not legal advice') that tells the agent how to present the number. It does not discuss rounding, staleness, or rate limits, which keeps it out of the top tier.
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 front-loaded sentence defines the metric and scope, followed by a short source note and a one-clause disclaimer. No padding; the only slack is that the geography list could be compressed since the schema repeats it.
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 two-parameter read whose output schema already defines return values, the description supplies metric definition, data source, geographic scope, and an output caveat — enough to call it correctly. The remaining hole is the unmentioned response_format, which is a parameter-level rather than description-level omission.
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 only 50% schema coverage, the description needs to compensate and does not. It restates the accepted geography forms (partially duplicating the truncated 'area' description) but never mentions the 'response_format' parameter at all — the enum, its default, and what changes between concise and detailed are left entirely undocumented.
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?
Names a precise, unusual metric (Spanish speakers with limited English per Spanish-speaking lawyer) and enumerates every supported geography type (state code, DC, US, metro), plus the data source (Census ACS). An agent can tell exactly what this returns; it simply does not explicitly contrast itself with siblings like data_lookup or compare_states, though the metric is distinctive enough among them.
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?
Usage is only implied: the geography enumeration hints that this is the single-area lookup for this metric, but there is no when-to-use statement, no guidance on picking this over compare_states/data_lookup, and no prerequisite or exclusion notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.