Open Creator Graph

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

Annotations already establish that this is a safe, read-only, idempotent operation. The description adds meaningful behavioral context beyond them: the result is expressed in words and includes links to a machine-readable declaration, and an absent declaration must be treated as unknown rather than permission.

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 dense sentences with no wasted language. The resource and return shape come first, followed by the critical caveat about missing declarations.

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 rich annotations and full parameter schema coverage, the description is largely complete: it explains what the consent record contains and how to interpret absence. It does not explain how the HCS declaration links should be used or how this relates to the sibling creator tools, but no output schema exists and the core call semantics are covered.

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 only one parameter, and the schema fully documents it with a pattern and example. The description adds no additional parameter meaning, so the schema carries the parameter semantics as expected.

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 defines the resource precisely as a Creator's AI consent covering name, image, likeness, voice, movement, and signature, and says it returns verbal terms plus links to the HCS 1.0 declaration. The read action is clear from the title, but the description itself does not explicitly differentiate this from get_creator_record or search_creators.

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: this is the tool for checking what a Creator permits AI to do with their identity. The description gives important interpretation guidance for missing declarations (“treat that as unknown, never as permission”), but it does not state when to choose this over the sibling tools.

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 read-only, idempotent, closed-world safety, so the description correctly spends its space elsewhere: it declares the return format (Markdown), the public-only scope, and a downstream obligation to preserve confidence labels and cite the record URL. It does not say what happens for an unknown or malformed ID, which is the remaining behavioral 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?

Front-loaded with verb, resource and format in the opening clause; the long field enumeration is dense but every item is return-value information an agent cannot get elsewhere since there is no output schema. The second sentence on confidence labels and citation is a distinct, non-redundant instruction.

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 return-shape burden and does so thoroughly, enumerating platforms, topics, location, languages, tenure, credentials, AI-use terms and provenance, plus the confidence-label scheme. Only failure behavior for an invalid or missing ID is unaddressed.

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%; the single sprk_id parameter is documented in the schema with its regex pattern and the note that the bare number is accepted. The description adds no syntax or format detail beyond that, 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?

Specific verb + resource: 'Read one Creator's full public record as Markdown', followed by an enumeration of exactly what fields come back. The singular 'one Creator' plus the required ID clearly separates it from the sibling search_creators, which returns multiple.

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: 'one Creator' signals a single-record lookup keyed on an ID, which an agent must already possess. There is no explicit instruction such as 'use search_creators first to obtain an sprk_id', and no exclusions or alternative routing named.

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 and non-destructive, so the safety profile is covered; the description adds that this is a search against the Open Creator Graph and enumerates the returned fields. It omits result-set behavior such as empty-result handling and how limit affects paging.

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 short sentences: what it finds, what it returns, when to prefer it. Front-loaded and 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?

Because no output schema exists, listing the returned fields (SPRK ID, name, handle, platforms, claim state, record URL) is genuinely necessary and supplied. The only missing piece is guidance on the limit parameter and result ordering.

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?

With only 50% schema description coverage, the query param is well served: the description widens it beyond the schema's 'Name, handle or URL' by including SPRK ID. The limit parameter gets no explanation in the description and relies on the schema's default/min/max alone, so the gap is only partly compensated.

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 ('Find') and resource ('Creator records') plus the exact lookup keys (name, handle, SPRK ID, profile URL). An agent can immediately distinguish this from the sibling get_creator_record.

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 says to use it *before* get_creator_record when only a name or handle is known, naming both the alternative and the condition that selects this tool. No inference required.

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