Read frozen Atlas cells, answer private quizzes, score Mini-IPIP vectors, and cast enum ballots.
Scored across 14 tools
Each tool targets a distinct resource or flow, and the descriptions include strong qualifiers like 'exact opaque code' or 'issued challenge and nonce'. However, cast_ballot, submit_friendship_prediction, and submit_personality_perception all represent submission actions and could be misselected if the agent does not carefully match the exact challenge type.
Tool names follow a consistent verb_noun snake_case pattern throughout, dominated by get_ for retrieval and submit_ for submissions, with unique verbs like cast_, create_, request_, and score_ standing out clearly. There are no mixed casing styles or unpredictable naming conventions.
14 tools is well within the ideal range and each tool appears to serve a distinct purpose across five clear subdomains: daily ballots, friendship challenges, personality perception, scoring, and aggregate results. The count feels intentionally scoped rather than bloated or thin.
Core lifecycle paths are present for ballots, friendship predictions, personality perception, and result retrieval. Minor gaps exist around explicit creation of private challenges and any update or cancel operations, but those appear intentionally constrained by the server's privacy and immutability model.
Submit enum-only self and prediction vectors for one issued challenge and nonce. Provenance is server-assigned.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | ||
| packId | Yes | ||
| challengeId | Yes | ||
| packVersion | Yes | ||
| selfChoices | Yes | ||
| schemaVersion | Yes | ||
| predictionChoices | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the call as a submission (consistent with readOnlyHint=false), ties it to a single issued nonce, and adds that provenance is server-assigned, which tells the agent not to send client identity. It does not detail finality or failure outcomes, but the annotations and output schema cover some of that burden.
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, both information-dense: the first states the action and scope, the second clarifies server provenance. No filler or repetition of schema details.
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 core submit path is clear and an output schema exists, so return values do not need describing. However, with seven required parameters and no property descriptions, the definition does not explicitly point the agent to request_ballot_challenge as the source of the issued challenge/nonce or state that the nonce is single-use, leaving some workflow context implicit.
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 0% schema description coverage, the description carries the burden. It gives semantic meaning to selfChoices/predictionChoices ('enum-only vectors') and to challengeId/nonce ('issued'), but it leaves packId, packVersion, and schemaVersion semantically unexplained beyond their raw schema constraints.
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 specific action ('Submit'), a specific resource ('self and prediction vectors'), and a scoping condition ('one issued challenge and nonce'). It is clear enough to distinguish from receipt/read-only sibling tools, though it does not explicitly name sibling submission tools such as submit_personality_perception.
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 phrase 'for one issued challenge and nonce' communicates the key precondition: cast a ballot only after a challenge and nonce have been issued. It gives clear context but stops short of explicitly listing when-not-to-use cases or naming alternative submission tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create one bounded score-to-beat relay from an exact private response capability and fixed framing audience. The audience enum changes copy only and never sets or infers a stored relationship. Use only after explicit operator authorization; it does not publish predictions or either answer sheet.
| Name | Required | Description | Default |
|---|---|---|---|
| audience | Yes | ||
| responseToken | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the audience enum only affects copy and does not set an inferred relationship, and that the tool does not publish predictions or answer sheets. This adds useful transparency beyond the annotations (which are all false), but it leaves out other behavioral aspects such as idempotency, side effects on existing data, or whether the relay is persistent.
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, compact sentence (plus a follow-up constraint) that conveys key caveats without unnecessary filler. It is well-structured and easy to parse, though the wording could be more straightforward.
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 a mutation with no annotation hints and no guidance on its return value or how the relay relates to other actions like prediction submission or scoring. While the description mentions what it does *not* do, it fails to explain what the caller will receive (output schema exists but is not described) or how to follow up. The description leaves important workflow gaps.
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 description hints that `responseToken` relates to a 'response capability' and that `audience` is an enum affecting copy only. This provides some meaning that the bare schema lacks (no descriptions), but it does not fully explain what a 'responseToken' is, its format, or its purpose beyond being a credential-like string. Overall, it adds moderate 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 states the tool creates a 'bounded score-to-beat relay' and mentions an audience and response capability, giving a general sense of purpose. However, the wording is abstract and jargon-heavy ('exact private response capability', 'fixed framing audience'), leaving ambiguity about what exactly the relay does or how it fits into the overall workflow.
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 provides a single usage constraint ('Use only after explicit operator authorization') but does not clarify when to use this tool versus siblings like `submit_friendship_prediction` or `score_personality_responses`. There is no guidance on preconditions, workflow position, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one receipt by its exact opaque identifier. Receipt enumeration is not available.
| Name | Required | Description | Default |
|---|---|---|---|
| receiptId | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond those annotations: the lookup is exact, the identifier is opaque, and enumeration is not supported, which shapes how an agent can expect the API to behave.
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 deliver the action, the constraint, and the negative capability. No filler or redundant restatement of the tool name or schema is present.
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 single-parameter point lookup with an output schema and read-only annotations, the description is fully sufficient. It communicates the necessary precondition, the absence of enumeration, and the lookup semantics; an agent has everything it needs to call the tool 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 description coverage is 0%, so the description carries the burden for parameter meaning. It effectively explains that receiptId must be the exact opaque identifier, adding semantic value beyond the schema's string pattern. Since there is only one parameter, this is sufficient.
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 clear action ('Retrieve one receipt') and a precise resource ('by its exact opaque identifier'), which fully defines the tool's purpose. It also explicitly clarifies that enumeration is not available, distinguishing this point-lookup tool from any imagined listing tool.
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 says exactly when to use the tool: when you already have the exact opaque identifier of a receipt. It also provides a clear exclusion, 'Receipt enumeration is not available,' telling agents not to attempt listing or discovery through this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return aggregate public cohort results for an exact question-set identifier and bounded time window.
| Name | Required | Description | Default |
|---|---|---|---|
| cohort | Yes | ||
| window | Yes | ||
| questionSetId | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the 'aggregate' nature of the result but does not disclose pagination, ordering, or error behavior; given the existing annotations, this is an acceptable baseline.
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 with the core action and result front-loaded. It is compact and free of filler, though the available space could have been used to clarify parameter semantics or usage context.
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 output schema and annotations provide useful information about safety and return shape, and the schema enumerates all parameter options. However, the description omits cohort semantics and inaccurately describes the window as bounded when 'all' is allowed, so an agent is not fully equipped to make all parameter choices 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 description coverage is 0%, so the description needed to compensate, but it only vaguely references an exact question-set identifier and a bounded time window. The cohort parameter is not explained at all, and 'bounded time window' conflicts with the window enum option 'all', which is unbounded.
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 verb ('Return') and a clear resource ('aggregate public cohort results'), scoped by an exact question-set identifier and a time window. It is distinguishable from most siblings by its subject matter, but it does not explicitly contrast itself with other get_* tools.
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 siblings such as get_daily_question_set or get_ballot_receipt. No exclusions, alternatives, or contextual triggers are provided, leaving tool selection mostly to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return only the latest already-frozen public Connection Atlas DTO. Cells are categorical, thresholded aggregates; raw edges, private capabilities, aliases, answers, scores, locations, and hidden cell totals are unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| cells | Yes | |
| status | Yes | |
| window | Yes | |
| createdAt | Yes | |
| editionId | Yes | |
| disclosure | Yes | |
| thresholds | Yes | |
| editionHash | Yes | |
| schemaVersion | Yes | |
| methodologyUrl | Yes | |
| previousEditionHash | Yes | |
| suppressedCellCount | Yes |
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. The description adds valuable behavioral context by specifying exactly what the DTO includes (categorical, thresholded aggregates) and excludes (raw edges, private capabilities, aliases, etc.), which is not covered by annotations. This goes beyond the structured metadata.
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 with no superfluous content. The primary action and resource are front-loaded, and the second sentence efficiently lists exclusions. Every phrase earns its place, making it highly concise and well-structured.
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 parameterless tool with an output schema, the description fully explains what the agent will receive: the latest frozen public DTO with specific aggregate cells, and explicitly lists unavailable data. There is no missing critical information needed to decide whether to call this tool or interpret its 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 has zero parameters, so the schema is trivially complete. Per rubric, a baseline of 4 applies, and the description further enriches the context by describing the nature of the DTO, even though it doesn't cover parameter details (there are none). This is acceptable and exceeds the 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?
The description clearly states the verb ('Return'), the resource ('the latest already-frozen public Connection Atlas DTO'), and its scope ('only' and 'already-frozen'). This is distinct from the sibling tools, which deal with ballots, friendship, and personality, so there is no ambiguity about what this tool does.
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 does not provide any explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. While the tool's name and content make its purpose obvious relative to the unrelated siblings, there is no 'use this when' or 'use that instead' language, leaving usage inference entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return today's public, curated either/or question set. No private challenge lookup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond those annotations: the result is time-scoped to today, the set is public and curated, and private challenge data is explicitly out of scope.
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 no filler. The primary action and resource are front-loaded, and the important negative constraint is stated clearly in the second sentence. Every word 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?
For a zero-parameter read-only tool with an output schema and strong annotations, the description is complete. An agent has everything needed to know when to call it and what it returns, and the output schema handles return-value specifics.
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 has zero parameters, so the schema fully covers parameter semantics by construction. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter-related noise.
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 ('Return') and names a precise resource: today's public, curated either/or question set. It also explicitly distinguishes this tool from private challenge lookups, making it easy to differentiate from siblings like get_friendship_challenge and request_ballot_challenge.
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 phrase 'today's public, curated either/or question set' establishes a clear usage context, and 'No private challenge lookup' communicates an important exclusion. It does not explicitly name which sibling to use instead for private challenges, but the exclusion is strong enough guidance for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one private 24-question Know Me challenge through its exact opaque code capability. Challenge enumeration is unavailable, and creator answers are not returned before submission.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral constraints: the challenge is private, answers are withheld before submission, and enumeration is impossible, which an agent needs to set expectations correctly.
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, information-dense sentence delivers the core capability first, followed by key limitations. No filler or repeated schema information is present.
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 a simple one-parameter input, strong annotations, and an output schema available, the description covers the essential retrieval semantics and caveats. Nothing critical for calling the tool 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 input schema only provides the code pattern without a description. The description compensates by explaining that the code is opaque and must be exact, and that no enumeration or listing exists. This adds meaningful semantic context to the single parameter.
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 identifies the resource as 'one private 24-question Know Me challenge' and the action as 'Retrieve' via an exact opaque code. This distinguishes it from sibling tools focused on personality instruments, daily questions, and ballot challenges.
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 states that challenge enumeration is unavailable, so the tool is only usable when the caller already possesses an exact opaque code. It does not explicitly name sibling alternatives or conditions for choosing them, but the usage context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one curated methodology section selected from a fixed enum.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'curated' and 'fixed enum' context, but these are minor. There is no contradiction, and the description does not add significant behavioral detail beyond 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 description is a single sentence with no filler. It front-loads the main action and the key constraint (fixed enum). Every word 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?
For a simple one-parameter tool with an output schema present, the description covers the essential behavior. The annotations cover safety, and the schema defines the parameter. The only minor omission is a hint about what the returned section contains, but the output schema likely handles that. Overall it is complete enough 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 coverage is 0%, so the description must compensate. However, the description only restates that the section is selected from a fixed enum, which mirrors the schema. It does not explain the meaning of each enum value or provide additional context about the content of each section. The enum values are self-explanatory, but the description fails to add value beyond what the schema already exposes.
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 ('Return') on a specific resource ('one curated methodology section') and notes it is selected from a fixed enum. This distinguishes it from sibling tools like 'get_cohort_results' or 'get_ballot_receipt' without ambiguity.
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 tool's purpose implies it should be used when methodology section content is needed, but there is no explicit guidance on when to choose it over alternatives or any exclusion criteria. The sibling list shows it is unique in covering methodology, so usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the exact versioned public-domain Mini-IPIP 20 instrument. No response vector is submitted or stored.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the tool returns an exact versioned public-domain instrument and that no response vector is submitted or stored. No contradiction exists between the description and 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 description is two short sentences with no filler. The core purpose is front-loaded in the first sentence, and the second sentence adds essential behavioral clarification about side-effect-free retrieval.
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 an output schema, the description fully covers what an agent needs to invoke it correctly. It explains what is returned (exact versioned Mini-IPIP 20 instrument) and that nothing is submitted or stored. No additional context is necessary.
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 has zero parameters, so there are no parameter semantics to document. The description still adds value by clarifying the operation has no request payload (no response vector submitted). The 0-parameter baseline of 4 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 uses a specific verb ('Return') with an exact resource ('exact versioned public-domain Mini-IPIP 20 instrument'), making the tool's function unmistakable. It also distinguishes itself from submission or scoring tools by explicitly noting that no response vector is submitted or stored. This is strong differentiation against the sibling tools.
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 clearly implies when to use this tool: when retrieving the instrument rather than submitting responses. It provides useful contextual guidance through the sentence 'No response vector is submitted or stored,' but it does not explicitly name alternatives or exclusion conditions. This fits 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one personality-perception challenge through its exact opaque code capability. Challenge enumeration is unavailable. Prediction is an unvalidated perception game.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation is read-only and idempotent. The description adds meaningful behavioral context beyond annotations by disclosing that challenges cannot be enumerated and that the code is an opaque capability, which materially affects how an agent should use the tool.
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 short and front-loads the core action and key constraint. The second sentence about prediction being an unvalidated perception game adds context, though its relevance is slightly less immediate; overall, no material waste exists.
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 a single parameter, strong annotations, and an output schema, the description covers the essential usage constraints: exact code required, no enumeration, and a warning about predictive validity. It is adequate for correct invocation without being overly verbose.
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 the undocumented parameter. It does so by characterizing 'code' as an exact opaque capability, clarifying that it is not a guessable or enumerable identifier and must match precisely. This adds semantic value beyond the schema's pattern constraint.
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 ('Retrieve') and identifies the resource as a personality-perception challenge in a way that is not a tautology. It also distinguishes this tool from siblings by emphasizing exact opaque code lookup and explicitly stating that enumeration is unavailable.
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 makes the primary usage condition clear: the caller must already possess the exact opaque code, since challenge enumeration is unavailable. It does not name alternative tools or explicitly state when not to use it, but the context is sufficient for an agent to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue one bounded challenge handle for a known pack, mode, and target. This does not enumerate challenges.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| packId | Yes | ||
| target | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false and destructiveHint=false, so the mutating but non-destructive nature is implied. The description adds some behavioral context by calling the result 'bounded' and clarifying that it does not enumerate challenges, but it does not explain side effects, handle lifetime, or repeat-call behavior. This is acceptable 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 two short sentences with no filler. It front-loads the core action and then adds the key exclusion clause, making every word earn 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?
For a tool with three required parameters including two enums and a 0% schema coverage description, the description fails to explain how to choose valid mode/target values or what makes a handle 'bounded.' The output schema covers return values, but the missing parameter semantics and usage context leave the description incomplete 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 0%, so the description carries the burden for explaining parameters, but it only restates their names ('pack, mode, and target') without defining packId format or the meaning of mode and target enum values. The phrase 'known pack, mode, and target' adds minimal semantic value beyond what the schema property names already 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 description uses a specific verb ('Issue') and a concrete resource ('one bounded challenge handle') scoped by pack, mode, and target. It also explicitly distinguishes itself from enumeration by stating 'This does not enumerate challenges.' This is enough for an agent to understand what the tool produces and how it differs from sibling tools.
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 the tool should be used when a single challenge handle is needed for known inputs, and the 'does not enumerate' clause tells the agent this is not the tool for listing challenges. However, it does not name alternative sibling tools or provide explicit when-to-use/when-not-to-use conditions, so usage guidance is left largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministically score exactly 20 canonical Mini-IPIP responses without storage. The result describes only the submitted vector, not an agent or person's identity, diagnosis, type, percentile, consciousness, or compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| responses | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already establish safety. The description adds meaningful context: 'without storage' clarifies non-persistence, 'deterministically' reinforces idempotency, and the phrase 'only the submitted vector, not an agent or person's identity...' prevents anthropomorphic misinterpretation of results. This goes beyond annotations and adds value without contradicting them.
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, tightly worded sentence that front-loads the core action ('Deterministically score exactly 20 canonical Mini-IPIP responses') and then qualifies output interpretation. No wasted words; 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?
The tool has an output schema (not shown but known), so return format is covered. The description addresses the main behavioral concerns: deterministic scoring, storage avoidance, and result interpretation. It does not explicitly mention error handling or prerequisites, but the schema enforces input validity. For a scoring tool with moderate 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 fully documents the responses array with itemId enums and response enums (1-5). The description provides no direct explanation of the parameter, but schema coverage is effectively 100% via enums. According to calibration, when schema is self-explanatory, baseline is 3. The description adds no parameter details, so a 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 verb 'score' and the specific resource: 20 canonical Mini-IPIP responses. It also explicitly states what it does NOT do (not identity, diagnosis, type, percentile, consciousness, compatibility), distinguishing its scope from potential misinterpretations. While it doesn't name sibling tools, the purpose is unambiguous and actionable.
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 specifies when to use the tool: to score exactly 20 Mini-IPIP responses. It implies a deterministic, storage-free operation. However, it does not explicitly mention alternatives among the sibling tools (e.g., get_personality_instrument for retrieving the instrument), leaving that differentiation to the reader. It is clear enough for an agent to infer its use case but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit exactly 24 enum-only predictions through one exact private challenge code. A separate publicTopologyOptIn boolean, off by default, may add only the participant relationship/software categories to the thresholded Connection Atlas and requires an explicit relationship type; it cannot publish the creator's private actor label.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| predictions | Yes | ||
| participantKey | Yes | ||
| relationshipType | No | ||
| publicTopologyOptIn | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as a non-read-only, non-idempotent write. The description adds meaningful behavior: the opt-in defaults off, publishing is limited to relationship/software categories, and the creator's private actor label cannot be published. It also imposes an exact-count invariant that agents need before calling.
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 compact and front-loads the core submission contract. The second sentence packs a complicated privacy condition into one long clause but earns its place; only slight restructuring would improve readability.
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?
Output schema and annotations cover return values and basic safety, and the description handles the tricky opt-in behavior. The missing participantKey and absence of any tie to prerequisite challenge flows leave a real completeness gap for a 5-parameter 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 provides no parameter descriptions (0% coverage), so the description must compensate; it explains code, predictions, relationshipType, and publicTopologyOptIn reasonably well. However, the required participantKey is never mentioned, and the prediction enum values (a/b) are left semantically uninterpreted.
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, resource, and hard constraints (exactly 24, enum-only, one private code). This clearly separates it from siblings like submit_personality_perception or score_personality_responses, even though no sibling is named.
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 guidance is given about when to choose this tool over submit_personality_perception, cast_ballot, or score_personality_responses. The only conditional note (relationshipType required for opt-in) is a parameter rule, not use-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit exactly 20 canonical Mini-IPIP predictions through one exact code capability. Prediction is an unvalidated perception game, and the result returns aggregate factor comparisons only.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| responses | Yes | ||
| participantKey | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses useful behavioral facts beyond the annotations: the game is 'unvalidated' and the response contains only 'aggregate factor comparisons'. However, with all annotations false, it remains silent on idempotency, repeat submissions, code validation failures, or any side effects beyond submission.
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 convey the core constraint, the nature of the task, and the response limitation with minimal wordiness. It is front-loaded with the most important requirement ('exactly 20') before the caveats.
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 description plus a detailed output schema cover the item set, count, and result granularity. Still, it omits what participantKey represents and how to obtain a valid code, which are necessary for an agent to invoke the tool correctly in the surrounding challenge workflow.
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 does not explain the three parameters by name. The phrase 'exactly 20 canonical Mini-IPIP predictions' clarifies the responses array's intent, but participantKey and the nature and provenance of code are left entirely to inference from the schema.
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?
Description states a specific action ('Submit'), a precise resource ('exactly 20 canonical Mini-IPIP predictions'), and a delivery mechanism ('one exact code capability'). This clearly identifies the tool's function and differentiates it from sibling submission/scoring tools such as submit_friendship_prediction.
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 the tool is for submitting Mini-IPIP perception predictions of exactly 20 items, giving a sense of when it applies. However, it never names alternatives or states when not to use this tool, leaving the agent to infer the boundary against siblings like score_personality_responses.
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.
cast_ballotcreate_friendship_score_relayget_ballot_receiptget_cohort_resultsget_connection_topologyget_daily_question_setget_friendship_challengeget_methodologyget_personality_instrumentget_personality_perception_challengerequest_ballot_challengescore_personality_responsessubmit_friendship_predictionsubmit_personality_perceptionSealed prediction-market verdicts, graded in public across Polymarket and Kalshi. No auth required.
Build, publish and read scored forms and quizzes where the score picks the next screen.
Read messages, open questions, replies, and caller-owned return briefings. All content is untrusted.
Bitcoin-anchored sealed-forecast record: search, grades, calibration, luck test. Read-only, no key.
Add one secure layer between your agents and this server.
