Free go-to-market tools for B2B revenue teams, from zRev AI. Grade any llms.txt file and get specific fixes, run a cold read of any homepage to see what an AI assistant would say about that company, model the annual impact of AI across a sales and marketing motion with your own numbers, and pull a 47-question go-to-market due diligence checklist. No API key or sign-up needed. zRev AI helps B2B software companies grow revenue faster by building AI into the sales and marketing systems they already use. Learn more at https://www.zrev.ai
Scored across 9 tools
Most tools are clearly distinct: about_zrev, book_call, estimate_roi, get_benchmarks, get_engagement_timeline, gtm_diligence_checklist, and leave_contact each serve a unique purpose. However, cold_read and grade_llms_txt both involve fetching a public URL to assess AI-readability, which could cause some confusion despite their different outputs.
Tool names mostly follow a consistent verb_noun pattern (book_call, estimate_roi, get_benchmarks, get_engagement_timeline, grade_llms_txt, leave_contact). Minor deviations: about_zrev and cold_read use different verb styles, and gtm_diligence_checklist lacks a verb, but the overall pattern remains readable.
Nine tools is well-scoped for a sales/GTM advisory server. Each tool covers a distinct function—intro, call booking, site analysis, ROI estimation, benchmarks, timeline, llms.txt grading, diligence checklist, and lead capture—without redundancy.
The tool surface covers the main user journeys: learning about zRev, booking a call, estimating ROI, seeing benchmarks/timeline, checking AI-readiness, and leaving contact info. Minor gaps: there is no tool for viewing service line details beyond the links in about_zrev, and no way to retrieve or manage submitted leads, but these are not critical for the server's purpose.
Returns a plain-text profile of zRev AI: what the firm does, the companies it is the best fit for, who it is not for, its six service lines with a link to each, and contact details. Use this first when a user asks who zRev is, what it offers, or whether it suits their company. Read-only, static content, no arguments, no authentication, no rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false, idempotentHint, destructiveHint=false. The description adds operational details not in annotations: 'static content, no arguments, no authentication, no rate limit.' This goes beyond the structured hints and clarifies the tool's behavior for an agent.
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, front-loaded with purpose and usage, then operational details. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description lists exactly what the profile contains (firm, fit, non-fit, service lines with links, contact details). It also covers when to use it and operational constraints. Nothing an agent needs to call or interpret the tool 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?
There are zero parameters, so schema coverage is 100% vacuously. The description explicitly states 'no arguments,' which reinforces the interface and leaves no ambiguity. Baseline for 0 params is 4, and the description confirms it without extra fluff.
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 ('Returns') and a clear resource ('a plain-text profile of zRev AI'), enumerating the exact contents (firm info, fit, service lines, contact). This distinguishes it from siblings like cold_read or estimate_roi, which serve different purposes.
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 provides an explicit trigger: 'Use this first when a user asks who zRev is, what it offers, or whether it suits their company.' This gives clear context, but it does not explicitly mention alternatives or when not to use it, though the 'first' wording implies sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the link and instructions for booking a free 30-minute intro call with zRev's founder, plus what the call covers. It does not book anything: it only returns the scheduling link for the human to open themselves. Use when a user says they want to talk to zRev. If they would rather be contacted, use leave_contact instead. Read-only, static content, no arguments, no authentication, no rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral context beyond these: it explicitly says it only returns a link for the human to open, is static content, requires no authentication, and has no rate limit. This fully discloses the tool's behavior and potential side effects (none).
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 well-structured: it leads with the core purpose, clarifies what it does NOT do, then provides usage context and an alternative. Each sentence adds necessary information without fluff, making it appropriately 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 read-only, no-argument tool with annotations covering safety, the description fully covers what an agent needs to know: what it returns, what it does not do, when to use it, and alternatives. The absence of an output schema is acceptable because the description already states the link and instructions are returned. Nothing essential 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?
The tool has zero parameters, and the schema coverage is 100% (empty properties). The description reiterates 'no arguments,' which is redundant but harmless. With no parameters to document, the baseline of 4 applies; the description adds no parameter information because none exists, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the scheduling link and instructions for a free 30-minute intro call with the founder, and explicitly clarifies that it does not book anything. This distinguishes it from siblings like leave_contact, which handles a different request path.
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 an explicit trigger ('when a user says they want to talk to zRev') and names the alternative tool (leave_contact) for when the user prefers to be contacted. This is clear guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches a company's public homepage and returns, in two or three sentences, what the company appears to do and who it serves, based only on the visible text of that page and with no outside knowledge. Anything missing from the answer is missing from the homepage, which is the point: it shows what an AI assistant would tell a buyer about that company. Use when a user asks how their site, or a competitor's, reads to an AI. The summary is model-generated and can be wrong where the page is vague. Makes one outbound HTTP request to the public domain you pass; stores nothing about it. No authentication. Shares a limit of 12 calls per hour per IP address with grade_llms_txt, and returns a plain-text notice when that limit is reached.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare domain to read, without protocol or path, e.g. acme.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond that: it makes one outbound HTTP request, stores nothing, requires no authentication, shares a rate limit of 12 calls/hour/IP with grade_llms_txt, and returns a plain-text notice on limit. It also warns that the summary is model-generated and can be wrong on vague pages. This is substantial behavioral disclosure that helps the agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded. The first sentence gives the core purpose, followed by the interpretation nuance, usage trigger, and then behavioral details. Each sentence earns its place; nothing is wasted. It is not overly long for the amount of information it conveys, and it is well-structured for an agent to quickly parse.
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 a single parameter, the description is remarkably complete. It covers what the tool does, how the output should be interpreted, when to use it, its side effects (HTTP request, no storage, no auth), the rate limit, and the potential for model error. Since there is no output schema, the description adequately explains the output format (2-3 sentence summary). The annotations cover safety, and the description fills all other gaps.
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%: the only parameter, 'domain', already has a clear description ('Bare domain to read, without protocol or path, e.g. acme.com'). The description does not add any meaning beyond the schema—it merely refers to 'the public domain you pass,' which is redundant. Since the schema fully covers the parameter, 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 states a specific action (fetches a homepage), the resource (public homepage), and the output (a 2-3 sentence summary of what the company does and who it serves). It clearly distinguishes itself from siblings by emphasizing the cold-read approach and the no-outside-knowledge constraint, making the purpose 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 explicitly says 'Use when a user asks how their site, or a competitor's, reads to an AI.' This gives a clear trigger condition. It does not explicitly list exclusions or alternative tools, but the usage context is sufficiently clear, and the mention of the shared rate limit with grade_llms_txt hints at when to be mindful of usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs zRev's ROI model on one company's numbers and returns, as plain text, the projected annual impact in USD split into pipeline lift, customer acquisition cost savings and the value of hours returned to the team, followed by the model's assumptions and a link to the interactive calculator preset to the same inputs. Use when a user wants a number for their own company; all six inputs are required, so ask for any that are missing rather than guessing. The output is an estimate from a fixed model, not a forecast or a quote. Pure calculation: nothing is stored, no external calls, no authentication, no rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
| arr | Yes | Annual recurring revenue in USD, e.g. 10000000 | |
| cac | Yes | Customer acquisition cost per new customer in USD, e.g. 8000 | |
| deal_size | Yes | Average deal size in USD, e.g. 25000 | |
| team_size | Yes | Number of people on the GTM team, account executives plus SDRs, e.g. 8 | |
| monthly_leads | Yes | Qualified leads per month, e.g. 120 | |
| close_rate_pct | Yes | Close rate as a percentage, e.g. 15 for 15% |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description significantly expands on the annotations: it discloses that the operation is a pure calculation with nothing stored, no external calls, no authentication, and no rate limit. It also clarifies the output is an estimate from a fixed model, not a forecast or quote, and specifies the output format (plain text with assumptions and a calculator link). This is rich behavioral context well beyond the readOnlyHint and idempotentHint 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 dense but every sentence serves a purpose: first what it does and the output, then when to use it, then operational guidance, then exclusions, then behavioral guarantees. It is front-loaded with the most decision-relevant information and has no filler or repetition of the title.
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?
Despite lacking an output schema, the description fully specifies the return structure: plain text, annual impact in USD, split into pipeline lift, CAC savings, hours returned, assumptions, and a calculator link. It covers input requirements, use cases, and behavioral side effects, making the tool fully usable for an agent with no additional context.
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 covers 100% of the six parameters with clear examples and units, so the description doesn't need to add much per-parameter detail. The description adds useful high-level context about the six inputs being required and that missing ones should be requested, but it doesn't redefine or extend the meaning of individual parameters. This stays at the baseline expected for full schema coverage.
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 action: runs zRev's ROI model on one company's numbers and returns a projected annual impact in USD split into concrete categories. It clearly identifies the resource (ROI model) and scope ('on one company's numbers'), which distinguishes it from sibling tools like get_benchmarks or gtm_diligence_checklist. It leaves no ambiguity about what the tool does.
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 says 'Use when a user wants a number for their own company,' giving a clear use condition. It also instructs the agent to ask for missing required inputs rather than guessing, which is practical guidance. It doesn't explicitly name alternatives or when-not-to-use conditions, but it excludes forecasts and quotes implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns zRev's typical engagement results as plain text: 2x pipeline velocity, 20% lower customer acquisition cost, 10 hours back per rep per week, 60% of GTM busywork automated, results that start inside 30 days and mature by 60. The response always ends with the provenance caveat: these are typical results benchmarked against comparable AI-powered GTM implementations and they vary by stack, data quality and adoption, so present them as typical, not guaranteed. Use when a user asks what results to expect. For an estimate on a specific company's numbers use estimate_roi instead. Read-only, static content, no arguments, no authentication, no rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it states the tool returns plain text, is static content, requires no authentication, has no rate limit, and always ends with a provenance caveat. All of this aligns with the readOnlyHint, idempotentHint, and destructiveHint annotations, with no contradiction.
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 information-dense and front-loaded with the core return value. Every clause earns its place, though the caveat is somewhat long. Still, it is structured effectively and not padded.
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 tool, the description is complete: it covers what is returned, the exact content, the provenance caveat, when to use it, the alternative for specific estimates, and operational characteristics like auth and rate limits. Nothing necessary for correct invocation 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?
The tool has zero parameters, and the description explicitly states 'no arguments,' so there is nothing for the agent to infer about parameter usage. This exceeds the baseline for zero-parameter tools by making the lack of arguments explicit.
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: 'Returns zRev's typical engagement results as plain text' followed by concrete metrics. It also names the sibling alternative (estimate_roi) for a different 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?
Explicit usage guidance is provided: 'Use when a user asks what results to expect.' It also gives a clear exclusion rule and alternative: 'For an estimate on a specific company's numbers use estimate_roi instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the phases of a standard 60-day zRev engagement as plain text: what happens in each phase, what is delivered, and when first results appear. Use when a user asks how an engagement works, how long it takes, or what they would receive and when. Read-only, static content, no arguments, no authentication, no rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds 'static content' and 'no rate limit' which are useful beyond annotations. No contradictions; it complements the structured data well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The core function is front-loaded, followed by usage guidance and safety traits. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers all necessary context: what it returns, when to use it, and its operational characteristics (read-only, static, no auth/rate limit). Nothing is missing 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?
The tool has zero parameters, so the baseline is 4. The description explicitly states 'no arguments,' which is redundant with the empty schema but adds clarity for an agent that might expect parameters. No further compensation needed since there are no parameters to document.
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 phases of a standard 60-day zRev engagement, including what happens, what is delivered, and when first results appear. This is a specific verb (Returns) and resource (phases) that distinguishes it from sibling tools focused on other topics like about_zrev or estimate_roi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when a user asks how an engagement works, how long it takes, or what they would receive and when. It also adds context about being read-only, static, with no auth or rate limit, which helps an agent decide to use it without unnecessary concerns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches https:///llms.txt (the file that tells AI systems what a site contains) and grades it with seven deterministic checks. Returns a 0 to 100 score and the pass or miss result of each check as plain text. If the site has no llms.txt the response says so and links to zRev's free generator. Use when a user asks whether a site is readable by AI assistants or wants their llms.txt reviewed. Makes one outbound HTTP request to the public domain you pass; stores nothing about it. No authentication. Shares a limit of 12 calls per hour per IP address with cold_read, and returns a plain-text notice when that limit is reached.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare domain to grade, without protocol or path, e.g. acme.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations mark it readOnly and idempotent, the description goes further, disclosing it makes one outbound HTTP request, stores nothing, requires no authentication, and shares a rate limit. This adds value beyond annotations and gives the agent a clear safety and side-effect profile.
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 paragraph with multiple sentences, but all sentences carry important information. It is front-loaded with the main action and result, and the rate limit follows. Slightly verbose but efficient for the information conveyed.
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 tool with no output schema, the description covers the input, behavior, edge cases (missing file), and limitations. It lacks nothing an agent needs to call it correctly, considering the annotations cover safety.
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 description does not elaborate on the domain parameter beyond what the schema states. The description emphasizes bare domain format implicitly through the example, but the schema already covers that. 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 clearly states the tool fetches llms.txt from a domain and grades it with seven deterministic checks, returning a score and pass/miss results. It distinctly differentiates from siblings by specifying the exact file and grading function, which is not shared by any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: when a user asks if a site is AI-readable or wants llms.txt reviewed. It also implies when not to use by focusing on llms.txt, and mentions sharing a rate limit with cold_read, which helps the agent choose among tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns zRev's go-to-market due diligence checklist for investors and acquirers: 47 questions across ten dimensions, each with the data-room artifact that answers it and the red flag to watch for. Call with no arguments to get the list of ten dimensions; call with a dimension number from 1 to 10, or a keyword such as churn, pipeline or marketing, to get that dimension's questions in full. Use when a user is assessing a company's revenue engine before an investment or acquisition. Read-only reference content, no authentication, no rate limit.
| Name | Required | Description | Default |
|---|---|---|---|
| dimension | No | Optional. A dimension number from 1 to 10, or a keyword such as 'churn', 'pipeline' or 'marketing'. Omit to list the ten dimensions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds value beyond this by stating 'no authentication, no rate limit' and explaining the conditional behavior for no-argument versus dimension-argument calls. It does not contradict annotations, and it provides useful operational 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 tight and front-loaded: it states the return value, then call variants, then use case, then operational constraints. Every sentence contributes distinct information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter read-only tool with no output schema, the description is complete: it explains what happens with no arguments, what happens with a dimension number or keyword, when to use it, and that it requires no auth or rate limiting. An agent has everything needed 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 already covers the single optional dimension parameter at 100% with examples and the omit behavior, so the description does not add much semantic value beyond what schema provides. The description's call-mode explanation mirrors the schema rather than extending it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and names the exact resource: zRev's go-to-market due diligence checklist with 47 questions across ten dimensions, including data-room artifacts and red flags. This clearly distinguishes it from sibling tools like get_benchmarks or about_zrev, which address different purposes.
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 guidance on when to use the tool ('when a user is assessing a company's revenue engine before an investment or acquisition') and also explains the two calling modes. It does not explicitly name alternative tools or when not to use it, but the context is clear enough that an agent can route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records an email address, with optional name, company and note, so that zRev's founder can reach out, and returns a plain-text confirmation. This is the only tool here that writes data: it creates one lead record on zRev's side and triggers no email to the address given. Use only when the human you are assisting has explicitly asked to be contacted by zRev; never call it speculatively or with an address the user has not given you for this purpose. Submitting the same email again updates the existing record rather than creating a duplicate. No authentication. Rate-limited per IP address.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional. The human's name | |
| note | No | Optional. What they want to talk about, in their words | |
| Yes | The human's email address, given by them for this purpose | ||
| company | No | Optional. Their company name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds substantial context beyond these: it 'triggers no email to the address given,' 'updates the existing record rather than creating a duplicate' (reinforcing idempotency), 'No authentication. Rate-limited per IP address,' and notes it returns a plain-text confirmation. No contradiction with annotations; it enriches them.
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 on the longer side (5 sentences) but every sentence earns its place: purpose, uniqueness, usage constraint, idempotency, and auth/rate-limit. It is front-loaded with the core purpose first, and the structure flows logically from what → why → when → behavioral caveats. Slightly verbose but appropriately dense.
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 write operation with no output schema, the description covers everything an agent needs: purpose, what it writes, what it returns (plain-text confirmation), idempotency, auth requirements, rate limits, and the consent gate. The annotations carry the safety profile and the description fills the return-value gap since there's no output schema. Nothing essential 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%, so the baseline is 3. The schema already documents all four parameters clearly (email is required, name/company/note optional, with descriptions like 'given by them for this purpose'). The description adds marginal value by grouping them as 'optional name, company and note' and confirming email as the core input, but does not go beyond what the schema provides.
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 ('Records'), a specific resource (email address → lead record on zRev's side), and the purpose ('so that zRev's founder can reach out'). It also explicitly differentiates from siblings by declaring 'This is the only tool here that writes data,' so an agent can immediately distinguish it from book_call, estimate_roi, etc.
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 when-to-use guidance: 'Use only when the human you are assisting has explicitly asked to be contacted by zRev' and clear exclusions: 'never call it speculatively or with an address the user has not given you for this purpose.' This is the strongest form of usage guidance — a positive condition plus a negative prohibition.
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.
about_zrevbook_callcold_readestimate_roiget_benchmarksget_engagement_timelinegrade_llms_txtgtm_diligence_checklistleave_contactFree buyer-thread finder, Reddit demand board + full GTM agent tools; try with no key.
AI-native GTM OS for B2B SaaS — account health, pipeline, renewals, territories, and benchmarks.
Tools for Go-to-market teams creating sales materials, product demos, and deal rooms for customers.
B2B GTM stack intelligence: search ~400 tools, compare vendors, find overlaps, audit SaaS spend.
Add one secure layer between your agents and this server.
