California employee-side employment law firm: offices, page search, consultation requests.
Scored across 5 tools
request_consultation and request_service both ultimately file a consultation request with the firm, and the only distinguishing factor is that request_service targets a specific office via business_id — an agent could easily pick the wrong one. get_firm_info and list_offices also overlap since both describe offices, address, phone, and contact details.
All five tools follow a clean verb_noun snake_case pattern (get_firm_info, list_offices, request_consultation, request_service, search_pages). No mixed conventions or vague verbs.
Five tools is well-scoped for a single-firm server covering firm info, offices, consultation intake, and page search. Each tool maps to a plausible distinct capability without bloat.
The surface covers discovery (firm info, offices, page search) and intake (consultation), which is most of what a law-firm server needs. Minor gaps: no way to retrieve individual attorney profiles or practice-area details except through generic keyword search.
What the Employment Lawyers Group handles, who it represents, fees, and the address, phone and contact page for one office.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site/office host, e.g. sacramentolaborattorney.com. Omit for the Los Angeles office. |
| Name | Required | Description |
|---|---|---|
| fees | No | |
| firm | No | |
| phone | No | |
| office | No | |
| website | No | |
| disclaimer | No | |
| contact_page | No | |
| how_to_reach | No | |
| service_area | No | |
| practice_areas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully scopes the content returned (fees, contacts, one office) but adds nothing about auth, caching, or freshness, which is acceptable given the annotation coverage.
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 that front-loads the resource and then lists the covered content. No filler, though the enumerated list is slightly dense without stating the retrieval action.
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 the parameter fully documented, the description only needs to convey scope, which it does. It is complete for a simple read-only info lookup, with the only gap being the absent routing versus list_offices.
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% and the single `site` parameter is fully documented in the schema, including the 'omit for Los Angeles' default. The description's 'for one office' merely restates the schema's intent without adding format or example detail beyond it.
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 (firm information for the Employment Lawyers Group) and enumerates what it covers: practice areas, representation, fees, and office contact details. The retrieval verb is implicit rather than stated, and it doesn't explicitly distinguish itself from list_offices, though 'for one office' hints at the distinction.
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 explicit when-to-use or when-not-to-use guidance. The phrase 'for one office' and the sibling list_offices imply a contrast, but the agent must infer that list_offices is the multi-office alternative; nothing states it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every office of the firm with its city, county, address, phone and website. Use it to pick the office nearest the person.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| offices | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description reinforces 'every office' as a complete, unfiltered enumeration with no input. It adds little beyond that — no pagination, count, or ordering information — so it clears the lowered bar but does not enrich it much.
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, zero waste, with the returned scope front-loaded and the usage guidance second. Nothing could be removed without losing information.
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?
A parameterless read tool with an output schema needs only to state scope and purpose, both of which are present. The output schema carries return-value detail, so the description is essentially complete for the agent's decision, with only minor headroom for sizing or ordering hints.
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, which is the baseline-4 case: there is no parameter semantics left to explain, and the description correctly implies a no-argument, whole-collection call.
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 the resource precisely ('Every office of the firm') and enumerates the returned attributes (city, county, address, phone, website), so the agent knows exactly what this tool yields. The verb 'list' is only implied, and no sibling is named, but the siblings (get_firm_info, request_consultation, search_pages) are plainly distinct.
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 states a concrete use case: 'Use it to pick the office nearest the person,' which tells the agent when this tool is the right call. It does not name an alternative or an exclusion, but no competing office-listing tool exists among the siblings, so the routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File a confidential consultation request with the firm on behalf of a person who has agreed to it. Goes through the same intake as the website contact form; the firm calls or emails back. Not for marketing or solicitation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name of the person seeking help | |
| site | No | Which office/site to send it to, e.g. riversideemploymentlawyer.com. Use list_offices to choose the nearest. Defaults to the Los Angeles office. | |
| No | Email address | ||
| phone | No | Callback phone number with area code. A phone or an email is required. | |
| consent | Yes | Must be true: the person has agreed to send these details to the law firm. | |
| location | No | City and state where they work or worked | |
| situation | Yes | What happened at work, in the person's own words | |
| company_size | No | Approximate number of employees at the employer | |
| termination_date | No | Date of termination if any, YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose a non-read-only, open-world, non-idempotent write. The description adds real value beyond that: confidentiality, the intake path, the callback outcome, and the consent precondition. This is solid supplementary context, though it does not state rate limits or what happens to a duplicate submission (consistent with idempotentHint=false).
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 compact sentences with no filler. The core action and consent condition are front-loaded, followed by outcome and exclusion in descending order of importance.
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 9-parameter write with no output schema, the description covers purpose, side effects, the callback outcome, and the consent requirement that gates the call. An agent has enough to invoke correctly, though it does not clarify how this differs procedurally from request_service.
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%, with every parameter documented including requirements and formats, so the schema carries the full burden. The description adds no parameter-level meaning beyond it, making the baseline 3 correct.
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 verb and resource ('File a confidential consultation request with the firm') plus the scope constraint ('on behalf of a person who has agreed to it'). It distinguishes itself from the marketing/solicitation use case, but it does not explicitly contrast with the closest sibling, request_service, leaving the agent to 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?
It gives the operative context ('Goes through the same intake as the website contact form; the firm calls or emails back') and an explicit exclusion ('Not for marketing or solicitation'). However, it does not name the alternative tool to use for non-consultation requests, so the when-to-use routing vs siblings is only partially closed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens the firm's consultation request form for one office. Used by hosts that show a Get Quote button; pass the office business_id from the business feed (its site host). The form itself files the request with the person's consent.
| Name | Required | Description | Default |
|---|---|---|---|
| business_id | Yes | Office identifier from the business feed, e.g. riversideemploymentlawyer.com |
| Name | Required | Description |
|---|---|---|
| site | No | |
| office | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this readOnlyHint=true and openWorldHint=false, and the description usefully adds that the form itself files the request with the person's consent — clarifying that this tool opens a surface rather than submitting data. It stops short of stating what the tool actually returns (e.g. a URL) or any auth requirements, though an output schema exists.
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: what it opens, who calls it, and where the identifier comes from. The purpose is front-loaded and no sentence is 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?
Annotations cover the safety profile, the single parameter is fully documented, and an output schema exists, so return values need not be described. What is missing is an explicit contrast with the sibling request_consultation, leaving the agent to infer the boundary.
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 a single parameter at 100% schema description coverage, the schema already defines business_id including its source and example format. The description's 'pass the office business_id from the business feed' largely restates this, adding only the 'one office' scoping nuance, so 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?
The description gives a specific verb and resource: 'Opens the firm's consultation request form for one office,' and the clause 'The form itself files the request' implicitly separates it from the sibling request_consultation, which presumably files directly. The sibling distinction is inferred rather than named outright, 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?
'Used by hosts that show a Get Quote button' gives a situational context, and the pointer to source business_id from the business feed helps invocation. However, no alternative is named (notably request_consultation) and there are no when-not conditions, so usage remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over the firm's published pages (employment-law topics, attorney profiles, case results). Returns title, summary, URL and a Markdown URL for each match.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site/office host, e.g. sacramentolaborattorney.com. Omit for the Los Angeles office. | |
| limit | No | ||
| query | Yes | Topic, e.g. "unpaid overtime" or "fired after medical leave" |
| Name | Required | Description |
|---|---|---|
| query | No | |
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile and the closed-world scope are covered structurally. The description reinforces the closed-world scope ('the firm's published pages') and names the returned fields, but adds nothing about result limits, ordering, pagination, or what happens at the 25-item cap.
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, zero filler, and the scope statement is front-loaded before the return-value sentence. Nothing needs to be re-read or trimmed.
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 spelling out return fields is not strictly required, and annotations cover safety. However, for a search tool the description is silent on result count behavior, ordering/relevance, and whether the 25-result cap means truncation — gaps the schema does not fill either.
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% (site and query are documented, limit is not), and the description mentions no parameters at all — no explanation of the site default to the Los Angeles office, the keyword semantics of query, or the effect of limit. It therefore does nothing to compensate for the coverage gap.
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 ('Keyword search over the firm's published pages') and enumerates the content scope (employment-law topics, attorney profiles, case results). No sibling tool offers search, so an agent can immediately separate this from get_firm_info, list_offices, or the request_* 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?
The description never says when to prefer this tool, when not to use it, or what the alternatives are for related information needs (e.g. firm details via get_firm_info, offices via list_offices). Usage is only inferable from the purpose statement itself, which is no guidance at all.
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.
request_serviceget_firm_info1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "contact_page": {
+ "type": "string"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "fees": {
+ "type": "string"
+ },
+ "firm": {
+ "type": "string"
+ },
+ "how_to_reach": {
+ "type": "string"
+ },
+ "office": {
+ "type": "object"
+ },
+ "phone": {
+ "type": "string"
+ },
+ "practice_areas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "service_area": {
+ "type": "string"
+ },
+ "website": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}list_offices1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "offices": {
+ "items": {
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "city": {
+ "type": "string"
+ },
+ "county": {
+ "type": "string"
+ },
+ "phone": {
+ "type": "string"
+ },
+ "site": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}search_pages1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "query": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "markdown_url": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ },
+ "site": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}get_firm_infolist_officesrequest_consultationsearch_pagesSearch real job openings, check job posts and pay rules, and prepare California offer letters.
Read-only employment-law research: 140K+ rulings, employer track records, rights & EEOC guides.
Search 5,950 US WARN Act layoff notices by state, employer, and date (CA, TX, NY, IL, NC).
Find, compare and price licensed U.S. lawyers from official licensing records. Not legal advice.
Add one secure layer between your agents and this server.
