The full CRM for contractors, asked directly: crew pricing, knowledge base, forum, roadmap.
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.
Put someone in line for the Measure Tech PRO web console at founding pricing. 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?
Annotations provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds crucial behavioral detail about the double opt-in mechanism ('NOTHING counts until they click the confirmation email themselves'), which is not inferable from annotations. This is valuable beyond what structured fields convey, though the description doesn't specify response format or potential side effects other than the pending state.
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 core purpose, then immediately details the critical behavioral constraint (double opt-in) and the usage condition. Every sentence adds unique value, 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 tool with only two optional parameters and no output schema, the description covers the essential aspects: what it does, when to use it, the key behavioral side effect (double opt-in), and the constraint on agent action. Nothing critical is missing for an agent to decide 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 description coverage is 100%. The schema already includes descriptive text for both parameters, including the explicit warning that email must be 'the person who ASKED to join — never a guessed one'. The description adds no additional usage nuances for parameters beyond what the schema provides, 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 ('Put someone in line'), a specific resource (Measure Tech PRO web console waitlist), and a context (at founding pricing). It clearly distinguishes the action from siblings like request_contact or heart_request by focusing on the waitlist enrollment action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use only when the person explicitly asked to join', providing a clear condition for invocation. It also notes 'an agent can only ever start the ask', which implies the agent cannot complete the process unilaterally. It doesn't name sibling alternatives explicitly, but the condition is clear enough to prevent misuse.
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 opens soon. 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 mark readOnlyHint=true, so the read-only promise is covered and 'Returns' aligns with that. The description adds useful product context such as platform availability and the upcoming web console, but it does not describe the response format or any operational quirks. With no output schema, adding return-structure detail would improve transparency.
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 short sentences with no filler. The lead sentence states the tool's role, and the following sentences supply product facts and expected output. It is front-loaded and 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 no-argument, read-only info endpoint, the description clearly states what the tool returns and gives the product context needed to decide whether to call it. It is complete enough to invoke safely, although the exact JSON shape is unspecified; with no output schema, a bit more return-structure detail would make it fully self-contained.
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 exposes zero parameters, so there are no parameter semantics for the description to clarify. Under the rubric, 0 params earns a baseline of 4 because no description compensation is necessary; schema description coverage is vacuously complete.
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 ('Returns') and identifies a concrete resource: Measure Tech PRO and what the server offers. It names three distinct outputs (product summary, knowledge-base size, surface locations), making the tool's role clear. It does not explicitly contrast with the sibling get_product_overview, but the server-level scope is evident.
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 clear context: call this tool for a high-level orientation about Measure Tech PRO, including platform availability and server-provided information. It does not name sibling alternatives or exclusions, but the zero-parameter interface and explicit return list make the intended use fairly unambiguous.
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. Dates show when Glama detected each change.
comment_on_requestget_forum_threadget_pricingget_product_overviewget_roadmapheart_requestjoin_waitlistmy_requestspost_feature_requestrequest_contactsearch_forumsearch_knowledge_baseserver_infoClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Your 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.
Most tools map to a clear resource/action, but get_product_overview and search_knowledge_base both claim to answer 'does it do X', and search_forum and get_roadmap both surface statuses, so an agent could pick the wrong one. The descriptions reduce the ambiguity but do not fully eliminate it.
The set uses lower_snake_case and broadly follows a verb_noun shape with get_/search_ prefixes for reads. However, my_requests and server_info are noun phrases and comment_on_request inserts a preposition, so the pattern is not perfectly uniform.
At 13 tools, the count is well within a reasonable range for the scope: product info, pricing, forum search/read/write, hearts/comments, waitlist, contact, and personal status. Each tool covers a distinct interaction area and none feels redundant enough to cut.
The surface covers the main customer journeys: learn about the product, search/read forum, post/comment/heart, check personal requests, ask for contact, and join the waitlist. Minor gaps exist (e.g., no edit/delete for comments or a way to check waitlist status), but agents can complete core workflows without dead ends.
