Skip to main content
Glama

Probative legal-marketing data

Law-firm marketing benchmarks

get_benchmark
Read-onlyIdempotent

Published benchmark tables on law-firm intake and marketing, as bands, tiers and rounded values with the methods page to cite.

Input Schema

NameRequiredDescriptionDefault
queryNoOptional words to keep only matching rows, e.g. "hour" or…
tableNo
response_formatNoconcise

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / detail
      Removed value: -{
      -  "default": "summary",
      -  "enum": [
      -    "summary",
      -    "full"
      -  ],
      -  "type": "string"
      -}
    • addedInput schema / properties / response_format
      Added value: +{
      +  "default": "concise",
      +  "enum": [
      +    "concise",
      +    "detailed"
      +  ],
      +  "type": "string"
      +}
  2. Changed4 schema fields changed
    • removedInput schema / properties / detail / description
      Removed value: -"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."
    • changedInput schema / properties / query / description
      Previous value: -"Optional words to keep only matching rows, e.g. \"hour\" or \"Local Services\""New value: +"Optional words to keep only matching rows, e.g. \"hour\" or…"
    • removedInput schema / properties / table / description
      Removed value: -"The table id (the benchmarks dataset key). Leave out to list the tables."
    • removedOutput schema / properties
      Removed 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"
      -  }
      -}
  3. Added

TDQS

B3.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description still adds real value by disclosing that results are bands, tiers and rounded values rather than raw figures, and that a methods page exists to cite — context that affects how an agent should present and attribute the data.

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?

A single dense sentence with no filler, front-loading the content domain before the output-shape caveat. The phrasing 'with the methods page to cite' is slightly compressed but still earns its place as attribution guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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. But a tool whose primary selector is a nine-value table enum with zero descriptions in either schema or prose is under-specified: the agent cannot reliably choose a table, and nothing indicates whether table is optional or what happens when it is omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%: the query parameter is documented, but the nine-value table enum has no per-value descriptions anywhere, and the description does not mention any parameter. An agent must guess which table corresponds to 'speed-to-sign' versus 'lsa-lead-mix' or 'cost-per-signed-client' with no help from the prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource: published benchmark tables on law-firm intake and marketing, which distinguishes it from generic siblings like data_lookup or data_search. However, it is a noun phrase with no verb, so the retrieval action is only implied by the tool name 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as data_lookup, data_search, or list_datasets, all of which could plausibly surface benchmark-style data. The description gives content, not routing logic.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources