Search certified insurance appraisers and umpires by state, city, role and specialty.
Scored across 3 tools
Each tool has a clearly distinct purpose: educational content, single-profile retrieval, and directory search. An agent can easily distinguish when to explain the process, fetch a known appraiser, or search for appraisers.
All tools use consistent snake_case with clear action verbs: explain_, get_, search_. The pattern is predictable and readable across the set.
Three tools are well-scoped for a directory lookup server: one explains context, one searches, and one retrieves a specific profile. Each tool earns its place without redundancy.
The core directory workflows are covered: searching appraisers, retrieving a full profile, and explaining the appraisal process. Minor gaps may exist around listing available specialties, roles, or certifications as filter metadata, but agents can work around these via search.
Explain the insurance appraisal process (neutral overview).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden. It does disclose the content posture ('neutral overview'), signaling this is informational and non-advisory rather than a personalized or transactional result, but it says nothing about the return shape (static text, enumerated stages, jurisdiction-specific caveats) or whether the content is fixed.
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 short sentence with the resource front-loaded and no filler. It is efficient, though the parenthetical '(neutral overview)' is doing the only differentiation work and could be folded into a stronger clause.
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 zero-parameter, no-annotation, no-output-schema tool, the definition is minimally viable: an agent knows what it will get at a high level. It stops short of describing what the explanation contains or how it is framed, which is the one piece of context that would make the tool unambiguously callable without trial.
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 there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies a parameterless, general-purpose 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?
States a specific verb and resource: explains the insurance appraisal process, with a qualifier that the content is a neutral overview. This is clearly distinct from the sibling lookup tools (get_appraiser_profile, search_appraisers), though the description never names them explicitly.
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 on when an agent should call this versus the sibling tools, or what kind of user question it answers (e.g., 'how does appraisal work?' vs 'who is my appraiser?'). Usage is only inferable from the name and the word 'overview'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one LossHQ professional's full public profile by username.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says the profile is public and full, but does not clarify read-only behavior, authentication requirements, not-found handling, or return format.
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 with no wasted words, appropriate for a simple one-parameter lookup.
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 description is adequate for identifying the resource and the required username, but with no annotations or output schema it omits useful details such as error behavior and what "full public profile" includes.
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 0%, so the description must compensate for the single undocumented parameter. It adds only that username identifies a LossHQ professional, without format or matching details.
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 ("Get ... full public profile") and scopes it to one professional by username, which implicitly distinguishes it from the plural sibling search_appraisers.
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 username" implies the tool is used when the username is already known, but it does not explicitly say when to use this versus search_appraisers or explain_appraisal_process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search LossHQ's directory of certified insurance appraisers and umpires by location, role, specialty, or certification.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| role | No | ||
| query | No | ||
| state | No | ||
| specialty | No | ||
| certification | No |
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 behavioral disclosure and largely drops it. It never says whether results are paginated or capped, whether the search is exact-match or fuzzy, whether it requires authentication/licensing scope, or whether omitting all filters returns the whole directory — all material for a six-parameter discovery tool.
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 tight sentence with the resource and the filter axes front-loaded. Nothing is redundant and nothing needs trimming.
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 annotations, no output schema, and six undocumented parameters, the one-line description is insufficient for an agent to call this correctly. At minimum it should explain the query parameter, the default role behavior, and whether unfiltered calls return the full directory.
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 0% and the description only gestures at four of the six parameters in generic prose ('location, role, specialty, or certification'), collapsing city and state into 'location'. The free-text 'query' parameter is left entirely unexplained in both schema and description, and there is no guidance on formats or on the appraiser/umpire/both role enum.
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 — searching a directory of certified insurance appraisers and umpires — and names the filter dimensions. It distinguishes itself implicitly from get_appraiser_profile (lookup of one known entity) by framing this as directory search, though it never names the siblings outright.
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 agent can infer 'use this to discover appraisers by attribute' from the listed filters. There is no explicit when-not guidance, no note on what an empty search returns (all records vs. an error), and no reference to get_appraiser_profile or explain_appraisal_process as alternatives.
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.
explain_appraisal_processget_appraiser_profilesearch_appraisersSearch public FAIR appraiser profiles by location, specialty, and intended use.
Find IICRC certified water damage, mold and restoration contractors in the US with emails and phones
1,679 licensed public adjusters across US states.
Find checked US roofers, siding and gutter contractors by city. Read-only, no login.
Add one secure layer between your agents and this server.
