SalesBook by MaxedS: B2B Startup Rankings & Enterprise Vendor Discovery

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

The description describes a public write ('Sign the public ... Wall', agents 'check in' and publish a message), yet annotations declare readOnlyHint=true and openWorldHint=false for a tool that posts to an external public website. This is a direct contradiction of the structured safety/profile hints, so the description cannot be credited for behavioral disclosure.

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

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

Two sentences, front-loaded with the action and target, and no obvious padding. The marketing flourishes ('Unmasked Bot Wall', 'unmask spoofed bots') are minor noise but do not obscure the action.

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?

It explains the server-side telemetry pairing, which is useful context, but with no output schema and 6 parameters it never says what the caller gets back (confirmation, public URL, verification verdict) or whether the submission is reversible. Adequate but incomplete for a publishing operation.

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% across all 6 properties, so the schema already carries the parameter meaning. The description restates the concept ('claimed identity, model, mission, and a short message') but adds no format, length, or validation guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: check in / sign the 'MaxedS Agent Mailbox & Unmasked Bot Wall', with the URL. It is plainly distinct from the SalesBook data siblings (search_startups, compare_vendors, etc.), though the branding-heavy phrasing makes the core action slightly less crisp than a 5 would require.

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 identifies the audience ('Visiting AI assistants, autonomous agents, and MCP clients can check in'), which implies when the tool applies, but gives no explicit trigger, no when-not-to-use condition, and no relationship to the sibling SalesBook tools that would tell an agent when in its workflow to check in.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. With no output schema, the description usefully discloses the return payload (status, rank, evidence grade, gaps with fixes, correction reporting) and adds the policy note that ranks are not purchasable. It stops short of auth or rate-limit details, but adds real value beyond the 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 opening question front-loads purpose and the return-value sentence follows immediately. It is slightly list-heavy, and the closing 'Ranks are never for sale' line is more positioning than instruction, but it is short and nothing is buried.

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

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

For a single-parameter read tool with no output schema, the description supplies what the schema cannot: a full inventory of returned fields and the remediation angle. The main omission is any sense of result size or what happens when a company is not found, which the annotation set does not cover.

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

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

Schema description coverage is 100% and the single parameter already documents 'Company name or website' with an example. The description's 'Give a company name or website' restates that without adding format or matching semantics, so the baseline 3 for schema-heavy tools 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 concrete verb (check) and resource (a company's SalesBook listing) and enumerates the dimensions returned: listing status, sector and rank, evidence grade, agent-readiness, and ranking gaps. It reads as a multi-dimensional audit, which implicitly separates it from narrower siblings like get_ranking or get_profile, but it never names or contrasts those siblings explicitly.

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

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

It gives an audience ('For founders and vendors') and an input rule ('Give a company name or website'), which implies when the tool applies. However, there is no explicit when-not guidance and no routing to alternatives such as get_ranking for leaderboards or get_profile for other detail, leaving the agent to infer boundaries.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context by naming the comparison dimensions: buyer-fit scores, verified commercial deal claims (T1-T4), pilot mechanics, and agent readiness, plus that results are unsponsored.

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, naming the comparison scope first and then the evaluated dimensions. Every sentence contributes to tool selection.

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 comparison tool with no output schema, the description gives enough context about inputs and comparison criteria to select and invoke it correctly. It does not explain the exact return structure or how unknown vendors are handled, but the annotations and schema cover the safety and parameter essentials.

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

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

Schema description coverage is 100%, so both vendors and buyer_context are already documented in the schema. The description's examples and 2-to-5 range reinforce the schema but add no new syntax or format details, making the baseline 3 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?

States a specific verb and resource: side-by-side comparison of 2 to 5 B2B AI startups. The scope and comparison dimensions distinguish it from single-vendor profile, ranking, or search tools without needing to open the schema.

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

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

Clearly indicates the tool is for comparing 2 to 5 vendors and gives examples like ['Glean', 'Notion']. It does not explicitly name sibling alternatives such as find_alternatives or get_profile, so there is no when-not guidance, but the use context is clear.

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?

Annotations already disclose readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral value by naming the ranking criteria (Fortune 500 buyer fit, verified enterprise traction, feature overlap), which tells the agent how results are ordered, but says nothing about result count, freshness, or coverage 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?

Three sentences, front-loaded with the core action, then positioning, then ranking methodology. The middle sentence is marketing copy that carries less operational weight, but the whole block is short and nothing is buried.

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

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

With no output schema, the description partially compensates by stating the ranking dimensions, which implies a ranked list of alternatives. It omits any statement about how many results come back by default or what fields each alternative carries, which is the main remaining gap for a three-parameter lookup tool.

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

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

Schema description coverage is 67%: 'company' and 'sector' are documented in the schema while 'limit' is not. The description adds an illustrative example of valid vendor inputs (Glean, Harvey) but never mentions the sector filter, the limit cap, or the fact that the schema's sector enum lists only five of six allowed values (it omits 'agentic'), so it does not close the remaining gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Find top enterprise-ready alternatives & competitors to any B2B tech vendor') and scopes it to B2B tech, which distinguishes it from generic search_startups. However, it never names or contrasts itself with the closest sibling, compare_vendors, leaving the agent to infer the boundary between 'find alternatives' and 'compare 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?

The only contextual framing is a competitive positioning claim ('Free alternative to CB Insights market maps & G2 grids'), which describes the product, not when an agent should call this tool instead of compare_vendors, search_startups, or find_prospects. No preconditions, exclusions, or alternative-routing guidance is 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?

Annotations already declare a read-only, non-destructive, non-open-world operation, and the description stays consistent while adding real context: the fit logic is 'experimental' and uses 'public, company-level signals only,' and the sector filter is 'strict.' Those caveats materially change how an agent should interpret and present results. It does not discuss result caps beyond limit=10 or latency/pagination, but no output schema exists so the 'reason for each' note partly covers returns.

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?

Purpose is front-loaded and nearly every clause carries operational information (defaults, strictness, opt-in routing). The middle sentence is dense and parenthetical-heavy ('innovation or pilot desks, dated startup purchases, supplier intake, readiness'), which slows parsing, but no sentence is 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 5-parameter, all-optional, read-only discovery tool with no output schema, the description covers intent, defaults, buyer-type routing, and interpretation caveats. Minor gaps remain: it never says what happens when no company or what_you_sell is provided, and 'if listed' is an unexplained conditional.

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 80%, so the baseline is 3, and the description earns above that by adding behavior the schema does not convey: sector filtering is strict, hospital/university buyers surface only via sector or buyer_type, buyer_type=startup targets SalesBook companies, and company is optional if what_you_sell is supplied. These mappings clarify the interaction between parameters rather than restating their definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ('the 10 best-fit buyers for a company, with the reason for each') plus the intended caller ('For startups looking for customers'), which immediately separates it from siblings such as search_startups or find_alternatives. Default ranking basis and default buyer population are spelled out, so an agent knows exactly what it will get back.

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?

Gives clear triggering context (startups looking for customers) and explicit routing to a sibling: 'To be considered for an introduction, use opt_in_for_intros.' It also states when hospital systems and universities appear ('only when you ask') versus the default enterprise set. It stops short of distinguishing this from other lookup siblings like find_alternatives or compare_vendors.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real context beyond that — the enumerated signal sources and the fact that each item carries a source link and date seen — but says nothing about result volume, ranking, or what happens when query matches nothing.

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 core deliverable is front-loaded in the first two sentences, and the long source enumeration, while dense, maps to the signal_type enum and therefore earns its place. Slightly over-stuffed in one sentence but no filler.

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

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

There is no output schema, so the description carries the burden of describing returns — it does so by naming the macro windows and the signal categories with their source/date provenance. Combined with readOnly annotations and 80% schema coverage, an agent has enough to call it correctly; only ranking/pagination behavior is unstated.

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 80%, so the baseline is 3, but the description meaningfully clarifies the `query` parameter's dual role (a company name triggers the per-company signal block) and that window_type=public_signal requires a query — information not present in the schema 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 states a specific resource (enterprise buying windows and F500 pilot programs) and enumerates what is returned: macro replacement cycles (SAP ECC 2027, VMware cliffs, CMS mandates) plus dated public buying signals. It is clearly distinct from find_prospects or search_startups, though it never names a sibling to reinforce the boundary.

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

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

It gives implied usage guidance ('Name a company in `query` to also get its dated public buying signals', 'Company-level only', and the note that public_signal needs a query), but there is no explicit when-to-use-this-vs-an-alternative statement against the prospect/sourcing 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds that the methodology is versioned and that every ranking cites its version, which is useful behavioral context. However, it doesn't disclose return format, size, or any rate limits. With annotations covering safety, this is 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?

The description is two concise sentences that front-load the resource and its contents. Every word earns its place, and the versioning note is a valuable addition without 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?

Given the tool has no parameters, no output schema, and clear annotations, the description provides sufficient context: what the methodology contains and its versioned nature. It doesn't need to explain return values. However, it could mention how to use the version information (e.g., referencing methodology versions in other calls) to be fully 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 there is no parameter semantics to address. The baseline for zero parameters is 4. The description correctly focuses on the resource rather than non-existent parameters.

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 resource ('ranking methodology') and enumerates its contents (weights, tombstone tier definitions, confidence labels, honesty guarantees). It is clear what the tool retrieves. However, it doesn't explicitly differentiate from siblings like get_tombstones or get_ranking, which also deal with ranking-related data.

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?

No explicit when-to-use or when-not-to-use guidance is provided. The description implies this is for understanding ranking mechanics and versioning, but it doesn't state when an agent should call this versus get_ranking or get_tombstones. The usage is implied by the content description.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds provenance context (unsponsored, transparent sources, confidence ratings), but says nothing about freshness, coverage limits, or behavior on an unknown startup_id, which is the remaining gap.

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 first sentence is dense but front-loads the returned fields well. The second sentence ('Unsponsored vendor intelligence dossier with transparent sources and confidence ratings') largely restates the 'evidence-graded' and 'verified' framing already implied, adding promotional padding rather than new 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?

With no output schema, the description usefully enumerates what the dossier contains, which is the key information an agent needs before calling. It is essentially complete for a single-id read tool, lacking only error/miss behavior for an invalid startup_id.

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 is a single parameter with 100% schema description coverage, and the schema already explains that startup_id comes from search_startups or get_ranking. The description adds no format, constraint, or sourcing detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (a startup dossier) and enumerates the returned content areas: problem, solution, stage, team, buyer-fit score, and verified enterprise customers. It is clearly distinct from search_startups or get_ranking by being a single-entity retrieval, though it never uses an explicit retrieval verb like 'fetch' or 'returns'.

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

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

There is no statement of when to call this versus siblings such as search_startups, compare_vendors, or check_listing. The only routing hint ('from search_startups or get_ranking') lives in the parameter schema, not the description, so the description itself offers no usage guidance or exclusions.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the data contains (verified Fortune 500 buyer-fit scores, methodology), but says nothing about return format, result size, or whether rankings are paginated.

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 front-loaded sentence that leads with the verb and core resource, with no redundancy. The 'Sourced alternative to PitchBook & CB Insights' clause is mild marketing padding rather than operational information, but overall it is tight.

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 read tool with no output schema and full annotation coverage, the description conveys purpose, scope, and the shape of the returned content adequately. Missing only the meaning of 'evidence-graded' and any indication of result size, which are minor given the tool's simplicity.

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

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

Schema description coverage is 50% (only 'period' is documented, as 'Ranking period id'). The description names sectors and period as filters, adding some meaning, but it lists only 5 of the 6 enum values (omitting 'agentic') and gives no period format or semantics beyond the schema's terse string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Get ... Top-100 B2B startup rankings by sector ... and period') with concrete scoping (evidence-graded, buyer-fit scores). It differentiates from external products (PitchBook, CB Insights) but never distinguishes itself from sibling tools like get_profile, search_startups, or compare_vendors, which is the more relevant comparison for an agent.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite a rich sibling set (get_methodology, search_startups, get_profile). The agent must infer that this is the entry point for sector-level ranking data rather than reading 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine data-semantics context beyond annotations: the T1-T4 grading scale, the claimed-unverified default confidence, and the corroborated marking for F500-confirmed records. It says nothing about ordering, pagination, or result limits, so it is additive 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?

A single sentence, front-loaded with the resource ('Deal tombstones for a startup') followed by a colon and the payload of useful definitional detail. No wasted clauses, though the density of domain terms makes it slightly heavy for one sentence.

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?

There is no output schema, so the description should carry more of the return-value burden than it does. It conveys the semantic content of records (dating, sourcing, T1-T4 grade, confidence, corroborated flag) but says nothing about the shape, ordering, or volume of the response, and gives no usage guidance for a single-parameter lookup tool.

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

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

Schema coverage is 100% and the single parameter startup_id is documented in the schema with its source ('from search_startups or get_ranking'). The description adds no parameter-level detail at all, so the baseline of 3 for high schema coverage applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (deal tombstones for a startup) and defines it concretely: 'dated, sourced public claims of enterprise commercial wins, graded T1 to T4.' That is far more than restating the name, and the sibling tools (get_methodology, get_profile, get_ranking, search_startups) are clearly different resources. It stops short of an explicit verb and never states how it differs from siblings, so it is clear but not maximally discriminating.

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

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

Usage is only implied: the description tells the agent what tombstones contain, so an agent can infer it should call this when it wants evidence of enterprise wins for a known startup. There is no explicit when-to-use, when-not-to-use, or routing to an alternative sibling, and no stated prerequisites.

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?

Annotations only say this is a non-destructive, closed-world write; the description goes well beyond that by disclosing the mutual-consent model, the threshold gating ('asks the buyer only once enough strong startups have opted in'), and the consent rule for sharing details. Missing only what happens after opting in (reversibility, opt-out).

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

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

Three sentences, front-loaded with the audience qualifier and with the key constraint stated before the explanatory clause. Some rhetorical phrasing ('Mutual or nothing') is slightly padded but still earns its place by conveying the consent model.

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 does the right work: it defines purpose, the consent/gating behavior, and the caller's prerequisite. A competent agent has enough to call it correctly, though a note on what the caller receives after opting in would close the last 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?

Schema coverage is 100%, so all four parameters are already documented including the note, buyers, company, and work_email fields. The description's email-domain guidance merely reinforces an existing schema description, which is the correct baseline-3 case.

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?

Concrete verb and resource: opting a startup in to be considered when MaxedS arranges a meeting with an enterprise buyer. An agent can understand exactly what the tool does. It does not, however, explicitly distinguish itself from siblings like find_prospects or search_startups in the description text.

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?

'For startups' scopes the audience and 'Use a work email on your company's domain' gives a prerequisite, so usage is implied. There is no when-not condition and no sibling alternative named, leaving the agent to infer that this is the registration half of the find_prospects flow.

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 readOnlyHint=false, destructiveHint=false and openWorldHint=false already declared, the description adds the key behavioral fact the annotations cannot convey: reports do not mutate anything automatically but enter a human review queue against public sources. It stops short of disclosing turnaround, auth requirements, or what the submitter receives back.

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, zero filler, with the purpose and examples front-loaded and the review-process constraint following immediately. The final sentence on source URLs earns its place as actionable submission 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?

For a 5-parameter submission tool with no output schema, the description covers what to report and what happens next (manual review, no automatic change), which is what an agent needs to decide and invoke. It could say more about what the caller gets back or expected review timing, but 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 description coverage is 100%, so all five parameters are already documented in the schema, which sets the baseline at 3. The description only adds one piece of guidance, 'include a source URL whenever you can', which reinforces the source_url parameter but adds no syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (report) and resource (an error in SalesBook) and enumerates the concrete cases: wrong fact, outdated claim, missing deal, company that should not be listed. This distinguishes it clearly from sibling mutation tools like update_listing, which the 'nothing changes automatically' clause implicitly contrasts against.

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?

Gives a clear context for use (something wrong in a listing) and explains the downstream process: MaxedS reviews against public sources and corrects the listing. It also advises including a source URL. However, it never explicitly names an alternative tool (e.g. update_listing for direct edits) or states when not to use this tool.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered, lowering the bar. The description adds the return content ('rank, score, and verified commercial proof') and the 'evidence-graded' nature, but omits result limits, pagination, or corpus scope behavior beyond the sector list.

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?

Well front-loaded: purpose, then alternatives, then return values. The lengthy parenthetical enumerating agentic commerce subdomains ('agent payments, identity, inboxes, tools, directories...') is mildly bloated but does not obscure the core message.

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 usefully states what is returned (rank, score, verified commercial proof), closing the biggest gap. It is reasonably complete for a search tool, though it omits any note on the limit cap or result volume.

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 67%; query and sector already carry descriptions, and limit is undocumented in both places. The description enumerates the covered sectors, which loosely complements the sector enum, but adds no syntax or formatting detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Search ... B2B startup rankings') and positions itself against external products (CB Insights, PitchBook, G2). It does not distinguish itself from internal siblings like get_ranking or find_prospects, which an agent must still disambiguate on its own.

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 framing as an 'alternative to CB Insights, PitchBook, and G2 for finding enterprise-ready tech vendors' implies a discovery use case, but there is no explicit when-to-use or when-not guidance relative to the many sibling tools. Usage is inferred rather than stated.

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?

Annotations only declare non-read-only, non-destructive, open-world. The description adds the real behavioral substance: an email sign-in link is sent to the work address on the company domain, confirmation happens on maxeds.org, the change 'shows immediately, marked as updated by the company', and rank-affecting fields are routed to review. That is meaningful context well beyond the annotation set.

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 the actor and the action, then the auth/confirmation flow and the review exception. Dense but each clause carries information; the field list is long but scopes the tool's blast radius.

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 still explains the outcome an agent should expect (immediate visibility, 'updated by the company' attribution) and the auth prerequisite. Nothing needed to invoke this mutation correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the mutable field set in human-readable terms (which loosely maps to the enum), but adds nothing about source_url or the work_email verification mechanics beyond what the schema already says.

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?

Specific verb+resource ('change a fact on your own company's listing') with an explicit enumeration of the mutable fields. It also draws the boundary against the sibling report_correction, so an agent can distinguish the two without opening either schema.

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

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

States the audience ('for founders and company staff'), the ownership precondition ('your own company's listing'), and an explicit exclusion with the alternative: rank-affecting deals/customers/results 'go through review (use report_correction)'. When-to-use and when-not-to-use are both covered.

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