Public remote MCP server for StruXure NorCal pergola services, FAQs, and contact requests.
Scored across 10 tools
Most tools have clearly distinct retrieval roles: list_products/list_services enumerate catalogues, products/services perform semantic search, get_product/get_service fetch single named items, and faq/troubleshoot/search serve different answer types. The main ambiguity is between faq, troubleshoot, and search, but the descriptions explicitly differentiate their output and intended use, so misselection risk is limited.
Names follow a readable lowercase style, but conventions are mixed: some are verb_noun (get_product, list_services), some are single verbs (search, troubleshoot), and some are bare nouns (products, services, faq, contact). The contrast between products and list_products is understandable but not part of a fully consistent pattern.
Ten tools is well-scoped for a knowledge-base server covering products, services, FAQ, troubleshooting, generic search, and contact. Each tool has a clear purpose and the count is neither thin nor excessive.
The surface covers catalogue enumeration, single-item lookup, semantic search, FAQ content, troubleshooting, generic search, and a contact path. Some auxiliary operations such as listing FAQs or retrieving individual FAQ/troubleshooting records by ID are missing, but the main customer-facing knowledge workflows are covered.
This is for Norcal to contact the client in case they have additional questions
| Name | Required | Description | Default |
|---|---|---|---|
| what_is_your_name | Yes | What is your Name? | |
| what_is_your_email_address | No | What is your email address? | |
| where_may_we_call_or_text_you | Yes | Where may we call or text you? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It weakly implies a follow-up contact will occur, but says nothing about what happens on submission, whether data is stored or shared, expected response, or any permissions/privacy considerations for collecting phone numbers and emails.
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?
It is a single short sentence with no waste, but it is not front-loaded with the tool's action and reads as an internal note rather than an agent-facing instruction. Brevity here reflects under-specification as much as 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?
With no annotations, no output schema, and three PII-collecting parameters, the definition should explain what submitting the form accomplishes. Instead it leaves the agent guessing about the effect and the downstream follow-up, which is inadequate for a data-collection tool.
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 every parameter has a self-explanatory prompt-style description, so the schema already does the work. The description adds no additional meaning about the three fields, which is the baseline expectation.
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 sentence describes an internal intent (Norcal following up with the client) rather than the tool's action. It never states that the tool submits/collects contact information, so an agent must infer the purpose from the parameter names alone. It is close to a restatement of the tool name rather than a specific verb+resource.
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 guidance on when to invoke this versus the sibling tools faq and services, nor any prerequisite or exclusion. The phrase 'in case they have additional questions' hints at a trigger condition but never states it as an instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a question from this knowledge base's FAQ content. Returns the closest-matching FAQ passages, not extracted answers — for a customer reporting that something is broken, troubleshoot returns the resolution itself.
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | Maximum number of results to return (1–20). | |
| query | Yes | The question to answer from the FAQ. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It clearly discloses that it returns matching passages, not extracted answers, which is a key behavioral trait. It also implies the tool is read-only (answering a question) and sets expectations about output compatibility. This goes beyond mere purpose to explain the nature of the response.
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, concise and front-loaded with the primary purpose. It delivers the key distinction (returns passages, not answers) efficiently. No extraneous information. Slightly more could be added about typical use cases, but it is well-structured for its length.
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 retriever tool with no output schema, the description sufficiently explains what it returns (passages) and how it differs from a resolution provider. It lacks details on result format or ranking, but given the simplicity (2 params, no nested objects) and the clarity of operation, it is nearly complete. A minor gap is the absence of explicit search behavior (e.g., semantic search) or result ordering.
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 schema fully documents 'query' and 'topK'. The description does not add parameter-specific meaning beyond the schema, but it does clarify that 'query' is a natural language question and 'topK' controls result count. This is sufficient given the high schema coverage; the baseline of 3 is appropriate.
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 tool answers a question from FAQ content, specifies the action ('Answer a question') and the resource ('knowledge base's FAQ content'). It also distinguishes itself from the sibling 'troubleshoot' by noting the return type (passages vs. resolution), effectively differentiating it despite not naming 'troubleshoot' as a sibling in the given list.
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 when to use by contrasting with 'troubleshoot' for broken items, but does not explicitly state 'use when the answer is informational' or 'when not to use'. It gives a clear context but lacks explicit exclusions or alternative selection criteria beyond the one example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one product by name, as returned by list_products, with a short excerpt of the page describing it and any documents the business has attached to it — an installation guide, a spec sheet. Those attachments are the authoritative answer to "where are the instructions for X": when the list is empty, no document is on file, and searching for one will only turn up a different product's manual. If no such product exists this says so plainly and suggests the nearest names — treat that as authoritative too: the business does not offer it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The product name, exactly as returned by list_products. Matching is case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the important behavior: it returns a page excerpt plus attached documents, an empty attachment list means no document is on file, and a missing product yields a plain statement with nearest-name suggestions. It does not mention permissions, rate limits, or explicit read-only status, but for a lookup tool the disclosed return and failure semantics are substantial.
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 purpose is front-loaded in the first clause, and every sentence contributes useful guidance. The middle sentence is somewhat long and clause-heavy ('Those attachments are the authoritative answer to...'), which slightly reduces scannability, but there is no 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?
Given a one-parameter lookup with no output schema and no annotations, the description is complete: it explains what is returned, how to interpret empty attachments, and what happens when the product does not exist. Nothing an agent needs in order to call it correctly is missing.
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% and the single 'name' parameter is fully documented in the schema, including case-insensitive matching. The description reinforces that the name must be the one returned by list_products, but adds little syntax or format detail beyond the schema, so the baseline of 3 is appropriate.
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 ('Look up one product by name') and explicitly ties it to the sibling tool that produces the input ('as returned by list_products'). It also enumerates what comes back (excerpt, attached documents), making it easy to distinguish from list_products and search.
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 specifies when to use it (looking up one known product by name from list_products) and gives an explicit when-not: do not search separately for documents, because an empty attachment list is authoritative and searching 'will only turn up a different product's manual.' It also tells the agent how to interpret a missing product, which is a usage decision point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one service by name, as returned by list_services, with a short excerpt of the page describing it. If no such service exists this says so plainly and suggests the nearest names — treat that as authoritative: the business does not offer it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The service name, exactly as returned by list_services. Matching is case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers meaningful behavior: it discloses the return shape (short page excerpt), the failure mode (plainly says no such service), and the fallback behavior (suggests nearest names) plus how to interpret that negative. Missing only peripheral details like performance or auth expectations.
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 front-loaded sentences with the core action first and the failure semantics second; no filler. Slightly dense in the second sentence but every clause carries information the agent needs.
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, the description must explain returns, and it does (page excerpt, negative result, nearest-name suggestions). For a one-parameter read lookup this is close to complete; only the exact response structure is left unspecified, which is acceptable given the tool's simplicity.
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% and the single parameter already documents that the name must match list_services output and is case-insensitive. The description repeats the sourcing constraint but adds no syntax or format detail beyond the schema, 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?
States a specific verb and resource ('look up one service by name') and scopes it as a single-item lookup, which cleanly separates it from the sibling list_services. An agent can pick it without opening the schema.
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?
Ties usage to list_services as the source of the name and tells the agent how to treat a not-found result ('treat that as authoritative: the business does not offer it'). It does not explicitly say 'use list_services when you need the full catalog', so the routing guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this business's products from its extracted catalogue. This is a complete, enumerable list with a total count — unlike products, which is a semantic search returning only the closest matches. Use filter to narrow by name and offset to page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (1-100). Default 25. | |
| filter | No | Optional words to narrow the list; case-insensitive. Each word must appear in the name or summary, in any order — so fewer, more distinctive words match more. Omit it to list the whole catalogue. | |
| offset | No | How many to skip. Pass the nextOffset from the previous call to get the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose key behavior: the result is a complete, enumerable list with a total count, distinct from ranked semantic results, and it is paginated. It does not mention permissions, rate limits, or auth, which keeps it short of a 5.
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 tight sentences: identity and scope first, differentiation from the sibling second, paging guidance last. No filler and nothing buried.
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 three-parameter read tool with no output schema, the description supplies enough — it signals a total count and nextOffset-style paging exist. What is missing is any hint of the product fields returned, though the schema's parameter docs largely compensate.
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%, so all three parameters are already well documented, including the `nextOffset` paging handoff. The description only restates the roles of `filter` and `offset` and is actually slightly narrower than the schema (says "narrow by name" where the schema also matches summary), so it adds little beyond baseline.
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 ("List this business's products from its extracted catalogue") and immediately distinguishes itself from the sibling `products` by contrasting enumerable listing with semantic search. An agent can pick between the two without opening either schema.
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 names the alternative (`products`) and the condition that selects it, then states how to narrow with `filter` and page with `offset`. Both the when-to-use and the when-to-use-something-else cases are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this business's services from its extracted catalogue. This is a complete, enumerable list with a total count — unlike services, which is a semantic search returning only the closest matches. Use filter to narrow by name and offset to page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (1-100). Default 25. | |
| filter | No | Optional words to narrow the list; case-insensitive. Each word must appear in the name or summary, in any order — so fewer, more distinctive words match more. Omit it to list the whole catalogue. | |
| offset | No | How many to skip. Pass the nextOffset from the previous call to get the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does reasonably well: it discloses that results are complete and enumerable, that a total count is returned, and that the sibling does semantic ranking. It doesn't mention permissions or rate limits, but for a read-only listing tool those are minor gaps.
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 tight sentences with zero padding. The core purpose and the sibling differentiation are front-loaded, and the practical paging guidance trails appropriately.
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?
No output schema exists, but the description compensates by telling the agent a total count is returned and the list is complete/enumerable, and the schema documents nextOffset for paging. Only finer return-format details are unstated, which is a small gap for a low-complexity list tool.
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%, so all three parameters (limit, filter, offset) are already fully documented in the schema, including the multi-word AND matching behavior. The description's 'use filter to narrow' and 'use offset to page' restate schema guidance rather than adding new meaning; baseline 3 is appropriate.
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 ('List this business's services from its extracted catalogue') and immediately distinguishes it from the sibling `services` tool by characterizing that one as a semantic search returning closest matches. An agent can route between the two without opening either schema.
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 explicitly names the alternative (`services`), explains the condition that selects this tool (need for a complete, enumerable list with a count), and directs the agent to use `filter` to narrow and `offset` to page. When-to-use and when-to-use-something-else are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find products relevant to a natural-language query. Returns the closest matches, not a complete catalogue — use list_products for the complete catalogue.
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | Maximum number of results to return (1–20). | |
| query | Yes | What the user wants — describe the product they're looking for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the behavioral burden. It usefully discloses that results are a ranked subset rather than the full catalogue, but says nothing about ordering semantics, whether results are relevance-scored, or how `topK` truncation affects recall.
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 with zero waste. The core behavior is front-loaded and the sibling routing follows immediately after.
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 two-parameter, fully-documented search tool with no annotations and no output schema, the description covers what the tool does and how its result set differs from a listing. The remaining gap is the undocumented `search` sibling relationship rather than anything about this tool's own mechanics.
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%, so both `query` and `topK` are already documented, and the default of 3 applies. The description reinforces the natural-language intent of `query` and implies ranked "closest matches" semantics for `topK`, but adds no format or behavior detail beyond the schema.
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 ("Find products relevant to a natural-language query") and explicitly distinguishes itself from `list_products`. It does not, however, differentiate itself from the sibling `search` tool, which an agent could plausibly confuse with this one.
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 an explicit alternative and the condition that selects it: use `list_products` for the complete catalogue. There is no guidance on when to prefer `search` or `get_product` instead, so the routing is clear against one sibling but not all of them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search this knowledge base for content relevant to a natural-language query. Returns the closest-matching snippets with their source, not an exhaustive list.
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | Maximum number of results to return (1–20). | |
| query | Yes | The natural-language query to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that results are closest-matching snippets (i.e., ranked/approximate) rather than exhaustive, and that each carries a source. It omits read-only nature, permissions, freshness of the index, and any rate limits.
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 compact sentences with the core purpose front-loaded and no padding. Every clause earns its place, though the return-behavior clause could have been equally brief.
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 two-parameter query tool with no output schema and full schema coverage, the description covers what it does and the shape of the return (ranked snippets with source). It is nearly complete; only auth and index-scope details are absent.
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 both parameters are already documented with types and the topK range (1–20). The description only reinforces the natural-language framing of the query, adding no syntax, weighting, or filtering semantics beyond the schema.
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 clear verb (Search) and resource (this knowledge base) plus the input type (natural-language query). Siblings like get_service, list_services and submit_contact are unrelated operations, so no differentiation is needed, but 'this knowledge base' is slightly vague about scope.
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 implied by the contrast with 'an exhaustive list,' which tells the agent this is a ranked-relevance lookup rather than a full enumeration. However, there is no explicit statement of when to prefer this tool or what prerequisites (auth, index scope) apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find service offerings relevant to a natural-language query. Returns the closest matches, not a complete list — use list_services for the complete catalogue.
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | Maximum number of results to return (1–20). | |
| query | Yes | What the user wants — describe the service they're looking for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose an important trait: the tool returns closest matches, not a complete list. However, it does not mention whether the operation is read-only, how it handles empty or poor matches, or what the result shape looks like.
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 entire description is one sentence that front-loads the core behavior and ends with a practical routing instruction. Every word earns its place, with no 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?
For a simple two-parameter search tool, the description plus schema is nearly sufficient for an agent to select and invoke it correctly. The main gap is the absence of an output schema and any mention of edge-case behavior, but these are not critical for basic invocation.
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 both `query` and `topK` are already documented. The description adds 'natural-language' framing, but this is largely reflected in the schema's own query description. No substantial extra parameter meaning is provided.
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 and resource: 'Find service offerings relevant to a natural-language query.' It also explicitly contrasts itself with `list_services` by saying it returns closest matches rather than a complete list, making its role clear.
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 gives clear usage context: use this tool for natural-language service search, and use `list_services` when a complete catalogue is needed. It does not explicitly address the `faq` sibling, but the domain difference is evident enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the resolution for a problem a customer is reporting, or the answer to a question they asked, from question-and-answer pairs extracted out of this business's FAQ pages and installation guides. Use this the moment a customer reports that something is wrong or does not work — it returns the actual fix rather than a passage that mentions the part, which is what search and faq would give you. Pass their words through unchanged. An empty result with a non-zero total means this business has troubleshooting material and none of it covers this, which you can say plainly.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (1-10). Default 3. | |
| problem | Yes | The problem in the customer's own words, or the question they asked. Pass it through as they said it — the match is on their vocabulary, so rephrasing it into the manual's terms makes it worse, not better. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden, and it does most of the work: it discloses the shape of the return (an actual resolution, not a keyword-matching passage) and, unusually, the semantics of an empty result set paired with a non-zero total, which prevents a false 'no material exists' conclusion. It omits any note on ranking, relevance thresholds, or what the match is keyed on beyond the customer's vocabulary, so it falls just short of fully documented behavior.
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?
Four sentences, front-loaded with the purpose, then the trigger, then the sibling contrast, then the edge case. Every sentence earns its place, and the ordering puts the decision-relevant information first.
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 two-parameter read tool with no output schema and no annotations, the description covers purpose, trigger, alternative routing, and return/empty-result semantics — the agent knows both how to call it and how to interpret a null result. Nothing needed to invoke it correctly is missing.
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 both `problem` and `limit` are already documented in structured fields, and the description's 'pass their words through unchanged' restates the schema's own instruction about verbatim matching. It reinforces the critical constraint but adds no new meaning beyond what the schema provides, 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 names a specific verb (find the resolution/answer) and a specific resource (question-and-answer pairs extracted from FAQ pages and installation guides), and explicitly contrasts the output against the `search` and `faq` siblings — it returns the fix, not a passage that merely mentions the part. An agent can distinguish this from every sibling without opening a schema.
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 precise trigger — 'the moment a customer reports that something is wrong or does not work' — plus the question-answering case, and names the alternatives (`search`, `faq`) along with why they are inferior here. It even covers the negative outcome: an empty result with a non-zero total means the business has material that does not cover this, and that can be said plainly.
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.
get_productget_servicelist_productslist_servicesproductssearchtroubleshootcontactfaqservicesPublic, read-only MCP server for FarmNeural company facts, packages, and capabilities.
Public remote MCP server for Walnai AI Consulting services, pricing, calculator, FAQs, and adoption.
MCP server for CertScore.ai public website risk-signal workflows.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Add one secure layer between your agents and this server.
