LegalAIMCP Directory
Server Details
Search a curated directory of AI tools and MCP servers for law firms. Read-only, free, no auth.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.3/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: searching tools, listing categories, and getting detailed info for a specific tool. No overlap or ambiguity.
All tool names follow a consistent verb_noun snake_case pattern: search_legal_ai_tools, list_legal_ai_categories, get_legal_ai_tool.
Three tools are appropriate for a directory server, covering search, category browsing, and detail retrieval without unnecessary bloat.
The server covers the main directory functions (search, list categories, get details). A minor gap is the lack of a 'list all tools' function, but search can approximate that.
Available Tools
3 toolsget_legal_ai_toolGet one legal AI toolARead-onlyIdempotentInspect
Get the full listing for one legal AI tool by its slug, including the complete description and MCP install command. Use after search_legal_ai_tools to go deeper on a specific result.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Listing slug, e.g. "harvey-ai" — taken from a search result |
Output Schema
| Name | Required | Description |
|---|---|---|
| tool | No | The listing, present when found is true |
| found | Yes | False when no published listing has this slug |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds that the tool returns 'complete description and MCP install command', giving concrete behavioral details beyond 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?
Two short, front-loaded sentences with zero waste. First sentence states purpose, second provides usage context.
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 tool with one parameter, high annotation coverage, and an existing output schema, the description provides all necessary context: what the tool does, when to use it, and what the response contains.
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% with a description for the slug parameter. The description mentions 'by its slug' but does not add significant meaning beyond the schema's explanation and example.
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 verb (Get), resource (legal AI tool), and distinguishing details (by slug, includes complete description and MCP install command). It also explicitly positions itself after search_legal_ai_tools, differentiating from 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 explicitly says 'Use after search_legal_ai_tools to go deeper on a specific result', providing clear when-to-use guidance and an exclusion for search functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_legal_ai_categoriesList practice-area categoriesARead-onlyIdempotentInspect
List the practice-area categories in the legalaimcp.com directory, with how many published tools each contains. Useful for orienting before a search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total published tools in the directory |
| categories | Yes | All practice-area categories |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety and idempotency are clear. The description adds that it lists categories with counts, consistent with annotations. No contradictions.
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 main action, no waste. Every word contributes to clarity.
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 zero parameters and an output schema, the description fully explains what the tool returns (categories with counts). No gaps for the intended use.
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?
No parameters exist, and schema coverage is 100%. Baseline of 4 applies; description adds no param info but none is needed.
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?
Clearly states the tool lists practice-area categories and their tool counts. Differentiates from sibling tools (get_legal_ai_tool and search_legal_ai_tools) by focusing on categories rather than specific tools.
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?
Explicitly states 'Useful for orienting before a search,' providing clear context for when to use. While it doesn't contrast with siblings, the usage scenario is clear and sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_legal_ai_toolsSearch legal AI toolsARead-onlyIdempotentInspect
Search the legalaimcp.com directory of AI tools and MCP servers built for law firms. Filter by free-text query, practice-area category, and pricing model. Use this when someone asks what AI tooling exists for legal work such as contract review, legal research, client intake, billing, or compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–25, default 10) | |
| query | No | Free-text search over tool names, taglines, and descriptions, e.g. "contract review" | |
| pricing | No | Pricing-model filter: free, freemium, paid, or contact | |
| category | No | Practice-area filter — get slugs from list_legal_ai_categories |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of tools returned |
| tools | Yes | Matching tools, link-verified listings first |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, idempotent read operation. The description adds that results can be filtered by query, category, and pricing, but does not disclose any additional behavioral traits beyond what the annotations and schema already convey.
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 sentences long, front-loaded with the core purpose, and uses specific examples. Every word adds value; there is no fluff or redundancy.
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 presence of an output schema and comprehensive annotations, the description covers the essential purpose and filtering capabilities. It could be slightly improved by hinting at pagination or response structure, but the output schema likely handles that. The description is complete enough for effective use.
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 the baseline is 3. The description lists the three filter types (free-text, category, pricing), which mirrors the schema's descriptions without adding new meaning or usage nuances. No extra value is provided beyond what the parameter descriptions already offer.
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 it searches the legalaimcp.com directory for AI tools and MCP servers, with specific filter dimensions (free-text, category, pricing). It includes concrete examples like 'contract review' and distinguishes from sibling tools by implying that get_legal_ai_tool retrieves a single tool and list_legal_ai_categories returns category slugs.
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 says 'Use this when someone asks what AI tooling exists for legal work...', providing clear context. However, it does not explicitly state when not to use it or contrast with siblings beyond the implicit differentiation, which would improve the score to 5.
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.
Discussions
No comments yet. Be the first to start the discussion!