Fifty50

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

Annotations (readOnlyHint=false, destructiveHint=false) already indicate a non-destructive write. The description adds context about the API endpoint and an example of signals, but does not disclose additional behavioral traits like side effects, permissions, or limitations.

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 concise, consisting of two sentences plus an API reference and example. It is front-loaded with the core purpose. However, it could be more structured by separating parameter explanations.

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 covers the core purpose and provides a signals example, but lacks explanations for optional parameters (kind, text) and does not mention the output schema. Given the complexity (5 params, nested objects), it is adequate but not complete.

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

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

Schema coverage is 0%, so description should compensate. It explains that pid is the partnership_id and gives an example for signals, but does not describe kind, text, or partner_id. This partial coverage is insufficient for a tool with 5 parameters.

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: 'Log what a partner contributed; this drives the equity split.' It uses a specific verb ('Log') and resource ('contributions of a partner'). The API endpoint adds context. It is distinguishable from sibling tools like 'create_partnership' or 'record_outcome'.

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 by stating 'this drives the equity split,' but does not explicitly specify when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.

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, openWorldHint=true, destructiveHint=false, which align with the chat tool's nature. The description adds no additional behavioral traits beyond the API endpoint and parameter structure, so it does not significantly enhance transparency 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 extremely concise: two sentences, front-loaded with the tool's action and an example. Every sentence adds value, with no unnecessary words.

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 presence of an output schema, the description does not need to explain return values. It adequately explains the input parameters and the tool's purpose for a relatively simple chat tool. However, a brief note on the AI's response behavior would improve completeness.

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 compensates by explaining that messages should be an array with role and content objects and that partnership_id is optional. It adds meaningful context beyond the schema's bare types, though it could be more detailed about the message format.

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 it is an AI co-pilot for asking questions in plain English, with an example ('is our split fair?'). It specifies the API endpoint and distinguishes itself from sibling tools that perform specific actions like adding contributions or forecasting equity.

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 mentions optional grounding via partnership_id but does not provide explicit guidance on when to use this tool versus other siblings. Since sibling tools are quite different in purpose, the context is implied, but lack of explicit when-to-use or when-not-to-use guidance limits the score.

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 provide readOnlyHint and destructiveHint. The description adds the API endpoint and syntax for the kind parameter, but does not elaborate on other behaviors beyond what annotations convey.

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, front-loaded with the purpose, and no extraneous information. Every sentence 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 simple structure (3 optional params, output schema exists), the description covers the basics well. Could mention that it returns a list of listings, but the output schema fills that gap.

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 adds meaning for the kind parameter ('e.g. 'seeking' or 'offering''), but provides no additional information for q or industry parameters.

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: 'Browse the co-founder / collaborator marketplace' with a specific verb and resource, and distinguishes from siblings like post_listing which creates listings.

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 mentions it is 'read-only' and provides an example for the kind parameter, but does not explicitly state when to use this tool instead of alternatives like post_listing or search 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 indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds important behavioral context: the tool returns a partnership_id and a one-time owner_token that the caller must store to manage the partnership. This discloses critical post-creation behavior beyond annotations. 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?

The description is two sentences, no wasted words. First sentence gives verb and resource, second explains critical return values and token handling. Information is front-loaded and efficient.

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 has 3 parameters and an output schema (not shown), the description covers return values and the partners parameter adequately. However, it does not explain the 'industry' parameter or provide constraints on partners (e.g., minimum number). The description is sufficient for basic use but lacks detail on optional parameters.

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 description must compensate. It explains the partners parameter as 'list of {name, role}', adding meaning beyond the raw schema. However, it does not describe the 'name' or 'industry' parameters, though they are simple strings. The explanation of partners is useful.

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 creates a partnership and its partners, with specific verb 'Create' and resource 'partnership'. It also references the API endpoint and lists return values, distinguishing it from sibling tools that do different actions.

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 use for creating partnerships but does not explicitly state when to use this tool versus alternatives, nor does it provide any prerequisites or conditions. No 'when not to use' guidance is given.

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?

Adds that it's Monte-Carlo simulation and explicitly says 'does not change any stored data', aligning with readOnlyHint. Provides API endpoint context beyond 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 efficient sentences: purpose first, then API details and safety reassurance. No wasted words.

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?

Adequate for a read-only simulation with output schema, but lacks detail on config parameter and simulation results. Not fully 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 coverage 0%. Description only explains pid (partnership_id), not the config object. No compensation for missing parameter descriptions.

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?

Clearly states it Monte-Carlo simulates equity split. Verb 'simulate' and resource 'equity split' are specific. Distinct from siblings like recommend_vesting or record_outcome.

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 explicit guidance on when to use vs. alternatives. Implied usage for forecasting, but no mention of when not to use or 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 declare readOnlyHint=true, destructiveHint=false. Description adds that the tool returns reasoning and uncertainty bands, which are behavioral details about the output. No contradictions.

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

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

Two sentences with no waste. Front-loaded with the key purpose. Efficient and to the point.

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 output schema exists, return values are not required. Description mentions reasoning and uncertainty bands, which is helpful. Tool is simple with one parameter. Could explicitly differentiate from 'forecast_equity' but otherwise complete.

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

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

Schema coverage is 0%, and description provides minimal parameter context: 'pid=partnership_id'. This adds meaning but could include format or constraints. Baseline is low, and description partially compensates.

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?

Clearly states the tool gets the current fair equity split with reasoning and uncertainty bands. The verb 'get' and resource 'fair equity split for a partnership' are specific. It distinguishes from siblings like 'forecast_equity' which is about predictions.

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?

Implies usage for retrieving current equity split but provides no explicit guidance on when to use versus alternatives like 'forecast_equity'. No when-not or recommended context.

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 indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that 'contact is shown publicly' and rejects investment listings, which provides behavioral context beyond 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 concise sentences, each adding value: purpose, constraint, and return value. No wasted words.

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?

Despite having an output schema and moderate complexity (8 params, 4 required), the description lacks parameter guidance and does not explain the 'kind' field. While the return URL is mentioned, the overall context for a creation tool is insufficient.

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 any of the 8 parameters or their valid values. 'contact is shown publicly' is the only hint. The agent gains no additional meaning beyond parameter names.

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 action ('Post'), the resource ('marketplace listing'), and the purpose ('to find a co-founder or skill you're missing'). It distinguishes from siblings like 'browse_marketplace' by focusing on creation.

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?

Provides explicit usage constraints: only for finding collaborators, not for investment. Mentions that 'contact is shown publicly' and that investment listings are rejected. However, it does not mention when to use alternatives.

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 and destructiveHint=false. The description reinforces this by stating no data change. No additional behavioral traits (e.g., rate limits, authentication needs) are disclosed beyond the API path mention. The description adds minimal extra value beyond 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 with key information front-loaded: purpose first, then behavioral clarification. The API endpoint inclusion is slightly verbose but not excessive. No wasted words.

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 has 4 parameters (including nested objects) and an output schema, the description covers the high-level purpose and safety but omits parameter semantics. The output schema may define return format, but input configuration details are missing, making it incomplete for complex usage.

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%, placing heavy burden on description. It only explains 'pid=partnership_id', leaving config, current_shares, and divergence_threshold completely undescribed. Users cannot infer the correct format or purpose of these optional parameters from the description alone.

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 'recommends a vesting plan and flags when a grant has drifted from fair', which is a specific verb and resource. It does not explicitly distinguish from siblings, but the sibling tools cover different domains (e.g., add_contribution, create_partnership), so no confusion. The API endpoint reference adds specificity.

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 notes that the tool 'computes a recommendation only — does not change any stored data', implying safe read-only usage. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context like required permissions.

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 indicate the tool is not read-only and not destructive, and the description adds the API endpoint and the fact that it triggers model learning. However, it does not elaborate on permissions, rate limits, or side effects beyond the basic action.

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 concise, two sentences plus a code snippet, with the API endpoint embedded. It is well-structured and front-loaded with the core action.

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 covers the purpose and key parameters but does not address the output schema or return behavior, leaving some gaps for a tool with 4 parameters and nested objects.

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 partially compensates by explaining pid and target_shares with an example. However, it omits explanation for source and weight, leaving them undefined.

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 'Record', the resource 'realized split', and the purpose 'so the model learns'. It distinguishes from siblings like create_partnership by specifying this is for outcomes after a vote.

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 recording split outcomes but does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions. The context is clear but not directive.

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