Private SuperIntelligence

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

Annotations declare readOnlyHint=false, so the agent knows persistence is possible; the description goes well beyond that by defining the exact consent gate that triggers storage and confirming that without consent nothing is stored. It also constrains framing ('never tell the person their data was stolen or breached'), which is behavioral guidance annotations cannot carry. The idempotentHint matches the described scoring-and-save flow.

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 dense sentences: outcome first, then the consent/storage workflow, then the framing constraint. Every clause carries information and the most important content (what it returns, what it saves) is front-loaded. It is on the long side for a tool description, but nothing is redundant.

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 an output schema present, the description needn't detail return values, yet it still previews the result shape. It fully covers the consent/privacy contract, the persistence condition, and the framing rules for a tool that both computes and conditionally writes — nothing an agent needs to invoke it 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 coverage is 75%, and the description reinforces the meaning that matters most: email/company exist to save the result for a follow-up from Alex Morris, and userConfirmed is the agreement flag authorizing that send. This clarifies the interdependent, all-or-nothing nature of the three optional parameters better than the schema's per-field descriptions do. Minor details of the nested answers object remain schema-only.

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?

It names a specific verb and resource ('Scores the person's answers to the AI data exposure check') and enumerates the outputs: exposure level, 2-4 reasons with policy sources, a recommendation, and a book_private_call URL. This is far more than a restated title. It stops short of a 5 because it never explicitly positions itself against the obvious sibling get_ai_exposure_questions, leaving the ordering of that pair to inference.

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 concrete operational context: ask for work email and company first, obtain agreement, then pass email, company and userConfirmed:true; otherwise nothing is stored. It also states presentation rules (editorial assessment of exposure/retention; never claim data was stolen). It lacks explicit when-to-use-vs-alternatives routing among siblings such as get_ai_exposure_questions or book_private_call.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the genuinely non-obvious trait that despite the name it performs no booking and merely yields a link, plus the open-world nature of an external scheduling destination; it stops short of saying whether the link is reusable or expiring.

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 tight sentences, zero padding, with the surprising fact (it does not book anything) front-loaded in the second sentence right where it matters. Every clause earns its place by naming the contact, topic, and the correct follow-up 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?

With an output schema present, return-value details need not be explained, and the annotations cover the safety/idempotency profile. For a zero-parameter read operation, the description supplies everything an agent needs: what it returns, who it concerns, and how to use the result.

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 takes zero parameters, so there is nothing for the description to clarify and the schema is fully self-describing. Baseline for a no-parameter tool.

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

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

States a specific verb (returns a link) and the exact resource/person (booking link for a private call with a named CEO), including the topic. Critically, it preempts the misleading name by stating it does not actually book, so an agent can distinguish this from an action tool without opening 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?

Gives clear operational guidance: hand the link to the person so they choose a time, and explicitly warns that no booking occurs. It does not name sibling alternatives (e.g. register_interest) for when a person wants contact without a call, so it stops just short of full routing 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description usefully adds what the payload contains (five questions, option values, answer JSON Schema, rubric), which matters because there is no output schema. It stops short of stating whether the returned question format is stable or how answers should be encoded, so it is strong but not exhaustive.

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 trigger condition and then the payload and next step. The persona and vendor lists are long but each item narrows applicability, so nothing is wasted.

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 zero parameters, no output schema and annotations covering the safety profile, the remaining burden is describing the return payload and the follow-up call, both of which are stated. An agent has everything needed to fetch the questions and route to assess_ai_exposure.

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 takes no parameters, so the baseline of 4 applies; there is no argument semantics the description could add or omit.

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 ('Returns the five multiple-choice questions, option values, the JSON Schema for answers and the rubric') and frames the trigger situation explicitly in the first sentence. The role of assess_ai_exposure as the consuming sibling makes the boundary with other tools 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?

Gives an explicit when-to-use condition ('Use when someone asks whether their family office, wealth manager, RIA or VC firm is exposing confidential data...') plus the calling sequence: ask each question, then call assess_ai_exposure. The alternative tool and its selection condition are named rather than left to inference.

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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds value beyond that by disclosing the shape of the return (published results plus a methodology link), which matters since there is no output schema.

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 tight sentences, with the usage trigger front-loaded and the return behavior second. Every clause earns its place; nothing is padded or repeated.

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, read-only lookup with no output schema, the description covers when to call it and what comes back (results plus methodology link). It is slightly thin on output specifics such as format or how many benchmarks are covered, but nothing needed to invoke it 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. Schema coverage is 100% and the empty input schema is consistent with the parameter-free 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 states the resource (published benchmark results) and what is returned (results plus a link to methodology), and the trigger phrases make the intent unambiguous. It does not explicitly distinguish itself from siblings like get_service_overview, but none of the siblings cover benchmark data, so overlap risk is low.

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 concrete when-to-use triggers (accuracy, hallucination rates, cost, speed), which is stronger than most definitions. It stops short of naming alternatives or exclusions, but no sibling tool competes for this intent.

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, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds genuine behavioral content beyond that: the result set has exactly six entries and is returned in a specific order (retention/deletion first, deployment last), which an agent could not infer otherwise.

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

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

Two sentences, no filler, and the usage trigger is front-loaded before the return-value detail. Every clause earns its place.

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

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

With no output schema, the description carries the burden of describing the return, and it does so at a high level (six ordered privacy domains). It does not enumerate the domains or state the response format, but for a static zero-arg lookup this is close to 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 takes zero parameters, so the baseline is 4. The description correctly implies no input is required and adds no misleading parameter expectations.

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 a concrete resource and scope: 'the six privacy domains in order, from retention and deletion down to deployment.' An agent can tell exactly what this returns, though it does not explicitly contrast itself with siblings like get_service_overview or get_benchmarks.

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?

'Use when someone asks how Private SuperIntelligence protects data' is an explicit trigger condition, which is strong usage guidance. It stops short of naming alternatives or exclusions, so it does not reach the 5 bar.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description goes beyond that by enumerating the content returned (definition, summary, availability, results, six privacy layers), which is genuinely useful for a tool with no output schema.

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 waste: the usage trigger is front-loaded, followed by the return contents. Every clause earns its place and nothing is repeated from the annotations or schema.

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 zero parameters, no output schema, and annotations covering the safety profile, the only real gaps would be what the tool returns and when to call it — both of which the description supplies in full.

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 takes zero parameters, which is the baseline-4 case per the rubric. There is nothing parameter-related for the description to clarify, and it appropriately devotes its space to describing returned content instead.

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 and resource ('Returns the definition of private superintelligence, the service summary, availability, results and the six privacy layers'), so an agent knows exactly what content comes back. It does not, however, differentiate itself from the sibling get_privacy_layers, whose scope it partially overlaps by also returning the privacy layers.

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 explicit trigger conditions ('Use when someone asks what Private SuperIntelligence is, who runs it, who it serves, how to get access or what it costs'), which is strong when-to-use guidance. It names no alternatives or exclusions, so the agent must infer that get_privacy_layers handles the narrower privacy question.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the output content (full markdown) but says nothing about size limits, pagination, or error behavior on an invalid path. With annotations carrying the behavioral burden, a 3 is appropriate.

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

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

Two short sentences with zero waste; the return value is front-loaded before the usage guidance. Nothing could be cut without losing information.

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

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

For a simple read tool with full annotation coverage and a fully documented single parameter, the description covers what an agent needs to call it correctly. No output schema exists, but the description states the return format (markdown), leaving only minor gaps like path-error handling.

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 enum-constrained path parameter is fully documented in the schema. The description adds no meaning beyond what the schema provides, so the 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?

States a specific verb and resource ("Returns the full markdown of one page") and implicitly contrasts with search_site by calling out "full markdown" retrieval. It is clear what the tool produces, though it does not explicitly spell out how it differs from search_site's result shape.

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 explicit routing: "Use after search_site, or when you already know the page you need." This names the alternative tool and the two conditions that select it. No when-not guidance, but the positive selection criteria are 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description's value-add is the gating behavior: userConfirmed must reflect explicit human approval, dryRun submits nothing, and $10M+ revenue triggers a booking link. It does not restate idempotency or the openWorld implication, leaving a little annotation-covered ground unaddressed.

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 purpose, then the confirmation protocol, then the validation mode and outcome. No filler, no repetition of schema text.

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?

An output schema exists so return values need no explanation. The description covers the mutation semantics, the confirmation gate, the dry-run escape hatch, and the qualifying threshold — everything an agent needs to call this correctly without further 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?

Schema coverage is 100%, so 3 is the baseline. The description goes beyond it by explaining why userConfirmed exists (only after the person approves the exact email, job title and revenue band shown to them) and by revealing the consequence of annualRevenueBand — the $10M threshold that determines qualification. That is real meaning the enum alone does not convey.

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 first sentence names a specific verb (adds to waitlist) and resource (Private SuperIntelligence waitlist), and frames it in terms of the agent's own task ('the person you are helping'). This is clearly distinguishable from siblings like book_private_call or assess_ai_exposure without opening any 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?

It gives concrete preconditions (show exact email/job title/revenue band, get a yes, then set userConfirmed=true) and a validation mode (dryRun). What's missing is explicit routing against the adjacent sibling book_private_call — the 'qualified registrations receive a link to book a conversation' line implies the relationship but never names the alternative 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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuinely new context: result shape (ranked passages) and coverage (the definition page, privacy notice, developer docs) – useful for an agent deciding what queries will hit. It doesn't mention rate limits, but that is minor.

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 tight sentences, front-loaded with the verb and scope; the second sentence delivers return format. No filler, no repetition of the title or annotations.

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 search tool with no output schema, the description supplies the essentials: what corpus is searched and the return format (ranked passages with URLs). The only mild gap is that it doesn't say a limit/count is accepted, though the schema covers that fully.

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%: both query (with min/max length and examples) and limit (range, default) are fully documented in the schema. The description adds nothing parameter-specific beyond the notion of 'passages' matching the limit field, so the 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?

States a specific verb (full-text search) and scope (every page on privatesuperintelligence.si), plus what it returns (ranked passages with page URLs). It never names a sibling such as read_page, so the distinction from fetching a known page is left implicit, which keeps it just below a 5.

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

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

Usage is implied by 'full-text search across every page' – use it when you need to locate content without knowing the URL. However, there is no explicit when-to-use statement, no exclusions, and no named alternative (e.g., 'for a known page, use read_page'), so the routing guidance is only inferred.

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