Verified lawyer and attorney search, discovery, and matching for AI — 991K+ US profiles.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.8/5 across 5 of 5 tools scored.
Each tool has a clear, distinct purpose: finding by name, fetching profile by ID, searching by criteria, and listing jurisdictions/practice areas. There is no overlap that would cause confusion.
All tool names follow a verb_noun pattern, but there is slight inconsistency: 'find_lawyer_by_name' uses singular and 'search_lawyers' uses plural, and 'get' vs 'find' are used for similar lookup actions. Still, the pattern is largely predictable.
Five tools is well-scoped for a lawyer search server, covering discovery, lookup, and reference data without bloat or thinness.
The domain is read-only lawyer search, and the tool set covers searching, name verification, full profile retrieval, and reference lists for jurisdictions and practice areas. No obvious gaps exist.
find_lawyer_by_nameAInspectLook up a lawyer by name to verify they exist and are licensed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Lawyer name to search | |
| state | No | US state to narrow results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only lookup ('look up') and adds the purpose of licensing verification, but it does not disclose return format, behavior when no match is found, or any permissions needed. It is minimally transparent for a simple read operation.
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, front-loaded sentence that clearly states the action and purpose. There is no wasted wording, making it highly concise and scannable.
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?
Given the lack of an output schema and annotations, the description leaves gaps: it does not explain what the tool returns (e.g., a profile, a boolean, or a list) or how it handles ambiguous names. For a simple tool it is adequate but not fully complete.
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 schema already provides comprehensive descriptions for both parameters ('Lawyer name to search' and 'US state to narrow results'), covering 100% of them. The description adds no additional semantics beyond aligning with the name parameter, so it does not need to compensate.
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 clearly states the action ('look up'), the resource ('a lawyer by name'), and the purpose ('verify they exist and are licensed'). This distinguishes it from sibling tools like search_lawyers, which likely handle broader search criteria, and get_lawyer_profile, which provides detailed profiles.
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 the tool is used when verifying a lawyer's existence and license via name lookup, but it does not explicitly list exclusions or reference alternative tools (e.g., 'for broader searches, use search_lawyers'). Guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jurisdictionsAInspectList US states with lawyer counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description clearly states the output type (a list of US states with lawyer counts) and implies a read-only operation. For a simple list tool, this provides adequate transparency without needing to mention ordering or data source.
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 concise sentence with no redundancy, directly conveying the tool's function.
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 parameterless tool with no output schema, the description fully specifies the output: a list of US states with lawyer counts. There is no additional complexity that requires further explanation.
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 tool has zero parameters, so there is nothing to describe beyond the fixed behavior. The description sufficiently characterizes the output without requiring parameter explanations, aligning with the baseline for parameterless tools.
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 uses a specific verb ('List') and resource ('US states') and adds the qualifier 'with lawyer counts,' clearly distinguishing it from sibling tools that handle individual lawyers, profiles, practice areas, or searches.
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 does not explicitly state when to use this tool versus the sibling tools, but its purpose implies that it is for obtaining jurisdiction-level aggregated counts rather than individual lawyer lookups. There is no explicit alternative guidance or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lawyer_profileAInspectGet full profile for a specific lawyer by their Law.AI ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Lawyer ID from Law.AI |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states 'get full profile' with no mention of return format, error handling, side effects, or any other behavioral traits. This is insufficient for a tool with zero annotation support.
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 sentence that is front-loaded with the action and key resource. It contains no unnecessary words or repetition, earning the highest score for conciseness.
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?
The tool is simple with one parameter and no additional schema richness, but the description lacks an output schema and does not elaborate on the structure of the 'full profile' or error conditions. As a minimal viable description it works, but it could be more complete given the absence of annotations and output schema.
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 input schema already describes the parameter id as 'Lawyer ID from Law.AI', achieving 100% schema description coverage. The description merely restates 'Law.AI ID' without adding extra semantic detail such as format expectations or how to obtain the ID, 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?
The description begins with a clear verb 'Get', specifies the resource 'full profile' for a lawyer, and uniquely identifies by Law.AI ID. This distinguishes it from sibling tools like search_lawyers or find_lawyer_by_name, which are for lookup without a known ID.
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 phrase 'by their Law.AI ID' clearly implies the tool is used when the ID is already known, providing a clear context. However, it does not explicitly state when not to use it or suggest alternatives like find_lawyer_by_name when only a name is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_practice_areasAInspectList all practice areas with lawyer counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states a list operation, which implies read-only, but does not disclose potential limitations (e.g., pagination, scope of 'all', data freshness). Still, for a simple list, the transparency is acceptable.
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, clear sentence with no filler. Front-loaded with the action and resource.
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?
Given the simplicity of the tool and the lack of input/output schemas, the description adequately covers the behavior. It states what is returned (practice areas with counts), which is sufficient for an agent to invoke it.
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 tool takes zero parameters, so parameter-specific semantics are unnecessary. The description adds value by clarifying the output includes lawyer counts.
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 uses a specific verb ('List') and resource ('practice areas'), includes the output detail (lawyer counts), and clearly distinguishes from sibling tools focused on lawyers and jurisdictions.
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?
No guidance is provided on when to use this tool versus alternatives like search_lawyers or get_jurisdictions. There is no mention of use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_lawyersAInspectSearch verified lawyer profiles by practice area, state, city, and bar status.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name | |
| limit | No | Results (default 10, max 50) | |
| state | No | US state (name or abbreviation) | |
| offset | No | Pagination offset | |
| bar_status | No | "Active" (default), "Inactive", or "Any" | |
| practice_area | No | Practice area, e.g. "Criminal Defense" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only mentions 'verified' profiles and the filter categories. It does not explain how multiple filters are combined (AND/OR), what happens when no filters are provided, pagination behavior, or the shape of the returned results. The schema provides some defaults (limit, bar_status), but the description itself offers minimal behavioral context.
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, front-loaded sentence with no filler. Every phrase earns its place: 'Search', 'verified lawyer profiles', and the filter list. It is concise and immediately scannable.
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 and no annotations, the description should compensate by explaining return values, defaults, and edge cases (e.g., no filters). It does none of these. The presence of sibling tools also makes it important to mention when to use this tool versus find_lawyer_by_name, which is absent. The description is functionally a purpose statement, not a complete tool guide.
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 input schema describes every parameter (100% coverage), so the description does not need to repeat them. The description restates the filter dimensions (practice area, state, city, bar status) but adds no new meaning beyond what the schema already provides. It is adequate but not additive.
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 uses a specific verb ('Search') and specifies the resource ('verified lawyer profiles') along with the key filter dimensions (practice area, state, city, bar status). This clearly distinguishes it from siblings like find_lawyer_by_name, which targets name-based lookup, and get_lawyer_profile, which retrieves a specific profile.
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 explicitly states the searchable criteria, giving clear context for when this tool is appropriate: when you need to find lawyers by practice area, state, city, or bar status. However, it does not mention an alternative like find_lawyer_by_name for name-based searches or any explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.