ProteinIQ

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, so the mutation profile is known. The description adds useful semantics (null target unassigns; linked-file movement is explicit) but never says what is destroyed or overwritten — e.g. whether an existing project membership is replaced — which matters for a destructive 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?

Three short sentences, front-loaded with the action, no filler. The final clause 'Linked file movement is explicit' is terse to the point of being cryptic, slightly weakening an otherwise tight statement.

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 destructive, non-idempotent mutation with no output schema and no per-parameter schema docs, the description covers the assign/unassign contract but omits permission requirements, whether existing assignments are overwritten, and batch-size/limit expectations (500 ids, 6 resource groups). Adequate but with clear 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?

With 0% schema description coverage the description must carry the parameter burden. It explains target_project_id's null behavior well, and the four resource types it names match the type enum, but 'Linked file movement is explicit' leaves move_linked_files ambiguous (default value? required flag?) and the resources array structure is not described.

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

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

States a specific verb ('Move ... into a project') and enumerates the exact resource types (jobs, files, workflows, workflow runs), so the agent can distinguish it from create_project, list_projects, and the per-resource mutation tools in the sibling list. The unassign clause further pins down scope.

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

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

Gives explicit conditions for the assign and unassign directions ('Set target_project_id to null to unassign') and flags that linked-file movement is treated specially. It does not name an alternative tool, but no sibling is a plausible substitute for project assignment.

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 flag destructiveHint=true, so the safety profile is covered structurally. The description adds genuine behavioral nuance: queued jobs cancel cleanly, running jobs stop only if the underlying tool supports it, and the idempotentHint=false is implicitly respected. It earns credit for explaining what cancellation actually does, though it doesn't state the resulting state of a partially-stopped job.

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 the core action front-loaded, the queued/running distinction in the middle, and the sibling routing at the end. Every clause carries information; no 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 single-param mutation tool with no output schema, the description covers the action, its limits, and the alternative path. It stops short of stating the eligibility condition for 'eligible' or the post-cancel state, which would make it 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?

With a single required job_id and 0% schema description coverage, the burden falls on the description, which only gestures at an 'eligible individual job' without clarifying format, eligibility criteria, or how to obtain the id. The parameter name is fairly self-evident, so this is marginal rather than absent, landing at baseline 3.

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

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

States a specific verb and resource ('Cancel an eligible individual job') and explicitly scopes it against the workflow-owned case by naming the sibling cancel_workflow_run. An agent can distinguish it from cancel_workflow_run without opening either schema.

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

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

Gives explicit when-to-use ('queued jobs can be cancelled') and when-not ('Cancel workflow-owned jobs through cancel_workflow_run'), plus the running-job caveat. Routing to the correct sibling is fully specified.

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 destructiveHint=true and readOnlyHint=false, so the mutation risk is covered structurally. The description adds real value beyond them by disclosing that cancellation returns billing metadata and that only active runs are eligible, which an agent needs to anticipate the side effect and the precondition.

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 the action first and the notable side effect second. No filler, no redundancy.

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 destructive tool with no output schema, the description conveys the key return hint (billing metadata) and the active-run precondition, but omits whether cancellation is reversible, idempotent, or what error surfaces on a non-active run. Adequate but with clear gaps given the destructive nature.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents run_id fully. The description's 'active workflow run' merely echoes the schema wording and adds no format, sourcing, or retrieval guidance, so it sits at 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?

States a specific verb (cancel) and resource (workflow run), and distinguishes itself from sibling mutators like retry_workflow_run and continue_workflow_run by the 'active' qualifier. It also signals a side effect (billing metadata), though it doesn't name a sibling it is explicitly not.

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 when-to-use guidance, no prerequisites (e.g., run must be in an active state), and no contrast with alternatives such as retry_workflow_run or cancel_job. The agent must infer applicability from the name and the word 'active' alone.

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 establish that this is a non-read-only, non-destructive, closed-world mutation, so the safety profile is partly covered. The description adds the sequencing requirement at curation checkpoints, but says nothing about what continuation does to the run, credit consumption, or reversibility. With annotations carrying part of the burden, a 3 is appropriate.

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

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

Two short sentences, purpose front-loaded, no filler. Every clause contributes either the action or the checkpoint prerequisite.

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 mutation with annotations but no output schema, the description covers purpose and the key curation prerequisite adequately. Minor gaps remain around what the continuation returns and the general precondition for non-curation paused runs, but nothing critical to calling it correctly is absent.

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 100%, so the baseline is 3. The description goes beyond the schema by stating that candidate_set_digest and approved_candidate_ids must first be obtained from the workflow run curation API and supplied together at a curation checkpoint, clarifying a cross-parameter dependency the schema alone does not express.

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

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

States a specific verb + resource ('Continue a paused workflow run'), which distinguishes it from the read-oriented siblings like get_workflow_run and the terminal siblings cancel_workflow_run. It does not, however, explicitly contrast with retry_workflow_run or start_workflow, leaving some ambiguity about which resume path applies.

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

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

The description implies usage context by naming the curation checkpoint case and telling the agent what to supply at that point. It gives no guidance on when to use this versus retry_workflow_run or start_workflow, nor on the preconditions for resuming a non-curation paused run.

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 this is a non-read-only, non-destructive, non-idempotent, closed-world operation, and the description merely restates the write intent. It adds nothing about permissions required, quotas, whether the caller becomes an owner, or what happens to an existing name collision.

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 compact sentence with the action front-loaded and no filler. Appropriately sized for what it says, even though it says too little.

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 mutation tool with no output schema and zero parameter documentation, the description omits the return value, permission requirements, and parameter meaning. It is far short of what an agent needs to invoke it confidently.

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% across 2 parameters, so the description was the only place to explain 'name' (required, 1-80 chars) and optional 'description' (max 500). It mentions neither, leaving both parameters semantically bare.

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

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

The description gives a clear verb (Create) and resource (workspace project) plus a brief rationale ('to organize scientific work'). It is distinguishable from siblings like list_projects or assign_project through the 'create' verb, though it never explicitly contrasts them.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as assign_project or list_projects. An agent gets no signal about when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds value beyond those: the draft is created disabled by default and no credits are spent, which is meaningful cost/mutation context for a create operation. It does not, however, describe what happens on name collisions or whether repeated calls stack drafts.

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

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

Three short sentences, zero filler, and the most decision-relevant fact (it saves a disabled draft, not a published workflow) is front-loaded. 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?

For a create tool with no output schema and opaque nested input objects, the description covers the workflow sequence and safety profile well but leaves parameter semantics almost entirely to the referenced schema tool. Adequate for orchestration, incomplete for construction of the definition payload.

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 5 parameters with 0% description coverage, two of them (definition, settings) are opaque nested objects, and the description explains none of them. The only partial compensation is the instruction to read get_workflow_schema first, which hints at how definition should be built, but name, project_id, and description semantics are entirely undocumented.

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

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

States a specific verb and resource with scope: 'Save a new disabled workflow draft.' Immediately distinguishes itself from publish_workflow ('does not publish'), validate_workflow, and update_workflow by naming the draft state. An agent knows exactly which lifecycle stage this tool occupies.

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

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

Gives an explicit ordered procedure: read get_workflow_schema first, validate the draft, then publish explicitly. It names the prerequisite sibling and the follow-up sibling, and implies the exclusion (this tool does not publish). Nothing about when to use this vs. alternatives is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds payload-level context (which account attributes are exposed) plus a pre-flight timing hint, which goes 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?

Two short sentences, fully front-loaded: capability first, call-timing hint second. No filler, no restatement of the name or annotations.

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 rich annotations and no input schema, the description usefully compensates for the absent output schema by naming the returned fields. It does not describe output format (e.g., credit units, scope representation), a minor omission for a zero-arg read.

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

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

The tool takes zero parameters, so the schema imposes nothing to document; the baseline for 0 params is 4. The description adds no param detail, but none is needed.

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

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

States a clear verb ('Read') and enumerates the exact resources returned: workspace, credits, concurrency limits, granted scopes. No sibling tool covers account-level state, so it is trivially distinguishable from the workflow/job/file 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?

'Check before planning paid work' gives a concrete call condition tied to a decision point. It stops short of naming exclusions or alternatives, but none exist among the siblings, so the gap is minor.

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 and openWorldHint=false, so the safety profile is fully covered. The description adds one genuine behavioral fact — this returns metadata rather than file content — but stops there, saying nothing about pagination, size limits, or failure behavior on a missing ID.

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 six-word sentence with zero redundancy and the resource stated first. It is efficiently sized, though the extreme brevity leaves no structure to speak of beyond the one clause.

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

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

There is no output schema, so the description is the only place an agent could learn the shape of the returned metadata, and it does not say what fields come back or what a failed lookup returns. For a simple single-parameter read tool the gap is modest but real.

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

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

Schema description coverage is 100% and there is a single required parameter, so the schema already carries parameter meaning; baseline is 3. The description adds only that the ID refers to a ProteinIQ file, which the schema field text already states.

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

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

The description gives a specific verb and resource ('Fetch metadata for one ProteinIQ file'), and the word 'metadata' usefully distinguishes it from a content-retrieval sibling like read_file. However, it never names or contrasts with list_files or read_file, so the agent must infer the boundary between listing, reading content, and reading metadata.

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 list_files (to discover IDs) or read_file (to get file contents). No prerequisites, no mention of what happens when the file_id is unknown or the file is inaccessible.

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

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

Annotations already cover safety (readOnlyHint, destructiveHint, openWorldHint), so the description need not repeat that. It adds that status and metadata are returned, which is mildly useful, but omits error behavior for invalid job IDs and return format nuances.

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 sentence, no waste, front-loaded with the action and target. Appropriate for a simple fetch-by-ID tool.

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 simple getter with full schema and read-only annotations, but lacks return-value hints (no output schema) and doesn't distinguish from sibling retrieval tools, leaving some ambiguity.

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 100% and the single job_id parameter is fully documented in the schema. The description adds no additional parameter semantics beyond the schema, so baseline 3 applies.

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

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

States a specific verb (Fetch) and resource (status and metadata for a ProteinIQ job). Clear but does not differentiate from siblings like get_job_logs or get_result, which also retrieve job-related data.

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 when-to-use guidance, no mention of alternatives such as get_job_logs for logs or list_jobs for enumeration.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context not in the annotations: that live worker logs are not necessarily persisted as saved artifacts, warning the agent that absence of a saved log is not proof the job logged nothing.

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

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

Two short sentences, front-loaded with the primary list behavior and the filename variant, plus the caveat. No filler; 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 two behavioral modes and the persistence caveat are covered, and the annotations carry the safety profile. But with 0% schema description coverage, no output schema, and four parameters whose units and semantics (byte/line bounds) are unexplained, the definition is only adequate 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% for all four parameters, and the description only hints at 'filename' ('by exact filename') and loosely at bounds ('bounded preview'). It does not explain job_id, max_bytes, or max_lines, nor why max_bytes/max_lines are required despite having defaults, so it fails to compensate for the schema gap.

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 resource (saved log artifacts for a job) and clearly distinguishes two modes: listing artifacts vs. reading a bounded preview by exact filename. It is much more informative than the bare name, though it never explicitly contrasts itself with the nearby read_job_file or get_job siblings.

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 two modes are implied by the presence or absence of a filename, which gives the agent an implicit rule for choosing between them. However, there is no explicit when-to-use guidance relative to siblings like read_job_file or get_result, and no stated prerequisites.

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 this a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real value beyond them: output is structured data plus signed file URLs, and MCP-Apps clients render a result card. It omits what happens for an incomplete or failed job, which is the main residual gap.

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

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

Two tight sentences with the core purpose front-loaded and the client-rendering note trailing. Every clause carries information and nothing is padded.

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

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

There is no output schema, so the description carries the return-value burden and does so adequately by specifying structured output plus signed file URLs. It falls just short of complete because it never addresses the failure/premature-call case for a job that is not yet completed.

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 a single parameter at 100% schema description coverage, the schema already defines job_id, so baseline 3 applies. The description adds only the implicit constraint that the ID must reference a completed job, no format or sourcing detail beyond that.

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

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

States a specific verb ('Fetch') and resource ('structured output and signed file URLs') and scopes it to 'a completed ProteinIQ job,' so the operation is unambiguous. It does not, however, differentiate itself from close siblings like get_job or get_workflow_results, leaving the agent to infer which getter to call.

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 a completed ProteinIQ job' implies the prerequisite that the job must have finished, which is useful implied guidance. But it never states what to use instead when the job is still running (get_job?) or names any alternative result-retrieval tool such as get_workflow_results.

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, and openWorldHint=false, so the safety profile is covered. The description adds value by listing the categories of information returned, but does not expand on auth needs, rate limits, or output format beyond those categories.

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. It states the action, scope, and returned content efficiently.

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 tool with complete parameter documentation and annotations that cover safety, the description sufficiently explains what the tool returns. It could be slightly stronger by clarifying when to prefer it over list_tools or get_workflow_tool, but the core behavior is clear.

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

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

Schema description coverage is 100%, and the single parameter's meaning is fully documented in the schema. The description does not add syntax, format, or additional meaning beyond what the schema already provides, so the baseline of 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 uses a specific verb ('Inspect') and resource ('one ProteinIQ tool'), and lists the data returned (accepted inputs, settings, outputs, credit model). It implicitly distinguishes itself from list_tools by focusing on a single tool, though it does not explicitly name alternative siblings.

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

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

Usage is implied: the tool retrieves details for a specific tool, likely after listing tools. However, there is no explicit when-to-use guidance, no when-not-to-use exclusions, and no named alternatives such as list_tools or get_workflow_tool.

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=false, and destructiveHint=false, so the safety profile is clear. The description adds useful context about what is retrieved ('workflow graph and its public execution configuration') but does not disclose auth needs, error behavior, or failure modes.

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, front-loaded sentence with no wasted words. It immediately states the action and the object being inspected.

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

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

For a simple read tool with annotations covering safety and a fully documented parameter, the description is minimally adequate. However, without an output schema, it does not explain return shape, not-found behavior, or how the returned graph relates to draft/curation variants.

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

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

Schema description coverage is 100%, and the single required workflow_id parameter is documented in the schema. The description adds no syntax, format, or usage detail beyond what the schema already provides, so the baseline of 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 states a clear verb ('Inspect') and resource scope ('workflow graph and its public execution configuration'). It is more specific than the tool name alone, but it does not distinguish this tool from siblings such as get_workflow_draft or get_workflow_schema.

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

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

No when-to-use guidance, prerequisites, or alternatives are provided. The agent can infer this is a by-ID retrieval tool, but there is no explicit routing information versus the many workflow-related 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, which the description does not contradict. However the description adds no behavioral context beyond the annotations – it does not say whether the run must be in a specific state, whether the checkpoint expires, or what happens if called on a non-paused run. With annotations covering safety, only the read-only aspect is fully transparent.

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 that names the return content first (candidate IDs, scientific previews, digest) and then the condition (workflow run paused for curation). 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?

There is no output schema, so the description usefully enumerates what is returned (candidate IDs, previews, digest). But it omits when the checkpoint exists, what to do after reading (e.g., use continue_workflow_run), and any constraint on calling it. For a read tool in a curation workflow, this is adequate but 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?

There is 1 parameter and schema description coverage is 100% ('Paused workflow run ID'), so the schema already defines the parameter fully. The description mentions 'a workflow run' and 'paused for curation', which is consistent with the schema but adds no syntax or format detail beyond it. Baseline 3 is appropriate when the schema carries the parameter documentation.

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

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

States a specific verb (read) and the exact resource content (candidate IDs, scientific previews, candidate-set digest) for a paused workflow run. This distinguishes it from get_workflow_run or get_workflow_results, which would not mention curation checkpoints.

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 'paused for curation' implies the tool is only useful when a workflow run has entered a curation checkpoint state, but it does not explicitly state when to use this versus siblings like get_workflow_run or continue_workflow_run. The condition is implied rather than spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses that access/permission checks are performed and that unpublished draft content is returned – behavior the annotations do not 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?

A single front-loaded sentence with no filler; the key action and scope come first. The trailing qualifiers ('with access checks, including unpublished work') are dense but each carries distinct 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 single-parameter read tool whose annotations already cover the safety profile and which has no output schema to explain, the description supplies the essential behavioral context (access checks, draft inclusion). The main omission is any explicit routing versus sibling read tools, which is a minor 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?

Only one parameter (workflow_id) with 0% schema description coverage, and the description adds no format, constraint, or source guidance for it. The name is largely self-explanatory, so it is adequate, but it does not compensate for the coverage gap.

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

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

States a specific verb (Read) and resource (a workflow and its current editable definition), and adds the scope qualifier 'unpublished work' plus 'access checks'. This distinguishes it reasonably from the published-version-oriented get_workflow and the list-style list_workflow_drafts, though it never names those siblings explicitly.

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

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

Usage is implied by 'editable definition' and 'including unpublished work' – an agent can infer this is for draft, not published, content. But there is no explicit statement of when to prefer this over get_workflow or list_workflow_drafts, and no prerequisites beyond the vague 'access checks'.

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, destructiveHint=false, and a closed-world scope, so the safety profile is covered. The description adds only that results are authorization-scoped ('authorized child result links'), which is useful but thin; it says nothing about pagination, truncation, or what happens if the run is incomplete.

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 front-loaded sentence with no filler. It is efficient, though its brevity is partly the reason the usage and behavioral gaps exist.

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-required-parameter read tool with no output schema, the description roughly covers the return shape (metadata plus child result links) and the safety profile comes from annotations. Missing are run-state caveats and how this relates to sibling retrieval tools, so 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?

With a single parameter at 100% schema description coverage, the schema fully documents run_id, so the baseline of 3 applies. The description adds no format, sourcing, or validity detail beyond the schema (e.g., where to obtain a run_id).

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

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

States a specific verb (read) and resource (workflow result metadata plus authorized child result links), which is clearer than a bare 'get results'. It does not, however, distinguish itself from near-siblings like get_result or get_workflow_run, leaving ambiguity about which retrieval tool applies.

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

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

There is no guidance on when to use this tool versus get_result, get_workflow_run, or read_job_file, and no mention of prerequisites such as run authorization. The agent must infer the selection from the tool name alone.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful content context by naming the returned data (status, nodes, child-job metadata), but it does not cover pagination, error behavior, or auth requirements.

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 efficient sentence with the resource and returned data front-loaded. Every word contributes to identifying the tool's purpose.

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 read tool, the description is mostly complete: it identifies the resource and the kind of data returned, and annotations cover the safety profile. The absence of output schema is partly offset by naming status, nodes, and child-job metadata.

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

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

Schema description coverage is 100% for the single run_id parameter, so the schema already documents the parameter fully. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 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 states a specific verb (Read) and resource (workflow run), plus the exact data returned: status, nodes, and child-job metadata. It is clearly distinguishable from a list operation, though it does not explicitly name sibling tools such as list_workflow_runs or get_job.

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 when-to-use guidance and does not compare this tool with alternatives like list_workflow_runs, get_job, or get_workflow_results. Usage is implied by the verb 'Read', but there are no exclusions or selection conditions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds useful reference-oriented context by calling the schemas "authoritative" and clarifying that it is not the source for scientific settings or ports. It does not describe return format, but with no output schema and strong annotations, that is a minor gap.

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

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

Two sentences with no wasted words. The prerequisite timing is front-loaded, followed by routing guidance for related data.

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

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

For a zero-parameter read tool with rich annotations and no output schema, the description fully positions the tool in the workflow authoring sequence and identifies where complementary information lives.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameters for the description to clarify.

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 ("Read") and names the exact resources: authoritative graph/settings schemas and authoring instructions. It also scopes the tool to the pre-creation phase, distinguishing it from siblings like get_tool and get_workflow_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 explicitly says to read this before creating a workflow and routes the agent to get_tool for scientific settings and get_workflow_tool for exact ports. This gives clear when-to-use guidance and names alternatives for related data.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered externally. The description adds useful context about what is inspected ('resolved' workflow ports vs. the direct-job schema), but says nothing about permissions, failure modes, or return shape.

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 purpose is front-loaded and the disambiguating clause follows. Slightly cryptic wording ('direct-job input schema') costs it the top mark.

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 inspection tool whose safety profile is covered by annotations and which has no output schema, the description adequately conveys purpose. However, it leaves both the identifier format and the returned 'resolved ports' shape unexplained, which an agent would need to call it confidently.

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% for the single 'tool' parameter, and the description only implies it is 'a scientific tool' without clarifying whether the value is a name, ID, path, or version. With the schema doing no work here, the description fails to compensate for the gap.

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 ('Inspect') and a precise resource ('a scientific tool with its resolved workflow input/output ports'), which is more informative than a bare 'get tool'. It distinguishes itself from the direct-job schema view, though it never names the sibling tool that provides that alternative, so the differentiation is implicit.

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 gives a clear situational trigger ('before connecting graph nodes') and clarifies when the direct-job input schema is not what you want. There are no explicit exclusions or named alternative tools (e.g., get_tool), keeping it short of a 5.

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=false, and destructiveHint=false, so the safety profile is covered. The description adds essentially nothing beyond that — it notes the workspace is 'authenticated' but does not disclose pagination behavior, default result ordering, default limit, or that all filters are optional and combinable.

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 zero filler, which is appropriate for a simple list tool. It is efficient, though it is arguably too terse given the 7 parameters it silently supports.

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

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

With no output schema, the description should at least sketch the returned shape or pagination contract, especially since a starting_after cursor implies paged results. An agent can call it correctly from the schema alone, but the description leaves the response model entirely unstated.

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

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

Schema description coverage is 100% across all 7 optional parameters, so the schema fully documents filters, cursor, and limit on its own. The description adds no syntax, default values, or interaction rules (e.g. how q relates to format/origin), so baseline 3 applies.

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

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

States a specific verb ('List') and resource ('files') scoped to the authenticated ProteinIQ workspace, which is clear on its own. However, it does nothing to distinguish itself from sibling read tools like get_file, read_file, or read_job_file, so the agent gets no help disambiguating list-vs-fetch semantics.

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 choose this tool over siblings such as get_file or read_file, nor any mention of how the optional filters should be combined. The description is purely a restatement of what the tool returns.

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 and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts — results are workspace-scoped and pagination is cursor-based — but says nothing about ordering, default limit, or the cursor mechanics.

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 resource and filter facets come first and pagination is appended as a trailing qualifier.

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 read-only list tool with no output schema and 8 parameters, the description is adequate but incomplete: it never mentions the required limit parameter or what shape the returned job list takes, and pagination behavior is only hinted at.

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 carry the params, and it does name five of the eight facets (q, tool, status, project_id, created_after/created_before). However it omits 'limit' (required, max 100) and gives no format details for the date bounds or the starting_after cursor beyond the phrase 'cursor pagination'.

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 ('Find') and resource ('workspace jobs') and enumerates the filterable facets (name, scientific tool, status, project, date). It clearly reads as a collection-listing tool distinct from the singular get_job, though it does not explicitly call out that distinction.

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

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

Usage is only implied: an agent can infer 'use this to search/list jobs by these facets' but there is no explicit when-to-use versus get_job or list_workflow_runs, and no stated 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 readOnly, idempotent, non-destructive, closed-world. The description adds that the result is IDs usable in downstream filters/assignments, but says nothing about pagination behavior or result size beyond that. Some added value, 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 padding; the core capability is stated immediately.

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?

No output schema exists, so the description partially covers returns by mentioning IDs, but it omits pagination (starting_after/limit) which an agent needs to page correctly. Adequate but with a clear gap for a paged list 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 coverage is 0% and there are 3 parameters. The description hints at name-based lookup (the 'q' param) but entirely omits 'limit' (required, max 100) and 'starting_after' pagination. It does not compensate for the documentation gap.

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

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

States a specific verb (Find) and resource (workspace projects), plus the practical purpose of retrieving IDs. It is distinguishable from create_project and assign_project, though it never explicitly contrasts itself with those siblings.

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

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

It implies when to use it ('for job filters and assignments') but gives no when-not guidance and names no alternatives. An agent can infer the context but must reason about it rather than being told.

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, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — 'available through the public job API' is vague and says nothing about ranking, pagination, or result shape for a mutation-free catalog read.

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 short sentence with no filler and the resource front-loaded. It is efficient, though its brevity shades into under-specification rather than well-targeted concision.

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 six-parameter tool with two required params, no output schema, and no enum guidance, the description should clarify filter semantics and pagination. It omits all of this, so an agent lacks what it needs to drive the query parameters 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 coverage is only 33%: q and task are documented, but tag, category, limit, and offset carry no schema descriptions. The description mentions no parameters at all, so it does not compensate for the gap — an agent cannot tell from either source what 'tag' or 'category' accept.

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

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

States a clear verb+resource ('List ProteinIQ tools'), which is unambiguous on its own. However, it never distinguishes itself from the singular sibling get_tool or from the other list_* catalog tools, leaving the agent to infer the scope is a full directory listing.

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 when-to-use guidance is given: nothing says when to call this versus get_tool or get_workflow_tool, and nothing explains that the q/tag/task/category parameters turn it into a search/discovery tool rather than a plain enumeration. The agent must guess the intended discovery workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful fact beyond the annotations: results include unpublished drafts. It says nothing about pagination behavior despite limit/offset being required.

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

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

Two short sentences, zero waste, with the inclusion-of-drafts fact front-loaded ahead of the follow-up guidance.

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?

No output schema, so the description need not explain returns, and annotations cover the safety profile. However, with 0% parameter documentation and a required limit/offset pagination contract, an agent lacks enough to call this correctly without inspecting the schema.

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 none of the four parameters (q, limit, offset, project_id) are mentioned or explained in the description. With low coverage the description must compensate, and it does not.

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

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

Specific verb+resource: listing accessible workflows, with a scoping qualifier that it includes unpublished drafts. This implicitly distinguishes it from list_workflows, though the contrast is never stated explicitly.

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

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

Names a concrete follow-up path (use get_workflow_draft before editing), which orients the agent in the workflow lifecycle. It does not, however, state when to prefer this over the sibling list_workflows.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: results are 'compact summaries, not result payloads' (output shape) and only 'accessible' runs are returned (permission scoping).

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, zero filler, with the core action and filters front-loaded and the output caveat placed last. Nothing can be cut without losing 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 read-only list tool with annotations covering safety and no output schema, the description is adequate but leaves pagination (limit/offset are required and undocumented), ordering, and the exact meaning of 'accessible' unstated.

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 carry parameter meaning. It names status, workflow, project, date and name, which maps to status, workflow_id, project_id, created_after/before and q, but it omits the required limit/offset pagination params and gives no format or matching-syntax detail.

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

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

States a clear verb ('Find') plus resource ('workflow and batch runs') and enumerates the filter dimensions. It also implicitly separates itself from result-fetching siblings with 'not result payloads', though it does not name list_jobs or get_workflow_run directly.

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 filter list implies when the tool is useful (searching runs by status/workflow/project/date/name), but there is no explicit guidance on when to prefer this over list_jobs, get_workflow_run, or get_workflow_results, and no stated prerequisites.

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, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only that results are scoped to the authenticated workspace; it says nothing about ordering, pagination behavior beyond the schema fields, or result volume.

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 tight sentence with the resource and scope front-loaded and zero filler. Nothing could be trimmed without losing 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 read-only list tool with full schema coverage and annotations, the description is minimally adequate. It omits any mention of pagination workflow or how results relate to workflow drafts/runs, which would help an agent use it correctly in this crowded sibling set.

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

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

Schema description coverage is 100%, so both limit and starting_after are already fully documented in the schema. The description contributes no additional parameter meaning, making the baseline 3 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?

States a clear verb (List) and resource (workflows) scoped to the authenticated ProteinIQ workspace. However, it does not distinguish this tool from close siblings such as list_workflow_drafts or list_workflow_runs, which an agent must infer from the noun alone.

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 versus list_workflow_drafts, list_workflow_runs, or get_workflow. No prerequisites or exclusion conditions are stated; the agent must infer usage entirely from the 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 only declare the generic safety flags (not read-only, not destructive, not idempotent). The description adds real behavior beyond them: the result is an immutable revision, no run is started, no compute is spent, and user approval is a gating condition. It stops short of stating what happens on a repeated publish or when expectedDraftVersion is stale.

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

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

Three short sentences, front-loaded with the action, followed by the negative scope and the precondition. Every sentence earns its place with no padding.

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?

Behavioral context is solid for a non-idempotent mutation, but with 0% parameter coverage and no output schema, the agent is left without guidance on what expectedDraftVersion must match or what a successful publish returns. Adequate but with clear 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?

Schema description coverage is 0% and both parameters are required, so the description carries the full explanatory burden. It says nothing about workflow_id or expectedDraftVersion, leaving the optimistic-concurrency semantics of the version parameter entirely undocumented.

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

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

States a specific verb and resource ('Validate and publish the current draft as an immutable revision') and immediately delimits scope against the run-oriented siblings ('Does not start a run or spend compute'). An agent can separate this from validate_workflow and start_workflow without opening any schema.

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

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

Gives an explicit precondition: 'Publish only after the user has approved the intended workflow.' It also rules out run execution, which is useful context. It does not, however, name alternatives such as validate_workflow for a dry check or update_workflow for editing the draft.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing that no credits are spent or reserved and by naming the output field (blocking_errors) and the downstream field (max_quoted_credits), which is genuinely useful behavioral context.

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 sentences, all load-bearing, with the purpose front-loaded and the workflow/constraint following. No 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?

There is no output schema, and the description compensates by telling the agent to inspect blocking_errors. For a validate-and-estimate tool it is largely complete, though the opaque nested 'input' object and the required 'tool' parameter remain unexplained.

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

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

Schema description coverage is 0% for four parameters, so the description carries the burden. It gestures at 'scientific input/settings' and a credit budget, but the required 'tool' parameter is never mentioned, and the description's 'max_quoted_credits' does not match either billing field name in the schema, leaving the mapping ambiguous.

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

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

Specific compound verb (validate + estimate credits) applied to a specific resource (scientific input/settings), with an explicit negative scope ('without submitting or spending'). This cleanly separates it from the submit_job sibling, which is the operation it feeds into.

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 states the exact workflow: inspect blocking_errors, then pass the accepted amount as max_quoted_credits to submit_job. It also names the boundary condition ('a quote does not reserve credits'), so an agent knows this cannot replace an actual submission.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: that returned content is untrusted data (a prompt-injection warning) and that output is a bounded preview rather than the whole file. It stops short of describing truncation behavior in detail.

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

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

Three short sentences, zero filler, and the core purpose is front-loaded before the untrusted-content caveat and the binary-file exclusion. Every sentence 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?

With no output schema and annotations covering safety, the description does reasonably well on what is returned (a bounded UTF-8 preview) and on the binary-file escape hatch. The gap is the three undocumented numeric parameters, which forces the agent to infer limits from the schema alone.

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

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

Schema description coverage is 0% for three required parameters and the description never names or explains file_id, max_bytes or max_lines. The word 'bounded' hints that limits exist, but an agent gets no guidance on units, defaults or truncation semantics from the description, so it does not compensate for the coverage gap.

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

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

States a specific verb and resource ('Read ... a workspace file') and scopes it precisely as a 'bounded UTF-8 preview', which separates it from get_file and list_files. It does not explicitly name those siblings, but the preview framing is enough to distinguish intent.

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 gives one clear when-not: binary files must be downloaded using their file URL, which steers the agent elsewhere. However it never names the alternative tool, nor does it say when this tool is preferred over get_file or read_job_file. Usage guidance is implied rather than explicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description adds real value: the read is a BOUNDED preview (not the whole file), the encoding is UTF-8, and the returned content is untrusted data. It omits truncation/return-shape details, but the security and scope disclosures are substantive.

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

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

Three short sentences, each earning its place, with the core action and scope front-loaded ahead of the usage constraint and safety warning. 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?

Covers the origin of the filename, the preview/bounded nature, and the untrusted-content caveat, but with 0% schema description coverage, four required parameters, and no output schema, the definition leaves parameter meaning and output limits unexplained. Adequate but with clear gaps for a four-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 description coverage is 0% and the description explains none of the four parameters. 'Bounded' and 'preview' hint at max_bytes/max_lines but never name or clarify them, and job_id is entirely unspecified. With the schema doing no work here, the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource (read/bounded UTF-8 preview of a job file) and ties the file to get_result as its source, which helps separate it from generic siblings like read_file and get_file. It does not explicitly name those siblings, so differentiation is implied rather than stated.

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

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

Gives a clear precondition ('exact file name returned by get_result') and an explicit prohibition ('Never invent paths'), which tells the agent exactly where the filename must come from. It stops short of naming alternatives (read_file, list_files) or stating when this tool is preferred over them.

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 this is a non-read-only, non-destructive, non-open-world write, so the safety profile is covered. The description adds the 'safe' framing (consistent with the required idempotency key) and the start-vs-failed-node choice, but is silent on what actually happens to the original run and whether a new attempt is created.

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 short sentence with the retry scope front-loaded and no filler. It is efficient, though so terse that it borders on under-specification for a mutation tool.

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 four-parameter write operation with no output schema and no annotations describing effects, the description omits critical behavior: whether a new run is created, what happens to the terminal run, and how credit ceilings interact with the parent. The schema documents parameters but not the mutation's consequences.

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

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

Schema description coverage is 100%, so baseline is 3. The description echoes from_node_id semantics ('from the start or a failed node') but adds nothing about max_credits inheritance or the idempotency key's stability requirement beyond what the schema already states.

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

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

States a clear verb (retry) and resource (workflow run) and adds scope ('from the start or a failed node'). It does not differentiate from close siblings like continue_workflow_run or get_workflow_run, but the core action is unambiguous.

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

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

No explicit when-to-use guidance, prerequisites, or alternatives are given. The agent must infer from the name and the schema's 'Terminal workflow run ID' hint that this applies only to finished/failed runs and is not the same as continue_workflow_run.

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 destructiveHint=true, readOnlyHint=false, and non-idempotency, so the safety profile is covered. The description adds the manage-access authorization requirement and clarifies that toggling state does not trigger execution, both of which are behavioral facts not visible in the annotations or schema.

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

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

Three short sentences, front-loaded with the action, followed by prerequisite and the key non-behavior. No filler or repetition of the name.

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

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

For a simple two-parameter mutation with full annotation coverage and no output schema, the description covers the action, access requirement, and a critical behavioral caveat. It omits what the tool returns or how it affects in-flight runs, which is a minor gap rather than a blocking one.

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 two parameters (workflow_id, enabled) are undocumented in the schema. The description implies the boolean toggle via 'enable or disable' and constrains workflow_id to published workflows, but does not explain identifier format or failure behavior, so it only 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?

States a specific verb pair (enable/disable) and the resource (published workflow), which distinguishes it from start_workflow and publish_workflow. It does not explicitly reference a sibling, but the 'published workflow' scope is precise enough to identify the target object.

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?

'Requires manage access' gives a prerequisite and 'Does not start a run' rules out the most likely confusion with start_workflow. It stops short of naming the alternative explicitly, but the exclusion provides clear context for when this tool is and isn't appropriate.

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 this is a non-read-only, non-destructive, closed-world operation, so the safety profile is covered. The description adds essentially nothing beyond that: it doesn't mention credit consumption (max_credits exists), what happens on idempotency-key reuse, or that a changed revision produces a conflict.

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 short sentence with no filler and the key qualifiers front-loaded. It is efficient, though arguably under-sized for a 7-parameter mutation tool.

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 mutation tool with a nested input object, a required idempotency key, an optional revision guard, and a credit ceiling, and with no output schema, the description omits what a run start produces, how retries behave, and how revision conflicts surface. Substantial gaps remain.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema, giving a baseline of 3. The description restates 'inputs' and 'idempotency key' without adding format, constraint, or conflict semantics beyond what the schema says.

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

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

States a specific verb and resource ('Start a workflow run') with a scope qualifier ('explicit inputs and an idempotency key'). It does not distinguish itself from close siblings like continue_workflow_run or retry_workflow_run, which an agent must infer from elsewhere.

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 statement of when to use this versus continue_workflow_run, retry_workflow_run, submit_job, or submit_batch, all of which live in the same sibling set. The agent gets no routing guidance beyond the 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 declare the safety profile (readOnlyHint=false, destructiveHint=false), but the description adds meaningful behavioral context beyond them: the requirement for an explicit spending limit and the idempotency-key retry contract. The idempotentHint=false annotation is mildly in tension with the stated safe-retry guidance, though the key parameter plausibly explains the mechanism rather than contradicting it.

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 tight sentences with the core action front-loaded and no filler. The retry guidance is associated with the idempotency key in a natural reading 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 an 8-parameter mutation tool with nested objects, 0% schema coverage and no output schema, the description addresses the highest-risk concerns (spending cap, idempotent retry, where results/cancellation live) but leaves the batch-specific semantics like combination_mode and project/input scoping unexplained.

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

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

Schema description coverage is 0%, so the description must carry the burden for all 8 parameters. It only clarifies two of them (max_credits as 'spending limit' and idempotency_key as 'stable idempotency key'); tool, name, input, settings, project_id and the zip/cartesian combination_mode enum are entirely unexplained in both schema and 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 gives a specific verb+resource ('Submit a single-tool batch') and frames the engine it runs on, so the agent knows this dispatches a batch when a single tool runs. It does not, however, differentiate itself from the sibling submit_job, which is the most likely source of confusion.

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 real guidance on retry behavior ('Reuse the same key and exact request after an uncertain response') and routes result/cancel handling to 'workflow run actions'. However, it never states when to prefer this over submit_job or start_workflow, leaving alternative selection 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 the write-but-not-destructive safety profile, and the description adds the key trait that execution is asynchronous and that a job ID is returned for polling. It omits the credit/billing consumption behavior that the schema's billing and max_quoted_credits params imply, which is relevant for a submission that spends resources.

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 zero filler; the core action is front-loaded and the follow-up guidance follows immediately. 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?

For an 8-parameter, deeply nested job-submission tool with no output schema, the description is thin: it does not explain the tool/input contract, the cost/credit implications, or how it relates to quote_job and submit_batch. It covers the return flow but little else an agent needs to submit 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 100%, so every parameter (tool, name, input, billing, settings, project_id, idempotency_key, max_quoted_credits) is already documented in the schema. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ('Submit an asynchronous ProteinIQ job') and names the follow-up tools, so the agent knows this creates a job. However it never distinguishes itself from the close sibling submit_batch, nor from quote_job which precedes submission.

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 'asynchronous' framing implies the usage context (long-running work you poll later), and it names get_job/get_result as follow-ups. But there is no explicit when-to-use vs submit_batch or quote_job, and no stated 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 destructiveHint=true and non-idempotent behavior, so safety is partly covered. The description still adds real value by scoping the mutation to the draft only, confirming no published revision is touched and no work is started, plus the read-before-write requirement. It does not say what happens to omitted fields or why destructiveHint is set, leaving a gap.

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

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

Three short sentences, front-loaded with the core action, then scope exclusions, then the precondition. Nothing is redundant and each sentence carries a distinct constraint.

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 scope-of-effect story is well covered, but for a destructive six-parameter mutation with no output schema and zero schema description coverage, the required baseDraftVersion token and field-merge behavior remain undocumented. Adequate at the workflow level, incomplete at the invocation level.

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% across six parameters with no definitions at all. The description says nothing about baseDraftVersion, which is a required optimistic-concurrency token whose semantics an agent cannot infer, nor about how name/settings/definition/description are merged. This is the tool's biggest documentation hole.

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

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

States a specific verb+resource ('Update an accessible workflow draft'), and immediately narrows scope by ruling out published revisions and run-starting, which implicitly distinguishes it from publish_workflow and start_workflow. It stops short of naming a sibling explicitly, so an agent must map the contrast itself.

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

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

Gives a clear precondition ('Read the current draft first') and two explicit exclusions ('Does not change an immutable published revision or start work'), which routes the agent away from publish_workflow/start_workflow. No named alternative tool is given, so it is context rather than full when/when-not routing.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered and the description is consistent with it. The description adds only the mutual-exclusivity rule across the three input modes; it says nothing about overwrite/duplicate handling, size limits, permissions, or what the caller gets back to reference the file later.

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, zero filler, with the destination and purpose front-loaded before the input constraint. Nothing is redundant with 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?

Adequate but thin for an 8-parameter mutation tool with no output schema: the agent is never told what the operation returns (e.g., a file_id needed for later get_file/read_file calls) or how collection_ids/tags affect subsequent retrieval. No required parameters are explained either, so the 'exactly one-of' rule is the only guard against a malformed call.

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

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

Schema description coverage is 100%, so the baseline is 3. The 'exactly one of file, content_base64 or content' statement does add tri-state exclusivity that the schema only partially expresses (only content warns against content_base64), but it contributes no format, size, or value details 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 verb (upload) and destination (ProteinIQ file library) plus the downstream purpose ('for later use as a saved file input'), which goes beyond the name/title. It does not explicitly contrast itself with the read-side siblings (get_file, list_files, read_file), but the action and target are unambiguous.

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

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

Usage is only implied via 'for later use as a saved file input' – an agent can infer this is the write/store counterpart to get_file/read_file, but no when-to-use condition or alternative is named. The 'provide exactly one of' sentence is an input constraint, not routing 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?

The annotations already establish read-only, idempotent, non-destructive, and closed-world behavior. The description adds that this performs validation without publishing or running and expects publication-intent inputs, but it does not describe error behavior, validation depth, or authentication requirements.

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?

It is two sentences, front-loaded with the core action and constraint, with no redundant wording. Every sentence contributes to understanding what the tool does and what it expects.

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

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

With no output schema and sparse parameter documentation, the definition leaves open what a validation result contains and how the free-form definition/settings are structured. It gives the essential pre-publication context but is not fully complete for an agent invoking or interpreting this 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 description coverage is 0% and the input includes nested free-form objects. The description names definition and settings with useful publication-intent context, but it omits workflow_id entirely and gives no structural or format guidance for any 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 states a specific verb and resource: validate a workflow draft graph and execution readiness. It also distinguishes the operation from publish and run, though it does not name a specific sibling tool to use instead.

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 clearly frames usage as pre-publication validation without publishing or running, and instructs the caller to supply the exact definition and settings intended for publication. It stops short of explicitly naming alternative tools or when-not-to-use conditions.

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