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. The description adds value by naming the categories of information surfaced (capabilities, policy defaults, runtime limits), which hints at return content, but says nothing about behavior such as cost, side effects, or freshness.

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; every word carries information about what is discovered.

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 must hint at what comes back, and it does by enumerating the three result categories. It is largely complete for a zero-parameter discovery call, though it could say whether this is a prerequisite for the other melra tools.

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

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

The tool takes zero parameters and the schema is fully described, so the baseline for this dimension is 4. There is no parameter syntax the description needs to compensate for.

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 (Discover) and a concrete set of resources (local execution capabilities, policy defaults, runtime limits). It clearly distinguishes this read-only introspection tool from actionable siblings like melra_plan and melra_execute, though it does not explicitly name a sibling.

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

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

No guidance on when to call this versus the other melra tools. The agent can infer it is an initialization/discovery step, but nothing states that it should be called before planning or that it is safe to call at any time.

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 destructive=true, idempotent=false and openWorld=true; the description adds non-obvious behavior on top: policy is re-evaluated at execution time so a looser-policy plan is still refused, the approval phrase is single-task scoped and expires, and only reads are retried. It does not describe what side effects occur or what failure returns, but the added context is genuinely useful.

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

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

Four tight sentences with no filler; the core action is front-loaded and the approval/policy caveats follow in priority order. Every sentence 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 destructive, non-idempotent, no-output-schema tool this covers the crucial operational context: the execution pipeline, approval challenge handling, and re-validation of policy. It omits failure semantics and return behavior, but the receipt-generation mention partially signals the outcome.

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 has to carry parameter meaning. It explains approval well (id plus exact phrase, scoped to one task, expiring), but says nothing about taskId beyond the schema's uuid format/pattern. Partial compensation 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 (execute) on a specific resource (one previously planned task) and enumerates the pipeline stages it runs: policy, runtime, verification, receipt generation. This cleanly separates it from melra_plan (which plans rather than executes) and from melra_task_status/melra_receipt.

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 (must be previously planned) and an explicit conditional workflow: if melra_plan returned an approval challenge, pass its id and exact phrase. It stops short of naming sibling alternatives such as melra_workflow_advance or stating when not to call it, so it is strong but not exhaustive.

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

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

Adds real behavior beyond the annotations: policy denials return as normal results with status policy_blocked and a reason rather than as errors, and nothing is executed until melra_execute. These are non-obvious outcome semantics an agent must know to interpret responses correctly.

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

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

Four tight sentences, front-loaded with the core action and the no-execution guarantee. Each sentence carries distinct information (what it does, what it doesn't, denial semantics, evidence/constraint rules) with 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?

Given a large nested schema and no output schema, the description covers the essential behavioral facts: no execution, denial-as-result, and the evidence/constraint rules. It does not describe the shape of the returned plan/approval challenge, but for a planning tool that gap is minor.

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 75%, so the schema already documents most parameters. The description's parameter-relevant content (requiredEvidence needed for non-read ops, constraints must stay empty) largely restates the existing schema descriptions for those fields, adding little syntax or format detail beyond them.

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 compound verb chain (persist a bounded task, evaluate policy, return an approval challenge) plus the key negative: it does not execute. Explicitly contrasts with the sibling melra_execute ('Nothing runs until melra_execute'), so an agent can distinguish the two 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?

Names the alternative (melra_execute) and the ordering condition that selects it, implying the plan-then-execute workflow. It also states a prerequisite rule (non-read operations need requiredEvidence). It stops short of an explicit 'use this when X, use execute when Y' routing sentence, so it is strong but not exhaustive.

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 safety is covered. The description adds nothing beyond that: it does not say what happens with zero arguments, whether both IDs may be supplied together, or what an 'execution certificate' contains.

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 verb front-loaded; nothing is wasted. It is concise but underspecified rather than complete, so it cannot score higher.

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 retrieval tool with no output schema, the description should at minimum say what comes back (receipt contents, certificate fields) and how the two optional lookup keys relate. Neither is present, leaving key caller questions unanswered.

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 two UUID parameters, and the description never mentions taskId or receiptId. It does not clarify whether the caller should pass one or the other or both, nor what each lookup key returns, so 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?

The description states a specific verb ('Retrieve') and specific resources ('action receipts and the execution certificate'), which is clearer than the title's generic 'Read MELRA evidence'. However, it does nothing to distinguish this from siblings like melra_task_status or melra_workflow_status, which an agent could easily confuse it with.

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

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

There is no statement of when to call this tool, when not to, or what alternative covers the same need. With ten sibling tools in the MELRA family, the absence of any routing guidance leaves the agent to guess.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine context the annotations cannot convey: cancellation is 'cooperative' (a request rather than a forced kill) and applies only to running or pending tasks. It stops short of describing post-cancel state transition or returned status.

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 short, front-loaded sentence with no filler – the verb and scope appear immediately. It is efficient rather than excessive, though its brevity is close to under-specification for the usage question above.

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, well-annotated mutation the definition is close to sufficient, but it omits the task-versus-workflow-routing decision that the sibling list makes necessary, and says nothing about permissions or the result of a successful cancellation.

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 a single parameter with 0% schema description coverage, so the description technically carries the full burden, but 'taskId' is self-documenting by name. The description adds nothing about the UUID format or the semantics of the identifier, leaving any added value to the schema's pattern alone.

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

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

The description names a specific verb (cancel) and resource (task), and the adverb 'cooperatively' plus the state qualifier 'running or pending' sharpen the scope beyond the bare title. It does not, however, distinguish itself from the sibling melra_workflow_cancel, leaving an agent to guess whether task-level and workflow-level cancellation are the same operation.

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 only usage signal is the implicit one embedded in 'running or pending' – there is no explicit when-to-use guidance, no statement about what happens if the task is already finished, and no mention of the alternative melra_workflow_cancel despite it being an obvious sibling for the cancellation use case.

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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description's only added disclosure is the word 'durable', hinting the state survives beyond a single call, which is marginal context. With annotations carrying the load, this meets the lower bar but adds little.

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 seven-word sentence with no filler and the action front-loaded. It is efficient, though so terse that it borders on under-specification rather than true conciseness.

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

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

There is no output schema, so the description carries the burden of explaining what 'durable state' actually contains — statuses, progress, error fields, terminal vs in-flight states. 'Read the current durable state of a task' leaves the return contract entirely unspecified for a tool whose whole purpose is inspection.

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%, but the single taskId parameter is self-documenting via type=string, format=uuid and an explicit pattern, so the agent knows exactly what to supply. The description adds no meaning about taskId (e.g. where to obtain it) beyond the schema's regex and format constraints.

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

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

States a specific verb (Read) and a specific resource (current durable state of a task), which is clearer than a tautology like 'inspect task status'. However, it does not explicitly differentiate itself from the nearby melra_workflow_status sibling, leaving the task-vs-workflow distinction to be inferred from the name.

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

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

No guidance on when to call this versus melra_workflow_status, melra_receipt, or melra_task_cancel, and no note about polling cadence for a status-check tool. 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 already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds almost no behavioral context beyond "governed": it does not warn that this is a non-idempotent mutation that can destroy prior workflow state, nor explain what "governed" means (approval gating) or what happens on partial failure. "One wave" is the only incremental-behavior hint offered.

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 a single front-loaded sentence with no padding, which is structurally sound. But it is terse to the point of under-specification rather than genuinely concise, and the jargon-laden wording costs clarity per word.

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 workflow-execution tool with approval inputs, zero schema description coverage, and no output schema, one sentence is not enough. The agent lacks the workflow-stage context and approval mechanics needed to call it correctly, though the destructive annotation and "one wave" phrasing at least convey that this is a consequential step.

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 three parameters, including two nested arrays (inputs, approvals) with structural constraints like maxItems and UUID/phrase pairing, and the description mentions no parameter at all. It does not compensate for the coverage gap in any way — an agent gets no guidance on what inputs or approvals must contain. Only the word "governed" faintly gestures at the approvals concept.

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 verb ("Execute") and a resource ("one ready workflow scheduling wave"), so the general intent is graspable. However, "scheduling wave" and "governed MELRA tasks" are unexplained jargon, and it gives no differentiation from close siblings like melra_execute or melra_workflow_control. An agent can guess it advances a workflow but cannot confidently separate it from 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?

There is no statement of when to use this tool versus melra_execute, melra_workflow_control, or melra_workflow_status, and no prerequisites (e.g., that the workflow must first be planned, or that approvals are needed). The phrase "one ready ... wave" hints at incremental stepping, but the agent must infer everything about invocation context.

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

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

Annotations already declare non-read-only, non-destructive, idempotent, closed-world behavior. The description adds real context beyond that: 'cooperatively' tells the agent this is a graceful request rather than an immediate hard kill, and the scope statement shows the cancellation cascades to child tasks of nonterminal nodes only.

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 is sized correctly for the operation, though the extreme brevity leaves useful detail (parameter, post-cancel state) unstated.

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, the description covers the what and the cooperative nature but omits whether cancellation can partially fail, what state the workflow ends in, and how to verify with melra_workflow_status. 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?

The single parameter workflowId has 0% schema description coverage - only a UUID format and regex pattern - and the description never mentions it, its format, or the requirement that it reference a nonterminal workflow. With one undocumented parameter, the description should compensate but 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?

States a specific verb (cancel) and a precise resource (nonterminal workflow nodes and their tasks), which implicitly separates it from the single-task sibling melra_task_cancel by noting the cascade to tasks. It stops short of naming any sibling for explicit differentiation.

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

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

Usage is implied rather than stated: 'nonterminal' signals the precondition that only active/running workflows can be cancelled, but the description never says when to prefer this over melra_task_cancel or melra_workflow_control, nor what to do afterwards.

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, idempotentHint=true), but the description adds genuinely useful behavioral context: node state is preserved and a resumed workflow continues from where it stopped, which is the key non-destructive guarantee an agent needs. It still omits auth requirements or whether halting affects in-flight nodes.

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, front-loaded with the core action and the state-preservation guarantee; 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?

Annotations carry the safety profile and there is no output schema, so the remaining burden is action semantics — which the description leaves incomplete. An agent can call the tool, but cannot reliably choose between pause and suspend from the definition 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% and the description adds no parameter meaning: it never explains the action enum values (pause/resume/suspend) or what workflowId refers to. The phrase 'halt... or lift a halt' only loosely implies two of the three enum options, leaving the distinction between pause and suspend undefined.

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

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

The description states a general verb+resource ('Halt a running workflow... or lift a halt'), which signals a control operation, but it collapses the schema's three distinct actions (pause, resume, suspend) into two vague modes and never defines what 'suspend' means or how it differs from 'pause'. It also does not distinguish this tool from siblings like melra_workflow_cancel or melra_workflow_advance.

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: nothing tells the agent when to choose pause vs suspend vs resume, nor when to prefer this tool over melra_workflow_cancel. The only usage hint is implicit in the word 'halt'.

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, but the description states the tool 'encrypt[s], and persist[s]' a workflow, which is a write to the plan store and therefore modifies its environment; idempotentHint=false reinforces that each call creates state. This is a direct contradiction of the read-only annotation in the dangerous direction (an agent may call it believing there are no side effects).

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 enumerating the pipeline stages with zero filler. It is efficient, though arguably under-specified rather than concise given the tool's complexity.

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

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

For a tool whose schema spans many node kinds, budgets, evidence predicates and reconciliation rules, one sentence omits what preflight actually checks, what a denial looks like, what the persisted plan's identity/return is, and how the artifact feeds melra_execute/melra_workflow_advance. No output schema exists to fill those 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?

There is a single required 'definition' parameter with 0% schema description coverage at the top level, and the description says nothing about what a valid definition must contain (required schemaVersion/id/version/name/nodes, allowed node types, forbiddenEffects/requiredEvidence rules). The enormous nested schema carries all the meaning, so 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?

The description names four concrete operations (validate, preflight, encrypt, persist) on a specific resource (a bounded workflow), which is far more informative than the title alone. The clause 'without executing it' distinguishes it from melra_execute and melra_workflow_advance, though no sibling is named explicitly and 'bounded workflow' is never defined.

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 'without executing it' clause implies when the tool is appropriate (before execution) versus melra_execute, but no alternative is named and no prerequisites are stated — e.g. whether a plan must exist before melra_workflow_advance or melra_workflow_control. Usage is implied rather than 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 readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered without the description. The description only adds that the read is of the "current durable" projection, implying a persisted latest-state snapshot, which is modest extra context but no detail on latency, staleness, or what happens for unknown IDs.

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 short sentence with no filler and the core action front-loaded. It is efficient, though the brevity borders on under-specification rather than genuine conciseness.

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

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

There is no output schema, so the description carries the burden of explaining what the "workflow projection" contains, yet it never says what fields or states are returned. For a state-inspection tool with an undocumented required parameter, this is too thin.

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 single parameter workflowId has 0% schema description coverage; the schema only supplies a UUID format and regex. The description adds nothing about the parameter, so the agent gets no plain-language meaning, source, or expected value for workflowId beyond the raw pattern.

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?

"Read the current durable workflow projection" names a verb (read) and a resource (workflow), but the term "projection" is unexplained jargon and does not distinguish this tool from siblings like melra_task_status or melra_workflow_control. An agent cannot tell from the description alone what state this returns versus those neighbors.

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 among the ten siblings (e.g., melra_task_status for task-level state, melra_workflow_control or melra_workflow_cancel for actions). The agent must infer usage purely from the name.

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