Sleeper Hit Studio — Public Discovery

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

Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds context beyond the annotations by specifying the document is 'public' and 'full,' which suggests no authentication and the complete scope of the return. This is useful behavioral information not present in 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 first sentence is direct and front-loaded with the essential action. The second sentence about compatibility with ChatGPT deep research and company knowledge is somewhat vague and arguably does not earn its place, preventing a perfect score, but the overall length is appropriately short.

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

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

For a simple tool with one parameter, strong annotations, and no output schema, the description adequately communicates that the return is a full public discovery document. It lacks details about structure or error handling, but given the complexity, it is sufficiently 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 input schema provides 100% coverage for the single 'id' parameter, clearly describing it as a 'Search result ID returned by the search tool.' The description adds no additional parameter semantics beyond restating that the fetch is 'by ID,' so the baseline score of 3 is appropriate.

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

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

The description precisely states 'Fetch the full public discovery document for a search result by ID,' using a specific verb and resource that clearly distinguishes it from sibling tools like search and get_project_summary. The annotation title reinforces this purpose.

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

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

The description implies a clear usage pattern: after obtaining a search result ID from the search tool, use fetch to retrieve the full document. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to know when to invoke 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, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds value by noting that returns include project hub URLs and public asset summaries, but it does not disclose potential limitations like pagination or error behavior. 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 a single sentence that is concise and front-loaded with the core action. Every phrase earns its place, with no fluff or repetition.

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

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

Given the tool's relative simplicity (2 parameters, no output schema) and existing annotations, the description covers the essential purpose and output content. It is not exhaustive, but it provides enough context for a straightforward list operation. The lack of an output schema is partially mitigated by describing result components.

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 50% (only query has a description). The description does not explain query beyond the schema, but it indirectly clarifies writerSlug as the writer identifier via the phrase 'for a writer'. This adds some semantic context, but not enough to fully compensate for the missing schema description of writerSlug.

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

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

The description clearly states the verb 'List' and resource 'public projects for a writer', making its purpose specific. It also mentions the key result contents (project hub URLs and public asset summaries). However, it does not explicitly differentiate from sibling tools like get_project_summary or search, so it falls 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?

There is no guidance on when to use this tool versus alternatives. The description simply states what it does without mentioning exclusions or preferred scenarios. Sibling tool context exists but is not leveraged within the 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, openWorldHint, idempotentHint, and destructiveHint. The description adds the 'opt-in public' scope, which is useful context, but does not disclose additional behaviors such as result ordering, pagination, or special search semantics. With annotations carrying the safety profile, the description adds limited but non-zero value.

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

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

The description is a single sentence of 7 words, front-loaded and free of any filler. Every word contributes to the meaning, making it appropriately concise.

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

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

The tool is simple, with 5 optional parameters fully described in the schema and strong annotations covering safety and world-view. The description clearly states the search target, but does not mention return format or ordering. Given the absence of an output schema and the presence of sufficient structured metadata, the description is mostly complete, though not exhaustive.

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 does not elaborate on any parameters; all parameter meaning is already provided by the input schema. The description adds no extra semantics beyond what the schema provides.

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

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

The description clearly states the tool's purpose: 'Search opt-in public Sleeper Hit Studio writer profiles.' It uses a specific verb ('Search') and identifies the resource ('writer profiles') with a scope ('opt-in public'), distinguishing it from sibling tools like find_projects and get_writer_profile.

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

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

The description implies usage for searching public writer profiles but does not explicitly state when to use this tool versus alternatives like search or find_projects. No exclusions or references to sibling tools are provided, so guidance is only implied.

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

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

The annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond those annotations by specifying exactly what information is exposed (account-free capabilities, account-gated capabilities, and waitlist URLs) and reinforces that creation is handled elsewhere.

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 sentences. The first sentence front-loads the core purpose, and the second adds a critical usage rule. There is no filler or redundancy, making it optimally concise for an agent to parse quickly.

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

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

Given there are no parameters and no output schema, the description sufficiently covers what the tool does, why an agent would call it, and the key routing context about where creation happens. It is complete for its intended purpose and leaves no material ambiguity.

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

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

The input schema contains zero parameters and the schema description coverage is 100%, so there are no parameters to explain. The baseline for zero-parameter tools is 4, and the description appropriately focuses on what the tool returns rather than on parameter syntax.

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 opens with a specific verb and resource: 'Read what Sleeper Hit Studio can do without an account, what requires one, and the waitlist URL for each intent.' This clearly distinguishes it from sibling tools like find_projects or get_project_summary, which operate on actual project data rather than access/onboarding routing.

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 guidance: 'Call this before telling a user you cannot create something here' and identifies the alternative: 'creation lives on the separate authenticated connector.' This tells the agent precisely when to use the tool and points to the relevant alternative, exceeding the minimal requirement.

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 non-destructive behavior. The description adds the context that the summary is 'public' and 'one' (singular) but does not disclose error conditions, response format, or any other behaviors beyond what annotations imply.

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

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

The description is a single, front-loaded sentence without redundant words. It efficiently conveys the core action and scope.

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 getter, the description is minimally viable, but it omits important context such as return value details, the need for exact slugs, and any relationship to sibling tools. Given no output schema, the description could be slightly richer.

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 0%, so the description must compensate for parameter meaning. It only hints at 'for a writer' (writerSlug) but leaves projectSlug unexplained. It does not describe what constitutes a project summary or how to obtain valid slugs.

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

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

The description clearly states a specific action ('Get one public project summary') for a specific resource ('project summary') and specifies scope ('for a writer'). It distinguishes itself from sibling tools like get_writer_profile and list_project_assets by focusing on a single public project summary.

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

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

The description implies usage: to retrieve a single project summary for a particular writer. However, it does not explicitly state when to use this tool versus alternatives like find_projects or search, nor does it mention required prerequisites (e.g., knowing the exact slugs).

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 read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable filtering semantics ('writer-approved', 'public', 'pitch deck') that go beyond annotations, clarifying exactly what subset of assets will be returned. No contradiction.

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

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

The description is a single, front-loaded sentence with no filler or redundant information. Every word adds value.

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

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

Given the low complexity (one parameter, no output schema, rich annotations), the description covers the essential filtering criteria and scope. It does not mention pagination or return format, but these are unlikely to be critical for a simple list 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 0%, but the description links 'for a writer' to the writerSlug parameter, providing minimal semantic context. The parameter name is self-explanatory, though no format or how to obtain it is given. Some compensation exists but is limited.

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

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

The description uses a specific verb 'List' and clearly identifies the resource: 'writer-approved public pitch deck assets for a writer.' This distinguishes it from siblings like list_writer_assets or get_writer_profile by focusing on pitch deck assets with writer approval and public visibility.

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

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

The description implies when to use the tool (when needing public pitch deck assets for a given writer), but does not explicitly state when not to use it or mention alternatives. The scope is clear enough for basic selection.

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, and destructiveHint=false. The description adds return-content context (public projects and shared assets), which is useful. It does not cover error handling or authentication, but the safety profile is well-covered by 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?

Single sentence, front-loaded with verb 'Get', no fluff or redundancy. Every word is informative.

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

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

The tool is simple: one parameter, read-only, no output schema. The description covers the resource and return scope, while annotations cover the safety profile. Nothing essential is missing for this complexity level.

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 schema has one required string parameter 'slug' with no description. The description says 'by slug' but does not elaborate on slug format or source. This adds minimal meaning beyond the schema's type and required flag.

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

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

The description clearly states 'Get a public writer profile by slug' with the specific scope 'including public projects and shared assets.' This distinguishes it from siblings like find_writers (search/discovery) and get_project_summary (project-level details).

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

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

The context is clear: use when you have a writer's slug and need their public profile. However, it does not explicitly state when not to use or mention alternatives, though siblings like find_writers/search obviously serve discovery purposes.

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 the tool is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying the URLs are 'writer-approved' and 'public,' clarifying the selection criteria and access level. This goes beyond the annotation hints, though it does not describe return format or pagination.

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

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

The description is a single, well-structured sentence that front-loads the core action and object. Every word contributes meaning, with no redundancy or filler.

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

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

For a simple list tool with two parameters and no output schema, the description adequately conveys the purpose and return type (URLs). Combined with the annotations, the safety profile is clear. However, it could mention that writerSlug must correspond to a valid writer and that the resulting URLs are shareable, but these are minor gaps in an otherwise sufficient description.

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

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

The input schema has no descriptions for the two required parameters (writerSlug, projectSlug), and the description does not explain their meaning or format. The parameter names are somewhat self-explanatory, but with 0% schema coverage the description should compensate by defining them, which it fails to do.

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

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

The description clearly states the tool lists 'writer-approved public share URLs' for a 'specific project.' This is a specific verb+resource combination that distinguishes it from sibling tools like list_writer_assets (which likely lists all assets for a writer) and get_public_pitch_assets (which focuses on pitch assets).

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

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

The description implies when to use the tool—when you need public share URLs approved by the writer for a project—but it does not provide explicit exclusions or name alternatives. Sibling tools exist, but no guidance is given on how to choose between them, so the usage context is clear but lacks differentiation.

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. The description adds meaningful context beyond annotations: it specifies the output consists of writer-approved public share URLs, indicating an approval filter and public visibility constraint. No contradiction with 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?

A single, front-loaded sentence that is both specific and concise. Every word earns its place; no redundant filler.

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

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

Given the tool's simplicity (one parameter, no output schema, strong annotations), the description is largely sufficient. It clearly states that the tool returns a list of URLs, though it could optionally note the output type (e.g., array of strings) or any pagination behavior, but 'all' already implies comprehensive results.

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 0%, so the description must compensate. It says 'for a writer,' which maps writerSlug to the intended entity, but it does not explain the slug format, how to obtain it, or any constraints. The parameter name itself already conveys the semantics, so the description adds only marginal value.

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

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

The description uses a specific verb ('List') and identifies the exact resource ('writer-approved public share URLs') plus the scope ('for a writer'). This clearly distinguishes it from siblings like list_project_assets (project assets) and get_public_pitch_assets (pitch assets).

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

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

The description provides clear context for when to use this tool: when you need public share URLs approved by a writer. It does not explicitly mention alternatives or 'when not to use,' but the clarifying phrase 'for a writer' implies it should not be used for other asset categories.

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, openWorldHint, idempotentHint, and destructiveHint: false. The description adds meaningful scope: 'opted-in public' and 'writer-approved', clarifying that results are limited to opted-in/public data. It also mentions compatibility with ChatGPT deep research, which hints at integration context. No contradictions with 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?

Two concise sentences. The first states the core purpose, the second adds context about compatibility. No fluff or redundant phrasing. Every word serves a purpose.

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 simplicity of the tool (single parameter, no output schema, rich annotations), the description is complete. It defines the scope (public/opt-in), the type of content searched, and the intended context (deep research/company knowledge). No critical information is missing for an agent to select and invoke the tool.

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

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

The schema description covers 100% of the parameter, listing specific searchable entities (writers, projects, genres, formats, accolades, etc.). The tool description adds no new parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Search opted-in public writer profiles, project summaries, and writer-approved public assets.' This distinguishes it from sibling tools like find_projects or find_writers, which are more targeted. The inclusion of 'public' and 'writer-approved' adds clarity about scope.

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

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

The description implies usage through the search scope and 'Compatible with ChatGPT deep research and company knowledge,' suggesting it is for open-ended discovery. However, it does not explicitly state when to prefer this tool over siblings like find_projects or get_writer_profile, nor does it provide exclusion criteria. Usage is implied rather than directly guided.

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