EchoPath MCP Server

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

With no annotations, the description carries the full behavioral burden. It does disclose the two things destroyed (in-memory sessions and local history artifacts), but never states that the operation is destructive/irreversible, whether it is global or scoped, or that the confirm flag gates execution.

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 or repetition. It is efficiently sized, though the brevity comes at the cost of the missing behavioral detail noted elsewhere rather than from deliberate pruning of low-value content.

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?

An output schema exists, so return values need not be explained, but a destructive zero-annotation tool should clarify scope, irreversibility, and the role of confirm. None of that is present, leaving the agent under-informed before an irreversible action.

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 single parameter 'confirm' (boolean, default false) is never mentioned in the description. For a destructive tool, the meaning and gating behavior of confirm is exactly the kind of detail the description should supply, and it is absent.

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 pairs a clear verb ('Clear') with specific resources ('in-memory sessions and local EchoPath history artifacts'), and the EchoPath scoping separates it from generic session tools. It does not explicitly name a sibling to contrast against (e.g., echopath_list_sessions), but the destructive clearing action is unmistakable.

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 versus the many session/history siblings (list_sessions, get_session, create_session), nor any preconditions or warnings. The agent must infer that this is a cleanup/reset operation from the verb 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?

No annotations are provided, so the description carries the full behavioral burden. 'Deprecate' implies a potentially destructive or irreversible change to a stored memory, but the description never states whether this is reversible, what happens to the underlying run data on consolidation, or what permissions are 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?

A single tight sentence with no filler, and the core operation is front-loaded. It is efficient, though the brevity shades into under-specification rather than pure 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?

An output schema exists so return values need no explanation, but for a four-parameter dual-mode mutation tool with zero annotation and zero schema description coverage, the description omits mode selection, parameter roles, and mutation effects — the essentials an agent needs to call it correctly.

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

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

All four parameters have 0% schema description coverage, and the description only obliquely hints at them ('recorded GUI run' for run_id, 'memory' for deprecate_path_id). Critically, it never explains that the supplied parameter selects the mode, nor what 'reason' or 'task_intent' are 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 names two specific operations — consolidating a recorded GUI run into memory and deprecating a memory — with clear verbs and resources that distinguish it from siblings like echopath_list_memories and echopath_list_runs. However, compressing both modes into one sentence leaves ambiguity about which one is primary and how they relate.

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 consolidation versus deprecation, nor any prerequisites, timing, or alternatives relative to the many sibling tools. The agent must infer the selection condition from the parameter names 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?

With no annotations, the description carries the full burden, and it does disclose one genuinely useful behavioral trait: this is an asynchronous 'request' and the caller must wait for the paused state before interacting with the desktop. However, it says nothing about permissions, what 'stop' destroys, whether actions are reversible or idempotent, or what happens if the run is already in the requested state.

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, front-loaded sentences with no filler, and the primary capability leads. The second sentence is slightly telegraphic ('Wait for paused') and reads as a fragment, which costs a point on structure.

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?

An output schema exists, so return values need not be explained, and the action vocabulary plus the wait-for-paused sequencing are covered. Still missing for a two-parameter control tool with zero annotations: the meaning of run_id, the effect of stop, and any error or state-precondition behavior.

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

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

Schema coverage is 0% and the action parameter is a bare string with no enum, so the only place the legal values (pause/resume/stop) appear is this description – that is real added value. It does not compensate for the rest of the gap: run_id is entirely undocumented, and there is no statement of what happens for an invalid action or unknown 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 ('Request') and enumerates the three operations it can perform (pause, resume, stop). The target resource is only implied by the name ('run') and never stated in prose, and the description does not differentiate this tool from look-alike siblings such as echopath_resume, echopath_resume_task, or echopath_start_task.

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

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

There is no explicit when-to-use guidance and no mention of alternatives, even though the sibling list contains at least two other resume-flavored tools that an agent could easily confuse with action='resume'. The 'before taking over the desktop' clause hints at a scenario but never states the condition for choosing this tool over its 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?

No annotations are provided, so the description carries the full burden. It discloses only the returned session_id; it says nothing about permissions, whether an existing session is reused, or any side effects of creating a session, which is thin for a mutation 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?

A single front-loaded sentence with zero filler; the action and its result are 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?

The output schema covers the return value and the tool has just one optional parameter, so little is required. However, with no annotations and no usage context relative to the other session tools, the definition is only minimally complete for an agent deciding how to use it.

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 never mentions the one parameter, 'title' (optional, default 'New chat'). The schema supplies the type and default, but the description adds no meaning about what the title is used for or what happens if omitted.

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 (Create) and resource (EchoPath chat session), plus the return value. It does not differentiate itself from the sibling session tools (echopath_get_session, echopath_list_sessions), so it lands just below the top tier.

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 create a new session versus reusing an existing one, and no mention of the alternatives in the sibling list. The agent gets a purpose but no selection criteria.

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?

No annotations are supplied, so the description carries the behavioral burden. It does disclose the salient return content (replay phrase, parameters, steps), from which a read-only nature can be inferred, but it says nothing about permissions, whether the identifier must be resolvable, or error behavior.

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 with the purpose front-loaded and no filler. The trailing start_task instruction is slightly tangential to describing this tool, but it is brief and actionable rather than 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?

An output schema exists, so the description need not detail return values, and it helpfully routes to the follow-up call. However, with two required parameters at 0% coverage and no annotations, the definition leaves the agent guessing about the identifiers it must supply.

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 both 'store' and 'procedure_id' are undocumented in the schema and the description does not compensate. The only mention of 'parameters' refers to the fetched procedure's own parameters, not the two required inputs, leaving their format and origin unspecified.

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 ('Return') and resource ('one stored procedure') and enumerates exactly what comes back: replay phrase, parameters, every step. The scope word 'one' implicitly separates it from the sibling echopath_list_procedures, so an agent can pick it without opening the 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?

The second sentence gives workflow context ('Start it with echopath_start_task using the replay phrase as the task'), which implies why one would fetch a procedure, but it never states when to choose this tool over echopath_list_procedures or what prerequisites exist. Usage is inferred rather than declared.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read operation and names the returned content ('messages and debug state'), but says nothing about permissions, behavior when the session_id is unknown, or whether any state changes occur.

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 or repetition. It is efficient, though arguably too terse given the gaps it leaves elsewhere.

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?

An output schema exists, so return values need not be explained. But for a tool with zero annotation coverage and an undocumented required parameter, the description is only minimally sufficient to invoke the tool correctly.

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

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

Schema description coverage is 0% and the single required parameter 'session_id' is never mentioned in the description, so there is no hint about its format or where it comes from. The description does nothing to compensate for the undocumented 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?

States a specific verb ('Return') and resource ('EchoPath session') and adds scope detail ('with messages and debug state'), which is more than a bare tautology. However, it does not distinguish itself from siblings like echopath_list_sessions or echopath_get_task, so an agent must infer the boundary from the name 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as echopath_list_sessions for enumeration. The description never says when fetching a single session is appropriate versus other retrieval tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a non-mutating snapshot read, but says nothing about whether debug mode must be enabled, whether the session must be active, what happens for an unknown session_id, or what 'status' actually encompasses. For a tool with zero annotation coverage this is thin.

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; the verb and resource lead and nothing is repeated from the title or schema.

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?

An output schema exists, so return-value explanation is not required. But with no annotations and an entirely undocumented parameter, the description leaves real gaps for what should be a trivial call: what 'debug status' contains and what makes a session_id valid.

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 one parameter (session_id) at 0% schema description coverage, and the description does not compensate at all — it never mentions the parameter, its format, or where a valid session_id comes from (e.g. echopath_list_sessions). The schema alone leaves the agent guessing.

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 ('Return') and a specific resource ('current debug status') scoped to an 'EchoPath session', which separates it from get_session/get_task/get_procedure. It does not, however, explicitly name or contrast with any sibling, so an agent must infer the boundary between 'status' and the other session/task getters.

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, and no mention of alternatives among the 16 siblings (e.g. echopath_get_session, echopath_smoke_check). The agent gets a definition but no routing signal.

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?

No annotations are provided, so the description carries the full burden. It does signal a read-style operation and discloses the returned fields, which is useful, but it says nothing about permissions, whether a task must be started/resumed first, error behavior for unknown run_id, or freshness of the status snapshot.

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 returned fields are listed compactly. It is efficient, though the terseness leaves no room for the usage and identifier context the tool needs.

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?

An output schema exists, so the description need not restate return values, and for a one-parameter read tool it is close to sufficient. The remaining gap is the undefined run_id semantics and lack of any routing guidance against the many sibling read 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?

Schema description coverage is 0% and the single parameter run_id is undocumented in both schema and description. The description's use of 'task' versus the parameter name 'run_id' leaves the identifier relationship ambiguous, so the description 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 ('Return a single tracked task') and enumerates the payload (status, activity, final result), so the agent knows exactly what it retrieves. It does not distinguish itself from the neighboring read tools such as echopath_get_status or echopath_get_session, so sibling differentiation is absent.

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 call this versus echopath_get_status, echopath_list_runs, or echopath_get_session, all of which are plausible alternatives for retrieving task state. No prerequisites, polling advice, or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses nothing about pagination behavior, default result size, whether hidden/candidate memories are omitted, or permissions. An output schema exists so return shape needn't be described, but the operational behavior of the listing is entirely undisclosed.

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 or repetition. It is efficiently stated, though its brevity is partly the cause of the specification gaps noted elsewhere rather than a deliberate compression of rich content.

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

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

For a tool with two undocumented parameters, no annotations, and an ambiguous 'both memory stores' claim, one sentence is not enough. An agent knows it lists memories but not how results are bounded, what candidates are, or how this differs from the other list 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?

Schema description coverage is 0% — 'limit' and 'include_candidates' have no titles beyond their names and no descriptions. The description mentions neither; 'both memory stores' vaguely gestures at the candidate/store concept but does not explain what include_candidates changes or what limit bounds.

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+resource ('List learned memories') and adds a scope note ('from both memory stores'). It is understandable on its own, but it never clarifies what a 'learned memory' is versus the sibling resources (procedures, runs, sessions), nor what the two stores are.

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 call this versus echopath_list_procedures, echopath_list_runs, or the get_* siblings, and no stated prerequisites. The only hint is the implied 'browse everything' framing of 'both memory stores'.

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?

With no annotations, the description carries the disclosure burden and does add real behavioral context: procedures are learned paths/replay-library records, and a matching active procedure causes replay rather than fresh planning. It implies a read-only listing but does not state filtering semantics (active vs inactive, limits, ordering) or expected empty results, which is the remaining 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 what is listed and what it returns, then the when-to-use rule, then the handoff tool. No filler sentences and nothing buried.

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?

An output schema exists, so return values need not be spelled out, yet the description still names the key fields. For a no-parameter listing tool its guidance on when to call it and which sibling to call next is sufficient 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?

There are zero parameters, so per the rubric this is a baseline 4. The description's mention of id/store/title/step count is about output, already covered by the output 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 (list) and resource (stored procedures), and clarifies what counts as a procedure: learned paths and replay-library records. It also names the returned fields and points to the distinguishing sibling echopath_get_procedure, so an agent can separate it from the list_runs/list_sessions siblings without opening a 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 timing guidance ('Check this before starting a desktop task') and the consequence of doing so (a matching active procedure replays instead of planning from scratch). It also names the follow-up tool, echopath_get_procedure, and what it retrieves (the replay phrase), which is exactly the routing an agent needs.

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?

No annotations are provided, so the description carries the full burden. It discloses the categories of runs returned (ongoing, paused, recent) and the worker sources, but omits access requirements, pagination, and whether it is read-only. With an output schema present, return formatting is partly covered.

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 wasted words. It conveys scope and source 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 zero-parameter list tool with an output schema, the description provides enough to understand what is listed. However, it lacks usage guidance and annotation coverage means safety/behavioral context is 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?

There are zero parameters, so the schema coverage baseline of 4 applies. The description adds no parameter details because there are none.

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 ('runs'), with scope (ongoing, paused, recent) and source workers (CLI, MCP, dashboard). It distinguishes itself from control_run and get_status by being the listing tool, though it does not name alternatives 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?

No explicit when-to-use guidance, prerequisites, or alternatives are given. An agent must infer that this is for viewing runs rather than controlling them or checking status.

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?

No annotations are provided, so the description carries the full burden, but it does disclose a meaningful trait: sessions are in-memory and scoped to this server process, implying ephemerality and no cross-process visibility. It says nothing about ordering, pagination, or emptiness behavior, which matters for a list 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?

A single short sentence with the scope constraint front-loaded and zero filler. Every word earns its place.

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

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

An output schema exists, so return values need not be described, and with zero parameters the surface is small. The one remaining gap is that the description does not distinguish in-memory sessions from persisted ones or point to the session-creation sibling, but it is otherwise complete for this call shape.

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 there is nothing for the description to disambiguate; baseline for a parameterless tool is 4. No wasted text attempting to explain absent inputs.

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 (EchoPath sessions) with a scoping qualifier (in-memory, this MCP server process). It is distinguishable from get_session and list_runs by the plural list framing, 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?

There is no statement of when to use this versus echopath_get_session, echopath_list_runs, or echopath_list_procedures. The only usage signal is the implicit 'browse sessions' reading of a list verb, and no exclusions or prerequisites are given.

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

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

With no annotations, the description carries the full burden and does add real behavioral facts: continuation tokens are single-use and expire on server restart, return state is verified, and cancel abandons a pending segment. It omits what happens on an expired/reused token, failure semantics, and any auth or permission 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?

Three short sentences, front-loaded with the action, then the cancel rule, then the token caveat. No filler; only the opening sentence's vagueness slightly weakens it.

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 4-parameter tool with no annotations and 0% schema description coverage, the description leaves session_id and the outputs structure undocumented and gives no sibling differentiation against echopath_resume_task. The output schema covers return values, but the calling contract remains 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?

Schema description coverage is 0% for 4 parameters, so the description must compensate. It explains cancel ('abandon a pending segment') and continuation_token (single use, expires on restart), but says nothing about session_id and only loosely gestures at outputs ('supply declared outputs') without format details.

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 verb 'Resume' is clear but the object is vague — 'after native computer use' does not name a resource an agent can reason about, and it does not distinguish this from the sibling echopath_resume_task. The added clause about supplying declared outputs hints at the mechanism but not the 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?

The only conditional guidance is 'Use cancel=true to abandon a pending segment', which is parameter-level, not tool-selection guidance. There is no statement of when to call echopath_resume versus echopath_resume_task or the other run/task tools, and no 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?

With no annotations, the description carries the full burden. It does disclose genuinely useful behavior beyond the schema: the worker verifies the live return state before continuing, and the caller should poll echopath_get_task, implying an asynchronous, eventually-consistent flow. It stops short of stating what happens if the task is not in awaiting_native, required permissions, or whether cancel is destructive/reversible, leaving notable gaps for a state-mutating 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?

Two short sentences, front-loaded with the action and its precondition, then the follow-up polling note. Every clause carries information and there is no filler, though the phrasing is slightly compressed and would read more cleanly as a single tightened sentence.

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?

An output schema exists, so return values need not be explained, and the description covers the trigger state, the two actions, and the required polling follow-up. What is missing is the failure/edge behavior (task not awaiting_native, invalid run_id) and differentiation from the similarly named sibling, which keeps it from being fully complete for a state-mutating tool with no annotations.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: 'supply its declared outputs' explains the outputs parameter and 'cancel' explains the cancel flag. The required run_id parameter and the shape/typing of outputs remain undocumented in both the description and the schema, so the compensation is incomplete.

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 concrete operation (answering a tracked task by supplying its declared outputs or cancelling) and a precise precondition state ('awaiting_native'), so an agent can tell this is a resume/fulfill step rather than a start or run step. It is slightly loose on the verb ('Answer a tracked task') and never contrasts itself with the closely named sibling echopath_resume or echopath_run_task, so it stops short of a 5.

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 triggering condition: use this for a tracked task that is 'awaiting_native'. It also frames the two available actions (supply outputs or cancel). However it offers no explicit when-not guidance and does not disambiguate from echopath_resume, echopath_run_task, or echopath_start_task, which is a real selection risk given the near-identical sibling 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?

With no annotations, the description carries the full burden and does disclose non-obvious behavior beyond the schema: default-disabled desktop control, the native-handoff precondition, and a named mid-execution state (awaiting_native) with a resume protocol. It omits error/consent/statefulness details, but the handoff lifecycle is meaningful disclosure.

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, front-loaded with the core action and default, followed by the conditional and the continuation step. Minimal waste, though the resume instruction overlaps with the echopath_resume tool's own domain.

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?

An output schema exists so return values need not be described, and the description covers the key default and continuation workflow. What is missing is the role of session_id and how this tool relates to the closely named task/session siblings.

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

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

Schema description coverage is 0%, so the description must compensate, and it explains only the two booleans (allow_native_handoff, allow_desktop_control defaults). It says nothing about 'message' or 'session_id', leaving two of four parameters undocumented anywhere.

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 ('Send one task to EchoPath') and adds the key qualifier that desktop control is off by default. However, it does not distinguish this from sibling tools like echopath_start_task, echopath_resume_task, or echopath_resume, leaving an agent unsure why it would pick this entry point over those.

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 concrete conditional guidance: enable allow_native_handoff only when native computer tools control the same desktop, and on an awaiting_native state complete the subgoal then call echopath_resume with the token. It omits when to use this versus the many sibling task/session tools, but the workflow conditions it does give are 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?

No annotations are provided, so the description carries the full burden. 'Safe' hints at non-destructiveness but does not state whether the check mutates anything, what services it probes, how long it takes, or what a failure looks like.

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 that is front-loaded and wastes no words. Brevity here is under-specification rather than tight editing, so it does not earn a top score.

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?

An output schema exists, so return values need not be described. But with no annotations, an undocumented parameter, and no usage context, the definition is too thin for an agent to invoke this confidently alongside sixteen siblings.

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 include_model_bridge has 0% schema description coverage and is never mentioned in the description, so its effect (whether model-bridge checks are added to the run) is undocumented anywhere. The description adds no meaning beyond the bare property name.

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 verb ('Run') and resource ('health checks') scoped to EchoPath, so the general purpose is inferable. However, 'safe' is undefined and nothing distinguishes it from the many sibling tools that also operate on EchoPath state (get_status, list_runs, etc.).

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 indication of when to run a smoke check, whether it should precede other operations, or how it relates to siblings like echopath_get_status. The agent is left to guess the trigger condition.

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?

With no annotations, the description carries the full burden and does deliver real behavioral context: the call returns immediately with a task ID (non-blocking), desktop control is a prerequisite that must be explicitly enabled, and a replay may halt at status 'awaiting_native' requiring an out-of-band subgoal completion. It omits what happens if desktop control is requested without being enabled and the meaning of the vm vs local target distinction.

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?

Front-loaded with the core action and return behavior, then two short routing sentences, then the handoff edge case. No filler, though the handoff paragraph is slightly dense and could be split for readability.

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

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

An output schema exists, so return values need not be explained, and the description covers the async nature, the control prerequisite, and the handoff exception. Remaining gaps are the task string format and vm_endpoint semantics, plus no guidance on how this relates to echopath_run_task.

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 5 parameters, so the description must compensate. It explains the intent of 'target' (local or VM), 'allow_native_handoff' (permits the awaiting_native stop), and implies 'allow_desktop_control' via the desktop-control prerequisite, but 'task' and 'vm_endpoint' are left entirely undefined 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?

States a specific verb and resource ('Start a tracked local or VM task') and captures the defining trait of the tool: it returns immediately with a task ID, i.e. it is asynchronous. It does not explicitly contrast with the sibling echopath_run_task, which is presumably the synchronous alternative, so sibling differentiation is only partial.

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?

Explicitly routes the agent for the follow-up phase ('Use echopath_list_runs or echopath_control_run to follow and control it') and describes the handoff path back to echopath_resume_task. It does not say when to prefer this over echopath_run_task or echopath_resume_task directly, but the named alternatives cover the main usage context.

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