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

Annotations already provide readOnlyHint=true and destructiveHint=false, covering the main safety profile. The description adds useful context by stating that the response includes version lineage, but it does not disclose rate limits, authorization requirements, or response shape. Overall it supplements the annotations 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?

The description is a single focused sentence with no filler words. It front-loads the action ('Get a dataset'), then specifies the scope ('version lineage') and input keys ('by organization and slug') in a natural order.

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

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

For a simple read-only lookup tool with two self-descriptive parameters, the description is sufficient for an agent to invoke it correctly. It names the return scope ('dataset and its version lineage') and the required identifiers. It does not detail the exact response structure, but the tool has no output schema and this omission is not blocking.

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

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

The schema has 0% description coverage, but the parameter names org_slug and dataset_slug are self-explanatory. The description's phrase 'by organization and slug' maps onto the parameters and communicates that they form the identity of the dataset, so basic semantics are clear. No deeper format or behavioral detail is added beyond the 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 uses the specific verb 'Get' with a clear resource ('a dataset and its version lineage') and specifies the lookup keys ('by organization and slug'). This is immediately distinguishable from sibling tools like scorestudio_list_datasets, which would return a collection rather than an individual dataset.

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 or when-not-to-use guidance, and no alternatives are mentioned. However, the description clearly implies this tool is for retrieving a single dataset by org and slug, leaving the choice versus list_datasets implicit but reasonably inferable.

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, so the safety profile is clear. The description adds value by listing expected report components, but it does not disclose error behavior, result format details, or any caveats beyond that, so behavioral transparency is adequate but not rich.

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

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

A single, front-loaded sentence with no filler. The verb, resource, and output contents are all conveyed efficiently, and every phrase 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 read-only report retrieval with only two required parameters and no output schema, the description adequately summarizes what the agent can expect. It could add details like whether an unknown run_id produces an error, but the core invocation context is sufficiently covered by the description and annotations.

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 explaining parameters. It only ties into 'evaluation run,' which helps infer run_id, but org_slug is left entirely to its parameter name. With both parameters required and undocumented, the description provides insufficient parameter guidance.

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 ('Get') and a specific resource ('evaluation report'), then enumerates the report's contents: metrics, slices, intervals, and evidence. This clearly distinguishes it from sibling tools like list_evaluations, which would list runs rather than retrieve the detailed report of one run.

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 this tool is used after an evaluation run has completed and the caller wants detailed results, but it does not explicitly state when to choose this over alternatives such as list_evaluations or start_evaluation. Usage context is recognizable but 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'versioned' and 'organization' scope, but it does not disclose pagination behavior, the default exclusion of archived datasets, or any other operational traits. It is consistent 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?

The description is a single concise sentence with no redundant phrasing and the core action is front-loaded. It is appropriately short, though brevity comes at the cost of missing useful invocation 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?

For a tool with four parameters, no output schema, and no parameter descriptions, this one-line description is insufficient for reliable invocation. An agent is left without guidance on required arguments, pagination, archived filtering, or the shape of the response. More context is needed.

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 the description does not compensate by explaining any of the four parameters. There is no mention of org_slug being required, or the meaning of limit, offset, or include_archived. Parameter names are somewhat self-evident, but the description adds no semantic value on top of 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?

The description uses a specific verb and resource: 'List versioned datasets in a Score Studio organization.' It clearly indicates a plural listing operation and adds the 'versioned' scope and organization context. It does not explicitly contrast with siblings like scorestudio_get_dataset, so it stops short of full sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives such as scorestudio_get_dataset or scorestudio_list_models. The description only states what the tool does, leaving the agent to infer usage from the tool name and siblings. No exclusions or conditions are provided.

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, so the safety profile is covered. The description adds that the list covers revisions and runtime state, and is org-scoped, but it does not describe pagination, ordering, or response behavior. Since annotations lower the bar, this is adequate but not rich.

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

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

A single sentence with no fluff. It front-loads the action and resource, then adds the extra content areas (revisions, runtime state) and scope. Every phrase 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 list tool with readOnly annotations and schema-provided limit/offset/defaults, the description is workable. However, there is no output schema, so the returned structure is undefined, and the description does not explain how pagination interacts with the list. It says what categories are returned but not what fields or status values an agent should expect.

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 missing parameter explanations. It adds organizational context that maps to org_slug, but it does not clarify limit/offset semantics, pagination behavior, or the expected slug format. The schema supplies types/defaults, but the description carries little added meaning.

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

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

The description uses a specific verb ('List') and names the resource ('deployments') plus the returned content ('revisions, and runtime state'). It also specifies the scope ('in an organization'). This clearly distinguishes it from sibling tools that list workflows, datasets, models, or evaluations.

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 gives no guidance on when to use this tool versus alternatives such as verify_deployment. It does not state when a list is appropriate, when verification is better, or any exclusions. The context must be inferred entirely 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.

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

Annotations already communicate read-only, open-world, and non-destructive behavior. The description adds a little value by saying runs are 'measured' and that 'current states' are included, but it does not describe pagination, response contents, or other behavioral edges.

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 focused sentence that front-loads the core action and resource with no redundant wording or filler. 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 list operation, the description is adequate: it identifies the resource and what states are returned. It does not explain how this relates to get_evaluation_report or describe the response shape, but those are not critical for invoking this 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 needed to compensate for the parameters, but it mentions neither 'org_slug' nor 'limit'. The schema provides type/default/constraints, which is minimal help, but the description adds no parameter meaning.

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 ('List'), a distinct resource ('measured evaluation runs'), and the key detail of 'current states'. This clearly distinguishes it from sibling list tools like list_workflows, list_datasets, list_models, and list_deployments.

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 resource is clear enough that an agent can infer when to use it: when a list of evaluation runs and their states is needed. It does not mention alternatives or exclusions, but the resource scope is unambiguous compared with 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, openWorldHint=true, and destructiveHint=false. The description adds that the tool returns both models and versions and that the scope is an organization, but it does not disclose behavior such as pagination behavior, ordering, or the shape of returned entries.

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, focused sentence that front-loads the action and object. It contains no filler, redundant phrasing, or repetition of the title.

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 is adequate for a simple read-only enumeration and the annotations cover the safety profile. However, there is no output schema and no mention of what fields or structures are returned, nor any guidance about how limit/offset pagination behaves, leaving some context incomplete.

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 undocumented parameters. It only reflects the org scope for org_slug and gives no semantic detail for limit or offset beyond their names and schema constraints, leaving pagination behavior underspecified.

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

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

The description uses a specific verb ('List') and resource ('models and versions') scoped to a Score Studio organization. It clearly distinguishes this from sibling list tools such as list_datasets, list_workflows, and list_evaluations by naming a different resource type.

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 usage is implied: use this tool when you need to enumerate models or versions in a Score Studio organization. However, the description gives no explicit when-to-use guidance, exclusions, or named alternatives, so an agent must infer when to prefer it over other listing siblings.

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, and the description's 'List' wording is consistent with those. The description adds that it returns workflow definitions and status, but does not disclose additional behavior such as pagination, response shape, or open-world completeness. This is adequate but not rich.

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

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

The description is a single compact sentence with no filler, front-loading the verb and resource. It earns its place without redundantly restating the title.

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

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

For a simple list tool with annotations covering safety, the description covers the core action and returned concept (definitions and status). However, without an output schema it does not clarify return fields or status semantics, and the required org_slug is left undocumented.

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 mention the org_slug parameter at all. It adds no meaning beyond the bare property name and type, so for a parameter with no schema description the tool description fails to compensate.

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

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

The description uses a specific verb ('List') and resource ('typed Score Studio workflow definitions and status'), making its purpose immediately clear. It differentiates from sibling tools like scorestudio_run_workflow (execution) and scorestudio_list_datasets/list_models (other resource types).

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 listing nature of the tool gives implied usage context, but the description does not explicitly say when to choose it over alternatives such as list_datasets/list_models or run_workflow. It provides no exclusions or 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.

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

Annotations already indicate this is not read-only but not destructive, so the description only needed to add behavior beyond that. It adds the 'existing image object' prerequisite and the 'may report deferred blocks' outcome, but it does not disclose side effects, whether execution is asynchronous, or what a deferred block means in practice.

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 appropriately short and front-loaded, with two sentences that avoid redundancy. It could be improved by using the available space for more parameter or usage detail, but as a concise definition it is effective.

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, yet the description only vaguely says the result may report deferred blocks; it does not describe the overall return format, whether a run ID is returned, polling/async behavior, or failure semantics. For a non-read-only operation with three required parameters, this is insufficient for reliable 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 must compensate for the three undocumented parameters. It only clarifies that the workflow runs against an existing image object, which maps loosely to image_object_key, but it does not explain org_slug, workflow_slug, how to obtain them, or any value-format expectations beyond the schema's length 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 ('Run a workflow') against a specific resource ('an existing Score Studio image object') and adds that the result may report deferred blocks. It is clear and not tautological, though it does not explicitly differentiate this tool from sibling tools that also execute work.

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 about when to use this tool versus alternatives such as scorestudio_start_training or scorestudio_list_workflows. No alternatives, exclusions, or prerequisite conditions are mentioned; usage is only implied by the tool name and action.

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 indicate readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral traits: 'immutable' discloses that the created run cannot be modified, and 'measured' indicates metrics are computed. This goes beyond what the annotations already 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 sentence with no wasted words. The action verb and key qualifiers are front-loaded, making the core operation instantly readable.

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 7-parameter creation tool with no output schema, the description is too thin. It omits what the created run returns, how metric_config and idempotency_key influence behavior, and what 'immutable' means for subsequent operations like updates or deletions.

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

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

Schema description coverage is 0%, so the description must compensate. It only adds semantic meaning for model_version_id and dataset_version_id, while leaving the other five parameters (org_slug, task_type, random_seed, metric_config, idempotency_key) unexplained in both the schema and the description.

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 ('Create') and a specific resource ('immutable measured evaluation run') and further specifies the two key inputs (model version and dataset version). This clearly distinguishes it from sibling tools like scorestudio_start_training, whose purpose is training rather than evaluation.

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 evaluation runs but gives no explicit when-to-use guidance or alternatives. An agent cannot tell from the description alone when to choose this over scorestudio_start_training or scorestudio_run_workflow; there are no exclusions or context signals beyond the tool name.

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 this is not read-only and not destructive. The description adds valuable non-obvious behavior: 'This may consume compute credits,' and indicates the job is tracked. It does not mention asynchronous completion or what artifacts are produced, but it covers the most decision-relevant side effect.

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 primary purpose is front-loaded, and the compute-credit warning is placed second as a necessary caution. 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 tool with nine parameters, enums, defaults, and no output schema, this description is too sparse. It omits what the returned result is, how parameters interact, and what 'tracked' means operationally. The description covers intent and cost but not enough for confident 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 must compensate for the nine parameters, but it does not. None of name, epochs, preset, compute, project_slug, version_number, or existing_model_slug are explained. The phrase 'immutable dataset version' weakly alludes to dataset_slug/version_number, but it is insufficient to make parameter choices clear.

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-resource pair: 'Start a tracked training job,' which clearly identifies the action and distinguishes it from evaluation and workflow tools. It also adds the context 'against an immutable dataset version,' making the target of the operation concrete. This is a clear, non-tautological purpose statement.

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 conveys a clear context: it is for starting a training job rather than for listing, evaluating, or running a generic workflow. It does not explicitly name alternatives or provide exclusions, which prevents a 5, but the phrase 'tracked training job' gives enough contextual signal for an agent to know when this tool applies.

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 meaningful behavior beyond annotations by revealing that evidence is retained and the active revision is not changed. This is consistent with destructiveHint=false and readOnlyHint=false. It does not detail storage or output side effects, but the key safety property is disclosed.

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?

One tightly written sentence that front-loads the action and key constraint. Every word contributes meaning, with no redundancy or filler.

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

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

For a simple two-string-parameter tool, this is reasonably complete: it states what the tool does, that evidence is retained, and that the active revision is untouched. The main gap is that, with no output schema, it does not clarify what the tool returns beyond retained evidence.

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 org_slug or deployment_slug. The parameter names and context imply their roles, but the description adds no explicit semantic value beyond 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?

States a specific action: run and retain deployment health verification evidence, and explicitly notes it does not change the active revision. This distinguishes it from sibling tools like run_workflow or list_deployments.

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 clear context: use this when you need verification evidence without altering the active deployment revision. It does not name alternative tools or explicit when-not conditions, but the non-mutation qualifier conveys an important usage boundary.

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=true and destructiveHint=false, so the description does not need to restate safety. It adds useful context by specifying that the result includes the authenticated user and organization memberships, which is more informative than the generic title.

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, perfectly front-loaded sentence that states exactly what is returned. There is no filler, no repetition of the title, and no extraneous 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?

For a simple zero-parameter identity lookup with no output schema, the description is fully sufficient. It tells the agent what the tool returns (user and organization memberships) and nothing else is needed to invoke it 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?

The tool has zero parameters, so the schema fully documents everything an agent needs to know. The description adds no parameter-level details, but none are required; a baseline of 4 is appropriate for a no-parameter 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 states a specific verb ('Return') and a clear resource: the authenticated Score Studio user and organization memberships. It unambiguously distinguishes this from all sibling tools (verify, list, run, start operations), all of which target workflows, datasets, models, or deployments.

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 this is the tool for retrieving current identity/context. While it does not explicitly name alternatives or say 'use when ...', the unique identity focus and zero-parameter design make the usage context obvious and there are no competing siblings that could be confused with it.

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