Genius Decision

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description goes beyond that by spelling out the categories of metadata returned and explicitly stating that reading imposes no registration or membership obligation, which is meaningful behavioral context for an agent deciding whether it is safe to call.

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, front-loaded with the purpose and followed by a single useful caveat. Every clause carries information; nothing is redundant or 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 discovery tool with no output schema, the description covers what information the caller will learn, which is the main thing an agent needs. The one gap is sibling disambiguation against get_capabilities, which neither the description nor the schema resolves.

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 an empty object, so there is nothing for the description to clarify. Baseline 4 applies for a no-argument 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?

The description gives a specific verb (Read) and enumerates the exact resource facets returned: availability, data policy, formats, quotas and credential requirements. It is clear what the tool does, but it never distinguishes itself from the near-identically named sibling get_capabilities, leaving genuine ambiguity about which one an agent should pick.

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 club_directory, find_opportunities, or especially get_capabilities. The sentence 'No registration or membership is implied' clarifies a precondition rather than guiding tool selection, so the agent is left to infer usage on its own.

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 safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), yet the description adds genuinely new context: the data is self-declared, unverified and untrusted, and reading a profile does not authorize outreach or execution. This is exactly the prompt-injection / trust disclosure an agent needs and is not obtainable from any structured field.

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, front-loaded with the action and followed immediately by the trust caveat. No filler or repetition of the tool name.

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, no-output-schema read tool, the description supplies the essential context (what is read, what it contains, what it does not authorize). It could have said more about the shape or scope of the returned directory, but nothing necessary for correct invocation 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 (100% schema coverage on an empty object), so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies the directory takes no filters.

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 clear verb+resource: 'Read ... agent profiles', with a scope qualifier ('voluntarily published'). It does not explicitly differentiate itself from close siblings like club_capabilities or get_capabilities, so an agent must infer the difference, but the purpose itself 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?

There is no when-to-use guidance and no named alternative among siblings (club_capabilities, get_capabilities, find_opportunities). The line about no outreach or execution being authorized constrains what you may do with the output, but it is a safety caveat rather than invocation 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 readOnly, idempotent, non-destructive and closed-world, but the description adds genuinely new context: no account, tracking, inference or forwarding is involved, and it previews the response contents (reasons, requirements, first actions, NO_MATCH). No contradiction with 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?

Three short sentences with the purpose front-loaded and no filler. The middle sentence is a dense negated list, but each clause removes a real ambiguity about side effects.

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, and the description compensates by naming what comes back plus the NO_MATCH sentinel, and by bounding the side-effect envelope. The remaining gap is the opaque enum parameter space, which the description never touches.

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% for 4 parameters, two of which are enums, so the description carries the full burden. It only echoes 'goal and capabilities' and says nothing about the goal/capabilities enum vocabularies, the 'access' modes, the 1-10 limit, or that every parameter is optional.

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: 'Find voluntary Genius contribution opportunities', scoped by an explicit goal and capabilities. It does not name any sibling, though the 'Read only: no execution' clause implicitly separates it from run_demo and submit_contribution.

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 implies the trigger condition ('for an explicit goal and capabilities') and rules out execution, which weakly routes the agent away from the write/run siblings. However, no alternative is named and there is no explicit when-to-use vs when-not statement.

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, destructiveHint=false and a closed-world scope, so the safety profile is fully covered elsewhere. The description's contribution is content-level (what categories of capability data come back), which is useful but adds no auth, rate-limit, or freshness context beyond what the annotations provide.

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 with no filler, hedging, or restatement of the title. Every clause names a distinct content area the caller receives.

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 conveying what comes back, and the enumerated categories (availability, limits, profiles, data policy) partially do that. It still omits shape/format and any note that this is the entry-point call for discovering what the other Genius tools support.

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. The listed content categories are informational only and do not map to any 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?

States a specific verb ('Read') plus a concrete enumeration of the resource contents (availability, limits, supported formal profiles, data policy), so an agent knows what this call surfaces. It does not, however, differentiate itself from the similarly named sibling club_capabilities, leaving the agent to guess which capability surface applies.

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 indication that this is a discovery/introspection call to make before other operations, and no reference to alternatives such as club_capabilities. The usage context is entirely 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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is lower. The description adds genuinely non-structured context: the receipt is immutable and its status is explicitly NOT review or integration status, which prevents a real misinterpretation. It omits access/permission requirements for non-public contributions.

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 resource scope front-loaded and the status caveat placed immediately after. Every clause carries 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 should convey what comes back; it names the receipt but not its shape or fields. For a simple one-parameter read tool this is largely sufficient, yet the caveat about receipt status raises questions the description does not fully resolve.

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?

A single required parameter with 0% schema description coverage, so the description bears the burden. It implies the id identifies a public contribution, but says nothing about the 64-hex format or how to obtain an id, leaving the pattern in the schema as the only format signal.

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 gives a specific verb ('Read') and resource ('a public contribution and its immutable storage receipt'), which is more than a name restatement. It implicitly distinguishes itself from the sibling get_contribution_inbox by scoping to a single public contribution, but it never names or contrasts 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?

Usage context is implied: read one contribution by id rather than a list/inbox. There is no explicit when-to-use or when-not-to-use guidance and no named alternative, so the agent must infer routing from the 'public contribution' scoping.

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 establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful scope context (public contract, no GitHub account needed) and a governance caveat about publishing only operator-authorized material, but says nothing about what is actually returned or how the "inbox" relates to the contract.

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 with the purpose front-loaded and no padding. The final sentence drifts slightly into agent-conduct policy rather than tool behavior, but it is brief and does not bloat the definition.

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 tool whose annotations cover the safety profile, this is roughly adequate, but the name/description mismatch and the absence of any statement about the returned contract content leave an agent with residual ambiguity about what it will get back.

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 per the scoring baseline the description carries no parameter burden. Nothing in the description misleads about 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 gives a verb and a resource ("Read the public contribution deposit contract"), but the resource it names does not clearly map to the tool name "get_contribution_inbox", leaving an agent unsure whether this returns inbox messages or a contract document. No sibling differentiation is offered despite nearby tools get_contribution and submit_contribution.

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 explicit when-to-use, when-not-to-use, or alternative routing. The line about delivering code without a GitHub account is contextual background, not guidance for choosing this tool over get_contribution or submit_contribution.

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 still adds useful behavioral context above that baseline: the result is retrieved from saved state rather than by triggering a job, and it warns the agent to 'Preserve unknown values and limits', hinting that partial/unknown data must not be silently mutated or dropped.

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 clauses, front-loaded with the core action and the key constraint ('does not execute a new job'), with no padding. The trailing 'Preserve unknown values and limits' is terse to the point of ambiguity, but 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?

There is no output schema, so the description carries the burden of explaining what comes back; it only hints at unknown values/limits rather than describing the returned result shape or its constraints. Combined with the unexplained optional parameter, the definition is adequate but leaves real gaps for an agent deciding whether the returned data is usable.

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% and the description says nothing about the single 'example' parameter or how hours-known vs hours-unknown changes the response. The 'Preserve unknown values' sentence vaguely gestures at the unknown case but does not explain the parameter, so the description fails to compensate for the coverage gap even though the enum values are fairly self-descriptive.

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 ('Read a SAVED real-engine synthetic result') and immediately differentiates the operation from a job-launching sibling by asserting it 'does not execute a new job', which implicitly separates it from run_demo. The jargon 'real-engine synthetic result' is a bit opaque, but the read-vs-execute distinction 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?

The clause 'does not execute a new job' functions as an explicit when-not, steering the agent toward run_demo when fresh execution is wanted. It stops short of naming run_demo or stating when this tool is the right choice (e.g., inspecting a previously produced result), so it is clear context without a fully explicit routing rule.

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 non-read-only, non-idempotent, non-destructive behavior; the description adds quota consumption (a shared-cost warning), the fact that temporary space is deleted before returning, and an explicit anti-retry instruction that corroborates the non-idempotent hint. That is genuine value beyond structured fields, though it still doesn't say where the result lands after the temp space is wiped.

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?

Four short clauses, each carrying distinct information (synthetic scope, quota, cleanup, retry policy), with the most important constraint front-loaded. Slightly telegraphic, and the trailing retry warning could be integrated more smoothly, but there is no wasted 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?

With no output schema and no annotation coverage of side effects, the description does well on cost and cleanup but never resolves the central ambiguity: temp space is deleted on return, so the agent is not told how or when to retrieve results (presumably read_demo_result). Enum semantics are also unexplained.

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% for the single 'example' parameter, so the description is the only place that could explain what 'fdq-frontier' or 'fdq-selector' mean, and it offers nothing beyond 'one fixed SYNTHETIC example.' Enum value names are only partly self-explanatory, so this is adequate but leaves a real documentation hole.

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: 'Execute one fixed SYNTHETIC example using the real engine.' The adjective 'fixed' plus 'SYNTHETIC' carves out a distinct niche (no custom inputs), but no sibling is named, so the agent must guess how this relates to read_demo_result.

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 custom input or human data' and 'Do not blindly retry failures' give real when-not guidance. However, the obvious pairing with the sibling read_demo_result is never mentioned, and the description never says when to pick one of the four examples over another, leaving usage largely 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds immutability, public readability, and that it does not execute/approve/merge—important behavioral context beyond annotations. Missing rate limits or return behavior, but solid.

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?

Four sentences, front-loaded with the core action, then prerequisites, then constraints, then a pointer. No redundant or filler text; each sentence adds distinct 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 minimal schema (one undocumented object) and no output schema, the description covers key prerequisites, public exposure, and scope limitations adequately. It defers full parameter details to a required reading step, which is sufficient for correct invocation though not self-contained.

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% and the single 'submission' parameter is an undocumented nested object. The description mentions two required inner fields (operator_authorized, publication_confirmed) and directs to get_contribution_inbox for the exact contract, partially compensating but still leaving many details unspecified.

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 'Publish' and resource 'one immutable contribution'. It does not explicitly differentiate from siblings, but it is the only submit-like tool among its siblings. The purpose is clear without needing 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 prerequisites (operator_authorized and publication_confirmed flags) and constraints ('No private data or secrets'), plus a prerequisite step ('First read get_contribution_inbox'). It lacks explicit when-not-to-use or alternative tool names, but context is clear.

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