Private SuperIntelligence by Mitosis Labs: define the term, see privacy layers, join the waitlist.
Scored across 6 tools
The three specialized getters (get_benchmarks, get_privacy_layers, get_service_overview) overlap with each other and with read_page, since get_service_overview already returns 'results and the six privacy layers' that the other getters cover. An agent may hesitate between calling a specialized getter versus search_site + read_page for the same content. read_page, search_site, and register_interest are clearly distinct.
All names use consistent snake_case with a verb_noun pattern (get_*, read_page, search_site, register_interest). No divergence in casing or style.
Six tools is well-scoped for a marketing/info site server: search, read, three domain getters, and a registration action. No tool feels like padding.
The surface covers discovery, content retrieval, domain-specific facts, and a write action (waitlist registration with dry-run and confirmation). Minor gaps like no explicit pricing/contact tool, but these are folded into get_service_overview so agents can work around them.
Use when someone asks about accuracy, hallucination rates, cost or speed. Returns the published results with a link to the methodology.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: the results are 'published' (i.e., static/pre-computed) and the response includes a link to the methodology, which hints at output content and provenance. It still omits freshness, format, and size details.
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 first front-loads the trigger conditions, the second states what is returned. Nothing redundant and nothing padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only retrieval tool with no output schema, the description supplies both the trigger and the return content (published results plus a methodology link). There is no meaningful gap an agent would need filled before calling it.
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 and the schema is fully self-describing, so there is nothing for the description to clarify. Baseline for a no-parameter tool is 4.
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 ('the published results') and what the tool returns, so an agent can distinguish it from siblings like get_service_overview or get_privacy_layers. It stops short of stating 'benchmark results' explicitly in the body, relying on the name/title for the subject, but the intent is 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?
It gives explicit trigger conditions ('Use when someone asks about accuracy, hallucination rates, cost or speed'), which is strong when-to-use guidance. It does not name alternatives or exclusions, so it falls short of the 5 bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when someone asks how Private SuperIntelligence protects data. Returns the six privacy domains in order, from retention and deletion down to deployment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, non-destructive, closed-world call, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the response is a fixed set of six domains returned in a deterministic order. It says nothing about caching, size, or formatting, but for a static reference tool that is a minor 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?
Two short sentences: the trigger condition first, then the concrete content contract. Every clause earns its place and nothing is repeated from the name 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?
There is no output schema, so the description carries the burden of describing the return value, and it does so at the right level (count and ordering of the domains). It deliberately does not enumerate all six, which is acceptable brevity, but leaves the agent slightly less certain about exact payload contents.
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 no parameter semantics to explain and no schema gap to compensate for. Baseline for a no-param tool is 4; the description correctly spends no words on nonexistent inputs.
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 specific resource (privacy layers) and even summarizes the payload — six privacy domains in order, from retention/deletion to deployment. That is far more than a restatement of the name. It does not explicitly contrast itself with siblings like get_service_overview or get_benchmarks, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit invocation trigger: 'Use when someone asks how Private SuperIntelligence protects data.' That is a clear when-to-use condition. It offers no when-not-to-use or named alternative, so it does not reach 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when someone asks what Private SuperIntelligence is, who runs it, who it serves, how to get access or what it costs. Returns the definition of private superintelligence, the service summary, availability, results and the six privacy layers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world behavior, so the safety profile is covered. The description adds value by disclosing the shape of the payload (definition, summary, availability, results, privacy layers), though it says nothing about caching, size, or freshness of the content.
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, trigger condition front-loaded, then the return contents. No filler, no restatement of the name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input parameters, no output schema, and annotations covering the safety profile, the description carries exactly the burden it should: when to call it and what comes back. 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. It correctly avoids inventing parameter-like details.
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 exact resource (the Private SuperIntelligence service overview) and enumerates its contents: definition, service summary, availability, results, and six privacy layers. It is clearly distinguishable from siblings like get_benchmarks and read_page, which cover narrower slices.
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 context for invocation. It does not, however, state when to prefer get_privacy_layers or search_site instead, and the 'six privacy layers' content overlaps with the get_privacy_layers sibling without a routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full markdown of one page. Use after search_site, or when you already know the page you need.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Markdown path of the page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds only that the return is 'full markdown' and where it fits in a search-then-read workflow; it says nothing about what happens with an invalid path or any truncation/size 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?
Two short sentences, zero filler, with the output shape stated first and the usage condition second.
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 one-parameter, non-destructive read with no output schema, the description covers what is returned and when to call it. A brief note on failure behavior for an out-of-enum path would make it 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?
Schema description coverage is 100% and the single path parameter is fully enumerated with 15 allowed values, so the schema carries the meaning. The description adds no syntax or selection guidance beyond the schema baseline.
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') with the scope narrowed to a single page, which cleanly separates it from the sibling search_site.
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 names the alternative (search_site) and the two conditions that select this tool: as a follow-up to a search, or when the target page is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds the person you are helping to the Private SuperIntelligence waitlist. Before calling, show them the exact email, job title and revenue band you will send and get their yes; then set userConfirmed to true. Set dryRun to true to validate without submitting. Qualified registrations ($10 million annual revenue or more) receive a link to book a conversation with Alex Morris.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The person's work email. | ||
| dryRun | No | Validate and preview the outcome without submitting anything. | |
| jobTitle | Yes | Their job title, e.g. "Chief Investment Officer". | |
| userConfirmed | Yes | True only after the person approved these exact details. | |
| annualRevenueBand | Yes | Approximate annual revenue of their organization in USD. |
| Name | Required | Description |
|---|---|---|
| dryRun | No | |
| message | Yes | |
| bookingUrl | No | |
| registered | No | |
| bookingEligible | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true). The description adds genuinely non-structured context: the human-approval gate, dry-run preview semantics, and the downstream outcome for qualified registrations. It stops short of describing what happens if submission fails or how duplicates interact with idempotency, so not a 5.
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, zero filler, and the workflow order is front-loaded (who to add → what to confirm → validation → qualification outcome). Every sentence carries information an agent needs.
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 needn't be described. The description covers the confirmation prerequisite, the dry-run escape hatch, and the qualified-registration consequence, which is everything needed to invoke this 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%, so the schema already documents all five parameters (baseline 3). The description still adds meaning for two of them: dryRun as 'validate without submitting' and userConfirmed as 'true only after the person approved these exact details', tightening the semantics beyond the schema text.
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 ('Adds the person you are helping to the Private SuperIntelligence waitlist'), which cleanly separates it from the get_*/read_* siblings. An agent can identify the action and target 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 explicit preconditions ('show them the exact email, job title and revenue band... get their yes; then set userConfirmed to true') and a validation path (dryRun=true). It also names the consequence that selects the qualified path ($10M+ revenue gets a booking link), so when and how to call are fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across every page on privatesuperintelligence.si, including the definition of private superintelligence, the privacy notice and the developer docs. Returns ranked passages with page URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum passages to return. | |
| query | Yes | Words to search for, e.g. "zero retention" or "how to book a call". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuine value by disclosing the return shape — 'ranked passages with page URLs' — which tells the agent how to interpret results beyond the structured hints.
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 tightly written sentences, front-loading the core capability (full-text search) before the coverage detail and return format. No filler and nothing 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 no output schema, the description carries the burden of explaining returns, and it does ('ranked passages with page URLs'). The limit cap of 10 is covered by the schema. Minor gap: no mention of pagination or ranking behavior, but overall the definition is sufficient for correct invocation.
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%, with both query and limit fully documented (including examples, min/max and default). The description adds no syntax or format detail beyond the schema, so the 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?
States a specific verb+resource combination: 'Full-text search across every page on privatesuperintelligence.si.' The coverage scope is spelled out clearly, so an agent knows exactly what corpus is searched. It does not, however, explicitly contrast itself with the read_page sibling, which is the closest alternative.
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 rather than stated: listing the definition, privacy notice and developer docs suggests this is the discovery tool for site content. There is no explicit when-to-use/when-not guidance and no routing to read_page for drilling into a specific result, so the agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_benchmarksget_privacy_layersget_service_overviewread_pageregister_interestsearch_siteConfidential AI execution with a post-quantum receipt on every job — verifiable by anyone.
Private, portable memory and reusable skills for AI agents.
Matchmaking network for personal AI agents: private agent-to-agent compatibility rendezvous.
Sovereign Agent OS — Persistent Memory, Governance & Compliance for AI Agents.
Add one secure layer between your agents and this server.
