venumark

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It alludes to creating a signed receipt (indicating a write operation) but does not explicitly state whether this tool mutates data, what permissions are needed, or if the decision is reversible. This is insufficient for a mutation tool description.

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 very concise with two sentences, no filler, and front-loaded with the tool's primary function. Every sentence adds value.

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 no output schema and no annotations, the description communicates the tool's purpose and key outputs (decision, reason, evidence, documents, receipt) but lacks details on output structure or exactly what 'evidence' and 'reason codes' look like. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds context about license_number vs vendor_id and mentions event_type relevance to document collection, but does not elaborate on parameter formats or constraints beyond the schema. No significant added value.

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 makes a booking decision for a Florida food vendor with specific outcomes (CLEAR, CONDITIONAL, REVIEW, DECLINE) and includes detailed outputs (reason codes, evidence, documents, receipt). It also distinguishes itself by recommending search_vendors for when no license number is available.

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 this is the recommended vetting tool and directs agents to use search_vendors first only when lacking a license number, providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral transparency. It accurately describes the return format as a document with id, title, text, url, metadata. However, it does not disclose potential side effects, authentication requirements, or error handling, which is a gap for a read-only operation.

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, concise sentence that efficiently conveys the tool's purpose and return format. While it could be slightly restructured for clarity, there is no unnecessary verbosity.

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 fetch tool, the description covers the key aspects: the input requirement (vendor id from search) and the output structure (document with listed fields). However, it lacks details on error handling or edge cases, but given no output schema, it provides adequate context for a basic tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for the 'id' parameter. The description adds value by specifying that the id comes 'from search', implying it's a UUID from search results. This provides context beyond the schema's basic description.

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 'fetch' is an alias of 'get_scorecard' and returns the full public scorecard as a document with specified fields. The verb 'fetch' and resource 'scorecard' are specific, though it doesn't explicitly differentiate from 'get_scorecard' beyond noting it's for ChatGPT Deep Research connectors.

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 mentions that the tool takes a vendor id from search, implying a prerequisite of having searched first. However, it does not provide explicit guidance on when to use this alias versus the sibling 'get_scorecard' tool, nor does it state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the output format (markdown) and the parameter values, but does not mention whether the tool is read-only, any authorization requirements, or performance characteristics. The behavioral transparency is adequate but not comprehensive.

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 extremely concise: two sentences that immediately state the tool's purpose and then list the slug options with their contexts. Every word serves a purpose, making it easy for an agent to parse quickly.

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 tool with one enum parameter and no nested objects or output schema, the description provides complete context: what the tool does, how to use it (the slug options), and what to expect (markdown output). No additional information is needed.

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?

Although schema coverage is 0% (the description does not separately describe the parameter), the description fully explains the meaning of each enum value by listing the associated context (e.g., 'breweries, HOAs, churches' for 'florida-food-truck-night'). This adds significant semantic value beyond the raw enum names in 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 clearly states the tool returns a 'Florida organizer checklist as markdown' and lists the specific slugs with their contexts. The verb is implied (retrieves) and the resource is a specific checklist, differentiating it from sibling tools like 'get_event' or 'get_platform_info'.

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 contextual usage guidance by mapping each slug to its associated venues (e.g., 'florida-food-truck-night' for breweries, HOAs, churches). While it doesn't explicitly state when not to use or name alternatives, the context is clear enough for an agent to select the appropriate slug based on the scenario.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It accurately states that only public details are returned (dates, venue, etc.), implying a read-only operation. It does not mention authentication, rate limits, or potential errors, but the behavioral trait is clear.

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 extremely concise, consisting of two sentences with no superfluous words. The first sentence front-loads the tool's purpose and returned fields, and the second provides usage guidance.

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 the tool's simplicity (one parameter, no output schema, no nested objects), the description covers all necessary information: what it does, what it returns, and how to obtain the input. It is complete for an agent to select and invoke 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%, so the parameter 'slug' is already documented. The description adds value by specifying where to obtain the slug (list_open_events or URL), providing context 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 clearly states the tool retrieves public details of one published event, listing specific fields. It distinguishes from siblings like list_open_events (which lists events) and get_signup_link (which provides a signup link) by specifying the scope and data returned.

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 explicit context on when to use the tool: after obtaining a slug from list_open_events or from a URL. It gives a clear alternative source for the slug but does not mention when not to use this tool or provide other exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates that the tool is informational and returns platform details, implying no destructive side effects. However, it does not mention authentication requirements or data source, which would be helpful. The description is still fairly transparent about the non-mutating nature of the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise, consisting of two sentences. The first sentence lists the information provided, and the second gives clear usage guidance. Every sentence adds value without redundancy, and the most critical 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?

The description adequately explains what the tool does and when to use it, covering the complexity of the tool (no parameters, no output schema). While it does not detail the output format, the listed topics (platform identity, workflow, pricing, tier fit) provide enough context for the agent to understand the return value.

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 description does not need to elaborate on parameters. According to scoring guidelines, zero parameters warrants a baseline score of 4. The description adds no parameter information because none are needed.

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 provides information about VenuMark's identity, workflow, pricing tiers, and tier fit. It uses the specific verb 'get' with the resource 'platform info' and distinguishes itself from sibling tools like 'get_event' or 'get_checklist' by focusing on the platform itself rather than specific events or entities.

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 advises when to use the tool: when someone asks about running vendor applications, pricing, or whether VenuMark fits their event. While it does not explicitly state when not to use it, the usage context is clear and sufficient for the agent to make appropriate selections among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description carries full burden. It explains the output components and grade meanings (A-F, HOLD, Ungraded, Withheld). It does not mention side effects or auth needs, but for a read-only lookup this is acceptable.

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. Key information is front-loaded, followed by a clear explanation of grade values.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description thoroughly explains return values. Parameter count is low and all are optional. The description provides enough context for an agent to use the tool 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 descriptions. The description adds value by explaining where vendor_id comes from and clarifying license_number format, which is 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 clearly states it retrieves a vendor's public compliance record with specific fields (letter grade, license status, inspection recency, record shape). It distinguishes from siblings like search_vendors by focusing on a single vendor's compliance details.

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 usage context: look up by vendor_id from search_vendors or directly by license_number. It explains the purpose is to vet a vendor in one call but does not explicitly state when not to use or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses key behaviors: the tool only generates a link, signup and payment occur via Stripe in the browser afterward, and vendor accounts are free forever. With no annotations provided, this goes beyond the schema by explaining the post-invocation flow and non-destructive nature.

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 at three sentences, with the core purpose front-loaded. Every sentence adds necessary 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?

Given no output schema and no annotations, the description covers all critical aspects: what the tool returns (a link), the parameter semantics, the user flow (open in browser, Stripe checkout), and role-specific outcomes. No significant gaps remain for an agent to use this tool 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?

Despite 100% schema coverage, the description enriches each parameter: it explains that 'venue' is for organizers running applications, 'vendor' for food trucks (free), and that 'tier' and 'cadence' only apply to venues for preselecting paid plans. This adds meaningful context beyond the enum labels.

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's purpose: generating a direct VenuMark signup link for the human to open in their browser. It specifies the two roles ('venue' and 'vendor') and how optional parameters preselect plan details. No sibling tool appears to duplicate this function, making it well-differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when a signup link is needed) but does not explicitly state when not to use it or mention alternative tools for related tasks. It provides context that the link is for browser use, not programmatic signup, which is helpful but lacks direct comparison to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes output (limiting factors, actions, resources, link) and grade categories. As no annotations exist, it carries full burden; it is clear about being a lookup tool with no side effects implied, though it does not explicitly state idempotency.

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 efficiently cover purpose, audience, usage, alternatives, and details. No wasted words.

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?

Tool is simple with 0 required params, no output schema. Description covers all: purpose, target, lookup methods, grade system, and links to sibling. Fully adequate.

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 description adds meaning: explains license_number format variations (with/without prefix) and that vendor_id comes from search_vendors, enhancing schema info.

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 specifies the tool is for Florida food truck/caterers checking their own VMScore, listing what limits it and what to do. It clearly distinguishes from sibling 'decide_vendor', which is for organizers vetting vendors.

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 target users and when not to use: 'Organizers vetting a vendor for booking should use decide_vendor instead.' Also provides lookup methods with examples.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes output fields (deadline, documents, apply_url) but does not declare read-only behavior or other side effects. With no annotations, the description carries the burden and is minimally adequate.

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?

Single sentence covering action, scope, filter, and output details. No extra words, but could be slightly more structured with bullet points for output fields.

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 list tool with one optional parameter, the description explains the scope and result contents. Lacks pagination info but that is acceptable given the simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter 'city', and the description adds essentially the same example as the schema. 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?

Clearly states the tool lists Florida events from VenuMark that accept food vendor applications, with an optional city filter. This distinguishes it from siblings like get_event or search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for finding open events accepting applications but does not explicitly state when to use or not use it, nor contrasts with alternatives like search.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the output shape (id, title, url) and instructs to use fetch for full records. However, it lacks disclosure of authentication needs or rate limits, but for a read-only search this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste. The description is front-loaded with the alias and purpose, then provides output details and a logical next step. 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 simple search tool with one parameter and no output schema, the description covers what is returned, how to use the result (id for fetch), and the domain (Florida food vendors). No gaps given the low complexity.

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 parameter description already details what the query can be (business name, license number, or Florida city). The description adds that results are Florida food vendors and includes output fields, providing marginal value 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 clearly states it is an alias of search_vendors and returns matching Florida food vendors with id, title, and url. It differentiates from siblings by specifying usage for ChatGPT Deep Research connectors, though the purpose could be even clearer by explicitly stating it is a lightweight search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates it is an alias for a specific context (ChatGPT Deep Research), but does not explicitly state when to use this over search_vendors or when not to use it. No alternatives or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the data source (19,000+ DBPR records), license number format examples, detailed grade definitions (including HOLD, Ungraded, Withheld), and the return fields (license status, grade, scorecard link). It does not mention rate limits or authentication but adequately describes behavioral traits for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is about 80 words, front-loaded with the main purpose, and lists key details efficiently. It is structured in a logical flow from general purpose to specific filters and returns. Slightly verbose with the grade list, but overall concise.

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 no output schema, the description explains return fields (license status, grade, scorecard link) adequately. It covers all input parameters contextually, including license number flexibility and grade definitions. The tool is moderately complex with 5 optional parameters, and the description provides sufficient context without 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?

The input schema has 100% coverage, so baseline is 3. The description adds value by explaining license number formats (MFD and plain numeric), the optionality of query when city is given, and expanding on grade enum values (including Ungraded and Withheld not in the schema enum). This goes beyond 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?

The description clearly states it searches for licensed Florida food trucks and caterers from official DBPR records, specifying match fields like business name, prior names, license number formats, and city. It also lists optional filters and output fields, distinguishing it from generic sibling tools like 'search' and 'get_scorecard'.

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 usage via its specificity but does not explicitly state when to use this tool versus alternatives (e.g., 'search' or 'get_scorecard'). No when-not-to-use guidance is provided, leaving the agent to infer from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description adds behavioral context (founder replies by email same day) but does not disclose potential side effects, error handling, or rate limits. Adequate but not rich.

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, no wasted words. Efficient and well-structured.

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 no output schema, the description explains the outcome (founder replies). Handles the submission scenario well. Could mention required fields explicitly, but overall 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?

Schema description coverage is 100% (all 6 parameters have descriptions). The tool description does not add parameter details beyond what the schema provides, so 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 sends a contact request to the VenuMark founder for setup help, demos, etc. It distinguishes from sibling tools (e.g., fetch, search) by its submission action, though no explicit comparison is made.

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 'Only call after the user has explicitly confirmed the exact details to send,' providing a clear precondition. Also mentions the founder replies by email, but lacks when-not-to-use or alternative tool guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.