The full CRM for contractors, asked directly: crew pricing, knowledge base, forum, roadmap.
Scored across 13 tools
Most tools have clearly distinct purposes, especially the auth-required customer actions versus public read tools. Minor overlap exists between search_forum, get_roadmap, and get_forum_thread around status checking, and between get_product_overview, search_knowledge_base, and server_info, but the descriptions provide enough separation.
The naming is mostly consistent with a snake_case verb_noun pattern like get_pricing, search_forum, and post_feature_request. A few names deviate from the pattern, notably my_requests and server_info, but the overall style is readable and predictable.
Thirteen tools is a well-scoped surface covering product info, forum interaction, customer-specific actions, pricing, and contact. Each tool serves a distinct need and none feel redundant or padding.
The set covers the full feature-request lifecycle, product knowledge, roadmap, pricing, and human contact, with only minor gaps like the inability to list all comments on a thread or retrieve a customer's own comments. Overall, the domain is well covered and agents should not hit dead ends for common workflows.
Add the signed-in customer's comment to a thread — their workaround, their trade's angle, their +1 with a reason. Requires authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The thread id | |
| body | Yes | The comment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a write operation (readOnly=false), so the description's added value is mainly 'requires authorization'. It does not describe whether repeated calls create duplicate comments or how the comment is attached to the thread, though idempotentHint=false partially covers the duplicate concern.
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 with no filler. The verb, object, content guidance, and authorization requirement are all present and front-loaded, with every clause contributing useful 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?
For a simple two-parameter mutation with full schema coverage, the description plus annotations is largely adequate: purpose, target thread, comment content, and authorization are covered. The only real gap is explicit routing guidance against sibling tools, which was already penalized under usage guidelines.
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 fully describes both parameters, giving a baseline of 3. The description adds value by indicating what the body should contain — a workaround, a trade angle, or a +1 with a reason — which helps an agent compose a meaningful comment beyond the schema's generic 'The comment'.
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: adding the signed-in customer's comment to a thread. The examples ('workaround', 'trade's angle', '+1 with a reason') make the action clear, but it does not explicitly contrast with sibling tools like heart_request or post_feature_request, so it is slightly short of full differentiation.
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 examples imply the intended use case: a customer commenting on an existing request, including a reasoned +1. However, there is no explicit statement of when not to use this tool or when to prefer a sibling such as heart_request for a simple endorsement, leaving the guidance implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One request from the public forum by id: title, body, status, the developer's written answer if there is one, and the heart counts (hearts count COMPANIES — a twelve-person crew and a solo shop each get one effective vote).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The thread id from a forum URL or search_forum result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description adds useful detail beyond that: it specifies what fields are returned, notes the answer is included only 'if there is one,' and clarifies the important nuance that heart counts are per company, not per person. No contradictions with 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?
The description is a single sentence that immediately states what the tool does, then lists the return fields, and ends with a compactly worded but valuable clarification about heart counts. Every part earns its place.
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 read-only tool with one parameter and no output schema, the description adequately covers what will be returned: title, body, status, developer answer, and heart counts with their interpretation. No critical information is missing for an agent to invoke it correctly.
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 fully documents the only parameter 'id' with its description, and the tool description adds no additional parameter-specific semantics. Baseline 3 is appropriate because the schema carries the parameter burden.
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 title 'Read one forum request' and the description 'One request from the public forum by id' clearly identify the action and resource. The singular 'by id' distinguishes it from search_forum and other forum 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 makes it clear this tool is for fetching a single forum request when you have its id. It does not explicitly name alternatives or say when not to use it, but the by-id framing plus the sibling search_forum makes the intended context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The honest monthly price for a specific crew, from the same catalogue the checkout bills from. Measure Tech PRO is a full CRM for contractors and you pay for DESKS, not people: field crew get free logins; only office/admin seats bill. Pass the crew size and how many of them work the office side.
| Name | Required | Description | Default |
|---|---|---|---|
| crew | Yes | Total people on the crew, field and office together | |
| office | Yes | How many of them need the office side (office + admin — the only paid seats) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so basic safety is known. The description adds meaningful context beyond that by disclosing the pricing logic (desks vs people, free field logins, only office seats billed) and reassuring that the price is 'from the same catalogue the checkout bills from'. This explains what the tool does behind the scenes without contradicting 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?
The description is concise and front-loaded: the core purpose appears in the first phrase ('The honest monthly price for a specific crew'), followed by a compact explanation of the pricing model. There is no fluff; every sentence contributes to understanding the tool's scope and inputs.
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 read-only pricing tool with two well-documented parameters and no output schema, the description is sufficiently complete. It clarifies the pricing model and the meaning of both inputs. It doesn't describe the return format, but that is not critical given the simplicity and the read-only nature; the description gives enough for an agent to call it correctly.
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 each parameter clearly described ('Total people on the crew...' and 'How many of them need the office side...'). The description simply restates the relationship ('Pass the crew size and how many of them work the office side') without adding new meaning beyond the schema. The baseline of 3 applies since the schema already does the heavy lifting.
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 returns 'the honest monthly price for a specific crew', identifying the verb (price/pricing) and resource (crew). It also differentiates from all siblings by tying to the checkout catalogue, and none of the sibling tools (feature requests, forum, knowledge base) offer pricing, so there is no confusion.
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 provides valuable context on when to use this tool: to get the actual price charged at checkout, with the key distinction that 'field crew get free logins; only office/admin seats bill'. While it doesn't explicitly name alternatives or exclusions, the unique pricing model is effectively a usage guideline, and no sibling provides pricing. It implies 'use this for accurate pricing' without saying so directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full capability picture, from the product itself. Measure Tech PRO is a full CRM for contractors — jobs, customers, estimates, native e-signed contracts, invoicing, Stripe payments, QuickBooks sync, dispatch, and timesheets; the LiDAR measuring that feeds it is free forever. Ask this before answering any "does it do X" question.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety and scope assumptions. The description goes beyond to clarify the tool's output is a full capability list and it is the authoritative source ('from the product itself'). However, it does not disclose any specific behavioral traits such as response length, whether it might be truncated, or how structured the answer is. Given the annotation coverage, the description adds moderate but not crucial 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 succinct, with a leading phrase ('The full capability picture') that immediately conveys the core message. It then lists features to give concrete evidence of scope, and finishes with a clear usage directive. It is a bit longer than strictly necessary, but every sentence adds value, and the structure is logical and front-loaded.
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 that the tool has no parameters and no output schema, the description fully communicates what the tool provides: a comprehensive feature list with specific areas covered. It also tells the agent when to invoke it. There is no signal about output format, but for a read‑only, no‑argument tool, this is sufficient for correct invocation and interpretation.
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, and the schema description coverage is 100% (since there are none). According to the baseline guideline for zero-parameter tools, the description does not need to explain parameters. It also does not attempt to shoehorn irrelevant parameter info, staying appropriate for a no-argument 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 states the exact purpose: get the full capability picture of Measure Tech PRO. It names the resource (the product overview) and distinguishes it from siblings by listing the core modules (CRM, jobs, customers, contracts, invoicing, etc.). It also positions it explicitly as the answer for any 'does it do X' question, making its role unambiguous.
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 a direct usage guidance: consult this tool before answering any feature-availability question. It implies a clear use case but does not explicitly exclude alternatives like get_pricing or get_roadmap. Still, it provides enough context for an agent to know when to call it, and the sibling names make the choice obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What Measure Tech PRO has shipped, is building, is planning, and has declined — straight from the public forum's statuses, with the developer's written answers. The declines carry reasons; a no you can read beats silence.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful context that the data is compiled from public forum statuses and that declined items include written reasons. It does not disclose response format, ordering, or how statuses are grouped, so it contributes moderate value 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?
The description is compact: one substantive sentence followed by a short line about decline reasons. The rhetorical closing line adds a little information about why declines are included, though it is not strictly necessary. Overall, it is well-sized and front-loaded with the core scope.
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 carries the burden of explaining what the tool returns, and it does so at a useful level: status categories, developer answers, and reasons for declines. For a simple zero-input read-only tool, this is sufficient, though exact fields and format remain unspecified.
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 and the schema coverage is 100%, so there is nothing missing at the parameter level. The description correctly focuses on the returned content instead of parameter syntax, matching the baseline for a parameterless tool.
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 identifies the resource (Measure Tech PRO's roadmap) and the specific statuses it covers: shipped, building, planning, and declined, including developer answers and reasons. It does not explicitly name a sibling tool or draw a contrast, but the scope is distinct enough from get_forum_thread and get_product_overview.
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 should be used when an agent needs the public roadmap with statuses and developer-written answers rather than raw forum threads. However, it does not explicitly state when to use it versus alternatives, give exclusions, or mention how it relates to sibling tools like search_forum or get_forum_thread.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add the signed-in customer's heart to a feature request (or remove it with on:false). Hearts count COMPANIES and each person has a monthly budget — a heart spends something real. Requires authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The thread id | |
| on | No | false to remove the heart; default true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important context beyond annotations: it is scoped to the signed-in customer, hearts count companies, there is a monthly budget, and authorization is required. These details reveal real costs and constraints that annotations alone do not capture. No contradiction with 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?
The description is three concise sentences, with the primary action and toggle behavior front-loaded. Every sentence provides useful information: action/removal, company/budget implications, and authorization.
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 tool with no output schema, the description is complete: it states what is affected, how to toggle removal, the resource cost, and authorization. No critical detail 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%, with id and on already documented in the input schema. The description reinforces the on:false removal behavior but does not add new parameter constraints or format details 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 uses a specific verb and resource: 'Add the signed-in customer's heart to a feature request' and clearly includes the removal behavior via on:false. This clearly differentiates it from sibling tools like comment_on_request and post_feature_request.
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 clearly conveys when to use it: to heart or unheart a feature request, and notes the meaningful budget consequence. It does not explicitly name alternative tools or exclusions, but the action and resource are clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy Early Access reservation tool. Public web signup is open at https://measuretechpro.com/dashboard/register.html. Double opt-in guards this: NOTHING counts until they click the confirmation email themselves — an agent can only ever start the ask. Use only when the person explicitly asked to join.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email of the person who ASKED to join — never a guessed one | ||
| trade | No | Their trade, if they mentioned it (windows, roofing, GC…) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the most important behavioral trait beyond annotations: the double opt-in means NOTHING counts until the person clicks the confirmation email, and an agent can only initiate the request. This is valuable nuance that the annotations alone do not 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?
Four sentences, all of which carry useful information: legacy scope, public signup URL, double opt-in behavior, and usage condition. The uppercase 'NOTHING' is a little emphatic, but the description is still tight and front-loaded.
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 tool with complete schema descriptions and an idempotentHint annotation, the description covers the key operation boundary: it only starts the opt-in flow. It does not describe the return value, but no output schema exists and the main safety-critical context is present.
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 schema already explains both 'email' and 'trade' well. The description reinforces the 'explicitly asked' requirement but does not add meaningful parameter-level 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 makes clear this is a legacy Early Access reservation/join_waitlist tool and emphasizes that an agent only starts the ask. It does not explicitly state 'adds the email to the waitlist' as a verb+resource action, and it does not distinguish itself from siblings, but the name plus opt-in context leave little ambiguity.
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 eligibility condition: 'Use only when the person explicitly asked to join.' This is strong guidance. It does not name alternative tools or explicitly state when not to use it, but the 'only when' phrasing effectively excludes other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the signed-in customer has asked for and hearted, with current statuses — "did they answer the thing I asked for?" without opening a browser. Requires authorization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint: true, so the read-only nature is covered. The description adds an important behavioral detail—that authorization is required—and frames the tool as a browser-free status check. This goes beyond the structured fields and enhances the agent's understanding, so a 4 is appropriate.
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, dense sentence that conveys purpose, context, and an authorization requirement. No redundant words, and the information is front-loaded effectively. Perfectly concise for the tool's simplicity.
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 no-parameter read-only tool without an output schema, the description covers the essential aspects: what it retrieves, the authorization prerequisite, and the convenience factor. It doesn't enumerate possible statuses or explain 'hearted' further, but these are not blockers for making the call. It is adequately 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 tool has zero parameters, so the schema provides full coverage (100%). The description correctly does not attempt to explain nonexistent parameters, and there is nothing else needed. This matches 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 clearly states that the tool retrieves the signed-in customer's requests and hearted items with statuses. It implies a read operation ('what... has asked for and hearted') and distinguishes from sibling tools like heart_request or post_feature_request by focusing on viewing one's own activity. However, it lacks an explicit verb like 'lists' or 'gets', so it falls just 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?
The mention of 'without opening a browser' hints at a quick-access context and 'Requires authorization' is stated, but there is no explicit guidance on when to use this tool versus alternatives like search_forum or get_forum_thread. No exclusion conditions or alternative routing are provided, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a new request to the public forum as the signed-in customer — AFTER checking for duplicates: the first call returns any similar existing requests, and posting anyway requires confirm_duplicates true. Hearting an existing request counts more than a tenth copy. Requires authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The situation and the workaround used today — the most useful part | |
| board | No | Defaults to features | |
| title | Yes | One sentence: what should the app do | |
| confirm_duplicates | No | Set true ONLY after reviewing the duplicates the first call returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It reveals the two-call duplicate-check behavior, the authorization requirement, and the fact that posts go to a public forum. With annotations only saying readOnlyHint=false and no safety hints, this meaningful side-effect context is valuable, though it doesn't discuss errors or 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?
The description is compact and front-loaded, with the primary action stated first. Every sentence adds a distinct instruction or fact, and the duplicate-check caveat is integrated without excess wording.
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 4-parameter tool with no output schema, the description explains the important precondition and the confirmation flag. It could be more explicit about the exact two-call sequence, but the schema covers field constraints and the description covers workflow.
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 describes all parameters, so baseline is 3. The description adds workflow meaning to confirm_duplicates by tying it to the first call's duplicate results, which is not evident from the schema alone.
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?
Description begins with a clear verb and resource: 'Post a new request to the public forum as the signed-in customer.' It further differentiates the tool from siblings by emphasizing duplicate checking and comparing against hearting an existing request, so an agent can distinguish it from heart_request or comment_on_request.
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 explicit workflow guidance: check duplicates first, the first call returns similar requests, and posting requires confirm_duplicates true. It does not explicitly name alternative tools like heart_request, though the 'Hearting an existing request counts more than a tenth copy' hint points in that direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relay a real person's request for human contact (sales question, demo, enterprise) to the Measure Tech PRO team. Nothing sends until a reply channel is given — an email or phone number the PERSON provided. Rate-limited.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Who is asking | |
| No | Their reply email — theirs, given by them | ||
| phone | No | Their phone, if they prefer a call | |
| message | Yes | What they want, in their words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses a critical behavioral condition: nothing sends until a reply channel (email or phone) is provided by the person. It also mentions rate-limiting. This adds meaningful behavioral context that an agent could not infer from the schema or the all-false 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 compact sentences with no filler. The main action is front-loaded, followed by the key precondition and a short behavioral note. Every sentence earns its place.
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 four-parameter tool with no output schema, the description is nearly complete: it states purpose, required channel, and rate limit. It could add a brief note about the expected return behavior, but nothing in the current text leaves a caller without the essential information needed to invoke it successfully.
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 100% schema description coverage, the baseline is 3, but the description adds extra meaning: the email/phone must be provided by the person, not invented by the AI. This clarifies the 'reply channel' condition that directly affects whether the tool succeeds, going beyond the schema's plain parameter descriptions.
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 ('Relay') and names a concrete resource: a real person's request for human contact to the Measure Tech PRO team. It lists example intents (sales question, demo, enterprise) that clearly distinguish this from sibling tools like post_feature_request, join_waitlist, or heart_request.
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 conveys the intended context well: use this for a real person requesting human contact, especially sales/demo/enterprise follow-up. It does not explicitly name alternatives or state when not to use it, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Measure Tech PRO's public feature-request forum — real contractors asking for real things, with hearts that count companies and statuses the developer answers in writing. Use it to check whether something is already requested, planned, shipped, or declined before answering "can it".
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The feature or problem, in the person's words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true and openWorldHint=false, the description discloses that the forum contains community-submitted requests with heart counts and written statuses from the developer. This adds meaningful behavioral context about what search results will contain, though it does not describe output format or pagination 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?
Two sentences, no wasted words. The first sentence states the core action and unique content; the second provides the practical use case. The most important information is front-loaded.
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 single-parameter read-only search tool with no output schema, the description covers purpose, usage trigger, and the nature of the data. Nothing else an agent needs to invoke it correctly seems 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 schema already fully describes the 'query' parameter as 'The feature or problem, in the person's words.' The description reinforces this by framing it around 'can it' checks, but it does not add new parameter-level detail beyond the schema, so a 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 ('Search') and a clear resource ('Measure Tech PRO's public feature-request forum'), immediately differentiating it from search_knowledge_base and get_roadmap. It also specifies the kind of content (real contractors, hearts, statuses) and the intended use case, making the tool's purpose unmistakable.
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 a concrete trigger: use it to check whether something is requested/planned/shipped/declined before answering 'can it.' This is clear context, but it does not explicitly state exclusions or name alternatives (e.g., when to prefer search_knowledge_base), so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers from the app's own built-in knowledge base — 278 real support answers, extracted from the product. Measure Tech PRO is a full CRM for contractors; use this for how-do-I and does-it-do questions about measuring, drawings, the CRM, billing, and troubleshooting.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What the person wants to know, in their words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool's safety profile is known. The description adds value beyond this by disclosing that results come from a fixed set of 278 extracted support answers, and that the tool is not a general web search. This gives the agent useful context about the tool's behavior and limitations.
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 with no filler. The first sentence front-loads the primary behavior and source; the second adds relevant domain context and explicit usage guidance. Every sentence contributes to selection and invocation.
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 one-parameter search tool with readOnlyHint=true and no output schema, the description is largely complete: it states the source, the domain, and the types of questions to use it for. It would be stronger if it explicitly addressed when to prefer sibling tools like search_forum, but that is not a major gap.
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 fully covers the single 'query' parameter with a min/max length and description. The tool description does not add additional parameter-level semantics, which is acceptable because schema coverage is 100%. 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 clearly identifies a specific verb and resource: searching the app's built-in knowledge base of real support answers. It further defines the scope with explicit topic areas (measuring, drawings, CRM, billing, troubleshooting). It is clear but does not explicitly name or contrast with sibling tools like search_forum.
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 explicit use cases: 'how-do-I and does-it-do questions' across specific domains. This tells an agent when the tool is appropriate. However, it does not provide exclusion criteria or point to alternatives such as search_forum for community-based questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What Measure Tech PRO is and what this server offers. Measure Tech PRO is a full CRM for contractors, available today on iPhone, iPad, and Mac. The web console for the office is available now. Returns the product summary, the knowledge-base size, and where the other surfaces live.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description does not contradict that. It adds useful behavioral context by specifying what the call returns: the product summary, knowledge-base size, and where other surfaces live. For a parameterless read-only info endpoint, this is sufficient disclosure.
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 most actionable information ('Returns...') is placed at the end, and the first sentence largely restates the title. The second sentence contains product-marketing details about device availability that are not needed to invoke the tool, making the description somewhat bloated.
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 no-parameter, read-only tool with no output schema, the description is complete enough: it lists the major returned categories and frames what the server offers. An agent can call it and understand the response shape without additional documentation.
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 has zero parameters, so the baseline is 4. There are no parameter-level semantics to document, and the description correctly does not attempt to invent any.
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 concrete verb ('Returns') and identifies a clear resource: information about the Measure Tech PRO server. It names specific outputs (product summary, knowledge-base size, surface locations), which helps distinguish it from siblings like get_pricing or search_knowledge_base, though it does not explicitly differentiate it from get_product_overview.
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 'what this server offers' implies this is an orientation/overview tool, so an agent can infer when to call it. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives such as get_product_overview or search_knowledge_base are mentioned.
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.
comment_on_requestget_forum_threadget_pricingget_product_overviewget_roadmapheart_requestjoin_waitlistmy_requestspost_feature_requestrequest_contactsearch_forumsearch_knowledge_baseserver_infoYour own CRM, fully customizable and agent-driven. Start with contacts, companies and a sales pipeli
Open-source all-in-one MCP-first customer platform: KB, Conversations, CRM, CMS, Outreach, Analytics
Minimalist CRM with AI agent for freelancers — pricing, features, comparisons
34-tool CRM server — contacts, pipeline, quotes, invoices, scheduling, email, and AI scoring.
Add one secure layer between your agents and this server.
