wtf

• command

  433343B3.4

  The description is clear and concise, effectively conveying the tool's purpose and basic usage. It aligns with annotations and provides useful examples, but could improve by explicitly stating when to use it versus alternatives and detailing potential side effects beyond row changes.

  4

  Purpose Clarity · 25%The description clearly states the tool runs ':' commands on the workspace and lists examples (decode, protocol, rows, cursors). It distinguishes from siblings by focusing on command execution, though it doesn't explicitly contrast with other tools.

  3

  Usage Guidelines · 20%It implies usage by showing command examples and mentions 'help commands' for more, but does not explicitly state when to use this tool versus alternatives like 'help' or 'info'. The context is clear enough for an agent to infer, but lacks explicit exclusions.

  3

  Behavioral Transparency · 20%Annotations already declare destructiveHint=true, so the description's mention of 'added or removed' rows aligns with that. It adds context about undo capability and response format, which is useful, but doesn't detail what destructive actions might occur or require confirmation.

  3

  Parameter Semantics · 15%Schema coverage is 100% and the parameter description is detailed with examples. The tool description adds minimal extra meaning beyond the schema, so baseline 3 is appropriate.

  4

  Conciseness & Structure · 10%The description is concise, two sentences, and front-loads the purpose. It includes examples and a pointer to help, with no wasted words.

  3

  Contextual Completeness · 10%Given the tool's complexity (running arbitrary commands) and lack of output schema, the description provides enough to understand basic behavior but could be more complete about error handling, side effects, or command syntax details. It's adequate but not exhaustive.

  params

  1 (1 required, 100% described)

  annotations

  readOnly=false destructive=true idempotent=false openWorld=false

  output schema

  no

  cost

  1

  bytes

  617

  hash

  5c79db16fe981ec6

• find

  444344A3.9

  The description is well-crafted, clearly explaining the tool's purpose and key usage nuances, with no contradictions to annotations. It leverages the schema's parameter documentation effectively, though it could benefit from a bit more structure and explicit mention of return format. Overall, it is a solid, above-average description.

  4

  Purpose Clarity · 25%The description clearly states the tool finds times when a search expression holds, and mentions related options like `show` and `count_only`. It distinguishes itself from siblings by focusing on search expressions and time-based matching, though it does not explicitly name alternative tools for similar tasks.

  4

  Usage Guidelines · 20%The description provides clear context on when to use the tool (searching for times when an expression holds) and explains the difference between using `@<clock>` and not, which guides usage. It does not explicitly state when not to use it or mention alternatives, but the context is sufficient for most cases.

  4

  Behavioral Transparency · 20%Annotations declare readOnlyHint=true, and the description aligns with that by describing a search operation without side effects. The description adds useful behavioral details such as the reporting time (cycle start vs. edge) and the effect of `backward`, which go beyond the annotations. No contradiction found.

  3

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all parameters. The description adds some context for `expr` (e.g., examples and the `@<clock>` syntax) and clarifies the meaning of `show` and `count_only`, but it does not add significant meaning beyond the schema for most parameters. Baseline 3 is appropriate.

  4

  Conciseness & Structure · 10%The description is concise and front-loaded with the core purpose, but it packs a lot of technical detail into a few sentences, which may be dense for some users. It is not overly verbose, but the structure could be improved with clearer separation of concepts.

  4

  Contextual Completeness · 10%Given the tool's complexity (8 parameters, no output schema), the description covers the main behavioral aspects and parameter semantics well. It explains the search expression syntax, the effect of `@<clock>`, and the `show`/`count_only` options. However, it does not describe the return format or how results are presented, which could be a gap for a tool with no output schema.

  params

  8 (1 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  1

  bytes

  1682

  hash

  cfa689461a481027

• help

  543354A4.0

  The description is clear and concise, effectively communicating the tool's purpose and usage context. It distinguishes itself from siblings by listing topics and providing a specific trigger for use. The parameter semantics are well-covered by the schema, and the description adds just enough behavioral context to be helpful without being verbose.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: it is a reference for one concept, covering its form, recipes, and details. It lists the topics it covers and explicitly mentions that without a topic it lists them, which distinguishes it from sibling tools like 'find' or 'info'.

  4

  Usage Guidelines · 20%The description provides clear guidance on when to use the tool: 'Call it when an argument's doc or an error isn't enough.' This gives a specific context for use, though it does not explicitly mention alternatives or when not to use it, which would make it a 5.

  3

  Behavioral Transparency · 20%The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds that it lists topics when no topic is given, which is a behavioral detail not in the annotations. However, it does not describe the output format or any other behavioral traits, so it adds only moderate value beyond the annotations.

  3

  Parameter Semantics · 15%The schema description coverage is 100%, and the parameter 'topic' is described as 'A topic; none lists them.' The description adds a bit more context by listing example topics, but the schema already covers the parameter's meaning. Thus, the description adds minimal value beyond the schema, warranting a baseline 3.

  5

  Conciseness & Structure · 10%The description is concise, with two sentences that are front-loaded with the core purpose and then provide usage guidance. Every sentence adds value, and there is no redundancy or fluff.

  4

  Contextual Completeness · 10%Given the tool's simplicity (one optional parameter, no output schema, and clear annotations), the description is complete enough. It covers the purpose, topics, and usage context. It could mention the output format, but that is not necessary given the tool's nature and the lack of an output schema.

  params

  1 (0 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  541

  hash

  063a1cb618097f00

• info

  433454A3.7

  The description is clear and concise, effectively communicating the tool's purpose of providing an overview of the open waveform. It leverages the read-only annotation well and adds value by specifying the exact information returned. Minor gaps exist in usage guidance (no explicit alternatives) but are acceptable for a simple info tool.

  4

  Purpose Clarity · 25%The description clearly states that the tool provides information about the open waveform, including file, time range, signals, and protocol decode interfaces. It is specific about the resource (open waveform) and the type of information returned, but it does not explicitly distinguish it from sibling tools like 'signals' or 'protocols', though the scope is broader.

  3

  Usage Guidelines · 20%The description implies that this tool is used to get an overview of the current waveform and its decoding, but it does not explicitly state when to use it versus alternatives like 'signals' or 'protocols'. There is no mention of when not to use it or any prerequisites, but the context is clear enough for a simple info tool.

  3

  Behavioral Transparency · 20%The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it returns the file, time range, signals, and decode interfaces, which is useful context. However, it does not disclose any potential side effects (though none are expected) or details about the output format, but given the read-only annotation, this is adequate.

  4

  Parameter Semantics · 15%The tool has zero parameters, and the schema description coverage is 100% (vacuously). The description explains what the tool returns, which is the main semantic content. Since there are no parameters to document, the description adds value by clarifying the output scope, so a baseline of 4 is appropriate.

  5

  Conciseness & Structure · 10%The description is a single, concise sentence that packs all necessary information: what the tool reports (file, time range, signals, decode interfaces) and the context (open waveform). There is no wasted wording, and it is front-loaded with the key noun 'waveform'.

  4

  Contextual Completeness · 10%Given the tool's simplicity (no parameters, no output schema, read-only annotation), the description is complete enough. It covers the main aspects of the tool's output. It could mention that it is a summary or overview, but the description already implies that by listing the elements. The lack of an output schema is not a gap because the description enumerates the returned items.

  params

  0 (0 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  293

  hash

  8e28f4512cace080

• open

  544354A4.2

  The description is clear and concise, effectively communicating the tool's purpose and key behavioral traits. It provides sufficient guidance for an agent to use it correctly, with minor room for improvement in explicit usage guidelines.

  5

  Purpose Clarity · 25%The description clearly states the tool opens a waveform file (VCD, FST, or GHW) in a new workspace, which is a specific verb and resource. It also distinguishes itself from siblings by mentioning the 'new workspace' behavior and the response format.

  4

  Usage Guidelines · 20%The description implies when to use this tool (to open a waveform file) and mentions the response ('info'), but does not explicitly state when not to use it or mention alternatives. However, the context is clear enough for an agent to decide.

  4

  Behavioral Transparency · 20%Annotations are all false, so the description carries the burden. It discloses that the tool opens a new workspace and that the current one changes from then on, which is a key behavioral trait. It also mentions the response format, adding value beyond the schema.

  3

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents the 'trace' parameter. The description adds the requirement that the path should be absolute, which is a small addition, but the baseline is 3 due to high coverage.

  5

  Conciseness & Structure · 10%The description is two sentences, front-loaded with the main action, and every word adds value. It is concise and well-structured.

  4

  Contextual Completeness · 10%Given the tool's simplicity (one parameter, no output schema), the description is complete enough. It covers the action, the file types, the workspace behavior, and the response. No major gaps.

  params

  1 (1 required, 100% described)

  annotations

  readOnly=false destructive=false idempotent=false openWorld=false

  output schema

  no

  cost

  1

  bytes

  532

  hash

  e898a48fafe7ba38

• present

  444444A4.0

  The description is clear and informative, providing specific behavioral details that go beyond the annotations. It effectively explains the tool's purpose and the two scenarios, making it easy for an agent to decide when to use it. The only minor gap is the lack of explicit guidance on when not to use it, but overall it is a well-crafted description.

  4

  Purpose Clarity · 25%The description clearly states the tool's purpose: to show the workspace to the user as evidence, with two specific behaviors depending on whether wtf windows are open. It distinguishes itself from siblings like 'view' and 'workspace' by focusing on the presentation of the workspace as evidence, though it could be more explicit about the distinction.

  4

  Usage Guidelines · 20%The description provides clear context on when to use the tool: when you need to present the workspace as evidence to the user. It also explains the two scenarios (with open windows vs. none open) and the resulting behavior. However, it does not explicitly state when not to use it or mention alternatives, but the context is sufficient for most cases.

  4

  Behavioral Transparency · 20%The description discloses key behavioral traits: it replaces the view of every wtf window on the trace, and when none are open, it writes a specific file. This goes beyond the annotations, which only indicate idempotentHint=true and destructiveHint=false. The description adds important context about the side effect of writing a file, which is not captured by the annotations.

  4

  Parameter Semantics · 15%The tool has zero parameters, and the schema coverage is 100% (vacuously). The description does not need to explain parameters, but it does explain the tool's behavior in detail, which is more valuable. Since there are no parameters, a baseline of 4 is appropriate, and the description adds context about the tool's effect.

  4

  Conciseness & Structure · 10%The description is a single sentence that is concise and front-loaded with the main purpose ('Show your workspace to the user as evidence'). It includes necessary details about the two scenarios without unnecessary fluff. It could be slightly more structured, but it is efficient and to the point.

  4

  Contextual Completeness · 10%Given the tool's simplicity (no parameters, no output schema), the description is complete enough. It explains the two possible outcomes and the side effect of writing a file. The annotations provide additional safety hints. The description covers the essential behavioral aspects, making it adequate for an agent to use the tool correctly.

  params

  0 (0 required, 100% described)

  annotations

  readOnly=false destructive=false idempotent=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  418

  hash

  964145c132ba68b0

• protocols

  433354A3.6

  The description is concise and clear, effectively communicating the tool's purpose and the role of its single parameter. It aligns with the read-only annotation and provides adequate guidance for a simple tool, though it could benefit from explicit differentiation from sibling tools like 'info' or 'help'.

  4

  Purpose Clarity · 25%The description states the tool lists or describes protocols, with optional name filtering. It is clear but does not explicitly distinguish from siblings like 'info' or 'help', though the focus on protocols is specific.

  3

  Usage Guidelines · 20%The description implies usage: call with no name to list all, with a name to get details. It does not explicitly state when to use this over 'info' or 'help', but the context is clear enough for a simple tool.

  3

  Behavioral Transparency · 20%Annotations already declare readOnlyHint=true, so the description need not repeat safety. It adds that the tool can decode protocols and that providing a name gives roles, params, streams, and fields, which is useful behavioral context beyond the schema.

  3

  Parameter Semantics · 15%Schema coverage is 100% and the parameter description is clear ('A protocol to describe; none lists them all'). The description adds minimal extra meaning, but the schema already covers it, so baseline 3 is appropriate.

  5

  Conciseness & Structure · 10%The description is a single, compact sentence that conveys the purpose and the effect of the optional parameter. No wasted words.

  4

  Contextual Completeness · 10%For a simple read-only tool with one optional parameter and no output schema, the description is sufficient. It explains what the tool does and how the parameter changes behavior, which is complete for the tool's complexity.

  params

  1 (0 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  441

  hash

  d5cd3eef5ac82e0c

• records

  433343B3.4

  The description is clear and concise, effectively communicating the tool's purpose and basic output structure. It leverages schema coverage well, but could improve by explicitly stating when to use this tool versus siblings and providing more behavioral details beyond the schema. Overall, it is a solid, functional description with minor gaps.

  4

  Purpose Clarity · 25%The description clearly states that the tool returns records of a decoded stream as a table with columns n, start, end, and fields. It distinguishes from siblings by focusing on record listing, though it doesn't explicitly name alternatives. The purpose is specific and actionable.

  3

  Usage Guidelines · 20%The description implies usage for querying decoded stream records, and mentions `where`, `group_by`, `count_only` as options, but does not explicitly state when to use this tool versus alternatives like `values` or `value_at`. It provides some context but lacks explicit exclusions or alternative guidance.

  3

  Behavioral Transparency · 20%Annotations declare readOnlyHint=true, so the description doesn't need to state safety. It adds context about the table structure and time edges, but does not disclose details like default count, time units, or filtering behavior beyond what schema already provides. It doesn't contradict annotations.

  3

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning, only mentioning `where`, `group_by`, `count_only` as features. It doesn't explain parameter syntax or relationships beyond schema, so baseline 3 is appropriate.

  4

  Conciseness & Structure · 10%The description is a single sentence, front-loaded with the core purpose, and includes references to help for details. It is concise and structured, though it packs many details into one sentence, which could be slightly overwhelming but remains efficient.

  3

  Contextual Completeness · 10%Given the tool's complexity (9 parameters, no output schema), the description provides a good overview but relies heavily on `help records` for full details. It covers the main output structure and key options, but lacks explicit examples or edge cases. It is adequate but not exhaustive.

  params

  9 (1 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  1

  bytes

  1682

  hash

  1d752481a595d5b5

• reload

  323443B3.1

  The description is clear about the action but lacks differentiation from the sibling 'open' tool and provides minimal usage guidance. It is concise and adequate for a zero-parameter tool, but could benefit from clarifying when to use it versus alternatives.

  3

  Purpose Clarity · 25%The description states the tool reopens a trace file after the simulation was run again, which is a specific action on a resource. However, it does not distinguish itself from the sibling tool 'open', which likely also opens files, so the purpose is clear but not differentiated.

  2

  Usage Guidelines · 20%The description implies usage after re-running a simulation, but provides no explicit guidance on when to use this tool versus 'open' or other alternatives. There is no mention of prerequisites or context, leaving the agent to infer when this is appropriate.

  3

  Behavioral Transparency · 20%Annotations already declare idempotentHint=true and destructiveHint=false, so the description does not need to repeat those. It adds the context that the tool reopens a trace file after a simulation rerun, which is useful. However, it does not disclose any side effects or state changes beyond what annotations imply, but since annotations cover the safety profile, a 3 is appropriate.

  4

  Parameter Semantics · 15%The tool has zero parameters, and the schema coverage is 100% (empty schema). The description does not need to explain parameters, and the baseline for zero parameters is 4. The description adds no parameter info, but none is needed.

  4

  Conciseness & Structure · 10%The description is a single sentence, concise and front-loaded with the action. It is appropriately sized for a tool with no parameters, though it could be slightly more specific about the context of use.

  3

  Contextual Completeness · 10%Given the tool has no parameters, no output schema, and annotations cover safety, the description is mostly complete. However, it lacks detail on what 'reopen' entails (e.g., does it clear current state? does it require a file to be already open?) and does not differentiate from 'open', so there is room for improvement.

  params

  0 (0 required, 100% described)

  annotations

  readOnly=false destructive=false idempotent=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  278

  hash

  e51bc492cb3c34c0

• render

  433344A3.5

  The description is clear about the tool's purpose and defaults, with a concrete reference to wtf's screen, and it is concise. It lacks explicit guidance on alternatives and does not add much beyond the schema for parameters, but it is sufficient for a simple rendering tool with good annotations.

  4

  Purpose Clarity · 25%The description clearly states the tool draws signals as text over a time range, and mentions the 'wtf's screen' behavior, which gives a concrete image. It distinguishes from siblings like 'view' or 'values' by specifying the text output and time range, though it doesn't explicitly name an alternative.

  3

  Usage Guidelines · 20%The description implies usage for rendering signal values as text, but does not explicitly state when to use this versus other tools like 'view' or 'value_at'. It mentions the default behavior without signals (workspace) but lacks explicit exclusions or alternative recommendations.

  3

  Behavioral Transparency · 20%Annotations already indicate idempotentHint=true and destructiveHint=false, so the description doesn't need to repeat those. It adds that without signals it shows the workspace, and the text output format, but does not disclose details about output size limits or side effects beyond what annotations provide. No contradiction.

  3

  Parameter Semantics · 15%Schema coverage is 100%, so the schema already describes each parameter. The description only mentions that signals are drawn top to bottom and defaults, which aligns with schema. It does not add extra meaning beyond schema, so baseline 3 is appropriate.

  4

  Conciseness & Structure · 10%The description is very concise, one sentence with a semicolon break. It is front-loaded with the main action and provides a key detail (screens like wtf's). No wasted words.

  4

  Contextual Completeness · 10%Given the tool has 5 parameters but all optional, no output schema, and basic annotations (idempotent, non-destructive), the description could be more detailed about output formatting or usage context, but it does capture the essential purpose and default behavior. For a rendering tool, it covers the main use case adequately.

  params

  5 (0 required, 100% described)

  annotations

  readOnly=false destructive=false idempotent=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  972

  hash

  eb954eab12133e36

• sessions

  443454A3.9

  The description is clear and concise, effectively communicating the tool's purpose and output. It provides good usage context by referencing sibling commands, and the read-only annotation aligns with the description. Minor gaps include lack of explicit exclusions and detailed output format, but overall it is a well-crafted description for a simple listing tool.

  4

  Purpose Clarity · 25%The description clearly states that the tool lists open sessions, including user's wtf windows and agents' workspaces, with ids and traces, and marks the user's own. It distinguishes itself from siblings like 'open' and 'use' by mentioning those commands, but it doesn't explicitly contrast with all siblings.

  4

  Usage Guidelines · 20%The description provides clear context for when to use this tool: to view open sessions. It also mentions that 'use' switches between sessions and 'open' starts one, which helps the agent understand the relationship with sibling tools, though it doesn't explicitly state when not to use this tool.

  3

  Behavioral Transparency · 20%Annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. It adds context about what the tool returns (ids and traces) and that the user's sessions are marked, which is useful. However, it doesn't disclose any potential side effects or limitations beyond the read-only nature, which is acceptable given the annotations.

  4

  Parameter Semantics · 15%The tool has zero parameters, and the schema coverage is 100% (vacuously). The description adds meaning by explaining what the tool returns (sessions with ids and traces) and the marking of user's sessions, which is beyond the empty schema. This is a baseline 4 for zero-parameter tools.

  5

  Conciseness & Structure · 10%The description is a single, concise sentence that packs in the purpose, the content of the output, and a hint about related commands. Every word earns its place, and it is front-loaded with the core purpose.

  4

  Contextual Completeness · 10%Given the tool has no parameters, no output schema, and simple read-only behavior, the description is sufficient. It explains what the tool returns and how it relates to 'use' and 'open'. It could mention the format of traces or ids, but that is not critical for a listing tool.

  params

  0 (0 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  324

  hash

  10336c49277e8621

• signals

  433353A3.5

  The description is clear and concise, effectively conveying the search-by-regex functionality. It aligns with the read-only annotation and provides good examples. It could improve by explicitly distinguishing it from sibling search-related tools and offering more detail on result structure, but it is well within the acceptable range.

  4

  Purpose Clarity · 25%The description states that the tool searches for signals, scopes, and instances by regex, distinguishing it from sibling tools like 'find' or 'value_at' by its scope of search (paths). It names the specific resources (waveform's design, scopes, signals) and the mechanism (regex in slashes). Not a perfect 5 because it doesn't explicitly distinguish from siblings like 'value_at' but it's clear enough.

  3

  Usage Guidelines · 20%The description implies when to use it: when you need to search paths by pattern, and 'none' lists all. It doesn't explicitly say when NOT to use it or provide alternatives. The regex examples give some context, but there's no explicit comparison to other commands like 'find' or 'values'.

  3

  Behavioral Transparency · 20%Annotations declare readOnlyHint=true, and the description describes a search operation, which is consistent (no contradiction). It adds that it searches 'anywhere in the path' and that results are 'folded to fit', which is useful context beyond annotations. Lacks details on what exactly is returned (signal names, paths, etc.) but sufficient.

  3

  Parameter Semantics · 15%The schema description coverage is 100% for the single 'pattern' parameter, and it includes regex examples and default behavior. The description adds some semantic value by explaining the regex-in-slashes syntax and 'none' behavior, but it largely echoes the schema. Baseline 3 is appropriate since schema already covers it well.

  5

  Conciseness & Structure · 10%The description is a single, well-structured sentence that packs in the purpose, the regex format with examples, and the special 'none' behavior. It is concise and front-loaded with the main verb 'Search'. No fluff.

  3

  Contextual Completeness · 10%The tool has a simple interface (1 optional param) and no output schema, so the description doesn't need to explain return values in detail. It covers the core functionality and provides usage examples. However, it could mention case-insensitivity (though the schema does) and the fact that it searches scopes, instances, and signals might be enough. It's adequate, but could be slightly richer (e.g., mention that 'none' lists all and results are folded).

  params

  1 (0 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  623

  hash

  9c8727d50e42ed1a

• use

  434354A3.8

  The description is clear and concise, effectively explaining the tool's purpose and behavior. It provides good context for usage, though it could be more explicit about when to use it versus alternatives. The description aligns with annotations and schema, making it a solid, well-rounded tool definition.

  4

  Purpose Clarity · 25%The description clearly states the tool's purpose: to switch the current workspace to another one from the server's list, and that it does not close anything. It distinguishes from siblings like 'open' and 'sessions' by specifying it changes the current workspace for other tools, but could be more explicit about the difference from 'open'.

  3

  Usage Guidelines · 20%The description implies when to use it (when you need to change the current workspace) but does not explicitly state when not to use it or mention alternatives. It references 'sessions' for valid ids, which is helpful, but lacks explicit guidance on when to prefer this over 'open' or other tools.

  4

  Behavioral Transparency · 20%The description adds useful behavioral context beyond annotations: it states that nothing is closed and that the tool responds with 'info'. Annotations already indicate idempotentHint=true and destructiveHint=false, and the description reinforces this by clarifying no closure occurs, which is valuable for a state-changing tool.

  3

  Parameter Semantics · 15%The schema already provides 100% coverage for the single parameter 'session', describing it as the id of a workspace from 'sessions'. The description repeats this reference but adds no new semantic detail beyond what the schema provides, so a baseline score of 3 is appropriate.

  5

  Conciseness & Structure · 10%The description is concise and front-loaded, with a single sentence that clearly states the action, the source of valid ids, the effect on other tools, and the response. No unnecessary words or repetition.

  4

  Contextual Completeness · 10%Given the tool's simplicity (one parameter, no output schema, clear annotations), the description is sufficiently complete. It covers the key aspects: what it does, how to get valid ids, and the response. It could mention error cases or side effects, but for a simple switch operation, this is adequate.

  params

  1 (1 required, 100% described)

  annotations

  readOnly=false destructive=false idempotent=true openWorld=false

  output schema

  no

  cost

  1

  bytes

  555

  hash

  6a33605e00e38582

• user_view

  433343B3.4

  The description is clear and concise, effectively communicating the tool's purpose and the effect of the 'adopt' parameter. It provides adequate behavioral context given the annotations, though it could be more explicit about usage guidelines and alternatives. Overall, it is a well-formed description for a simple tool.

  4

  Purpose Clarity · 25%The description clearly states the tool shows what the user is looking at in their 'wtf window' on a trace, which is a specific resource and context. It distinguishes from siblings like 'view' and 'workspace' by focusing on the user's current view, though it could be more explicit about the distinction.

  3

  Usage Guidelines · 20%The description implies usage: to start from what the user sees, and mentions 'adopt' as an option to copy into the workspace. However, it does not explicitly state when to use this tool versus alternatives like 'view' or 'workspace', nor does it provide exclusions or alternative tool names.

  3

  Behavioral Transparency · 20%Annotations indicate destructiveHint=true and readOnlyHint=false, so the tool may have side effects. The description mentions that 'adopt' replaces the workspace's rows, cursors, and range, which adds behavioral context beyond annotations. However, it does not detail other potential side effects or permissions, but the annotations already cover the safety profile partially.

  3

  Parameter Semantics · 15%Schema description coverage is 100%, so the parameter 'adopt' is fully described in the schema. The description adds a bit of context by explaining what 'adopt' does (replaces workspace's rows, cursors, and range), but this is largely redundant with the schema's description. Baseline 3 is appropriate.

  4

  Conciseness & Structure · 10%The description is a single sentence that is concise and front-loaded with the main purpose. It includes a useful clarification about 'adopt' without unnecessary fluff. Slightly more structure could be added, but it is efficient.

  3

  Contextual Completeness · 10%The tool has one optional parameter, no output schema, and annotations that indicate potential destructiveness. The description explains the main purpose and the effect of 'adopt', which is sufficient for a simple tool. However, it could mention what the tool returns or how to interpret the user's view, but given the simplicity, it is adequate.

  params

  1 (0 required, 100% described)

  annotations

  readOnly=false destructive=true idempotent=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  585

  hash

  882987cf705ff68e

• value_at

  543354A4.0

  The description is clear and concise, effectively distinguishing this tool from its siblings. It leverages the schema and annotations well, providing just enough behavioral context without redundancy. A solid, well-rounded description.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: 'Values of signals at one time; a struct or array whole, then each signal in it.' It uses a specific verb ('values') and resource ('signals at one time'), and distinguishes from siblings by mentioning 'changes over a range' (values) and 'when something happens' (find).

  4

  Usage Guidelines · 20%The description provides clear context for when to use this tool: for a single time point, as opposed to 'values' for changes over a range and 'find' for event detection. It does not explicitly state when not to use it, but the alternatives are named, which is sufficient guidance.

  3

  Behavioral Transparency · 20%Annotations already declare readOnlyHint=true, so the description does not need to repeat that. The description adds the behavioral detail that it returns a struct or array whole, then each signal in it, which is useful. However, it does not disclose any potential side effects or limitations beyond that, but given the read-only annotation, a score of 3 is appropriate.

  3

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all parameters. The description does not add much beyond what the schema provides, but it does imply the 'time' parameter is a single time point. Since the schema covers everything, a baseline of 3 is appropriate.

  5

  Conciseness & Structure · 10%The description is two sentences, front-loaded with the core purpose, and every word earns its place. It efficiently contrasts with sibling tools without unnecessary detail.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (4 parameters, no output schema), the description is complete enough. It explains the return behavior (struct/array whole, then each signal) and provides usage context. The schema covers parameters, and annotations cover safety, so the description fills the remaining gaps adequately.

  params

  4 (2 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  2

  bytes

  851

  hash

  15e72dd91ff021c4

• values

  433354A3.6

  The description is clear and concise, effectively communicating the tool's purpose and output format. It leverages the full schema coverage and read-only annotation, though it could improve by explicitly contrasting with the sibling `value_at` tool. Overall, it is a solid, functional description with minor gaps in usage guidance.

  4

  Purpose Clarity · 25%The description clearly states the tool returns values of signals over a time range, with a specific format ('the value at `from`, then each change, as `time value` lines'). It distinguishes from sibling `value_at` by implying a range of changes, though it doesn't explicitly contrast with it.

  3

  Usage Guidelines · 20%The description implies usage for retrieving signal values over a time range, but does not explicitly state when to use this over `value_at` or other siblings. It provides no exclusions or alternative guidance, leaving the agent to infer from the name and description.

  3

  Behavioral Transparency · 20%Annotations include readOnlyHint=true, which the description aligns with (no mutation implied). The description adds the output format detail (time value lines) and the inclusive end time, which is useful. However, it does not disclose potential large output sizes or performance implications, but given the read-only annotation, the bar is lower and this is adequate.

  3

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the schema, such as the output format and the inclusive nature of `to`. It does not elaborate on the `unit` or `radix` parameters beyond what the schema provides, so baseline 3 is appropriate.

  5

  Conciseness & Structure · 10%The description is a single, concise sentence that front-loads the core purpose and includes the output format. Every word earns its place, with no fluff or redundancy.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (5 params, 3 required) and full schema coverage, the description is sufficient. It explains the output format and the inclusive end time, which are not in the schema. No output schema exists, but the description covers the return format adequately. It could mention pagination or limits, but for a read-only signal query, this is complete enough.

  params

  5 (3 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  3

  bytes

  877

  hash

  d0350344818cf297

• view

  433354A3.6

  The description is clear and concise, effectively distinguishing the tool from its siblings. It leverages annotations well and provides sufficient context for a simple read-only tool. Minor improvements could include explicit usage guidelines, but overall it is well-crafted.

  4

  Purpose Clarity · 25%The description clearly states the tool's purpose: to describe the workspace in words, including rows, cursors, and visible range. It distinguishes itself from siblings by explicitly contrasting with 'render' and 'user_view', which are likely visual or user-specific views.

  3

  Usage Guidelines · 20%The description implies when to use this tool (to get a textual description of the workspace) and contrasts it with 'render' and 'user_view', but it does not explicitly state when not to use it or provide alternative tools for other scenarios. The guidance is clear but not exhaustive.

  3

  Behavioral Transparency · 20%Annotations already declare readOnlyHint=true, so the description does not need to repeat that. The description adds context about what the tool outputs (rows, cursors, visible range) and mentions the 'unit' parameter for time formatting, which is useful. However, it does not disclose any potential side effects or limitations beyond what annotations cover.

  3

  Parameter Semantics · 15%The schema description coverage is 100%, so the parameter 'unit' is already documented in the schema. The description adds a brief mention of 'unit' in the context of times, but it does not provide additional meaning beyond the schema. Baseline 3 is appropriate.

  5

  Conciseness & Structure · 10%The description is concise, with two sentences that pack essential information: what the tool does and how it relates to siblings. It is front-loaded with the main purpose and uses minimal words, earning a high score.

  4

  Contextual Completeness · 10%Given the tool's simplicity (one optional parameter, no output schema, read-only annotation), the description is complete enough. It explains the tool's output and the parameter's role, and the sibling references provide context. No major gaps are apparent.

  params

  1 (0 required, 100% described)

  annotations

  readOnly=true openWorld=false

  output schema

  no

  cost

  0

  bytes

  474

  hash

  9f53e29e591039ad

• workspace

  Shadowing Risk443444A3.8

  The description is concise and informative, clearly stating the tool's purpose as a one-call workspace setup. It effectively uses examples and references to help commands to guide usage. The main gap is not explicitly disclosing destructive behavior, but annotations cover that partially. Overall, a solid description for a complex configuration tool.

  4

  Purpose Clarity · 25%The description clearly states the tool sets up the whole workspace in one call, listing rows, cursors, range, and decodes. It mentions that it answers as `view` does, which distinguishes it from `view` as a bulk setup. However, it doesn't explicitly name sibling alternatives, so not a perfect 5.

  4

  Usage Guidelines · 20%It implies when to use: when you want to set up the entire workspace in one call, as opposed to incremental setup. It references `help workspace` for more details, and notes that it answers like `view`, giving context. It does not explicitly state when not to use it, but the 'in one call' phrasing suggests it's for bulk configuration.

  3

  Behavioral Transparency · 20%Annotations indicate destructiveHint=true, and the description implies that calling this might reset or replace the workspace configuration. It says 'Set up the whole workspace' and 'not given: it stays' (for scope), which hints at mutation behavior. However, it does not explicitly warn about destructive effects, and the idempotentHint=true suggests safe re-application. The description adds some context beyond annotations but could be clearer about potential overwriting.

  4

  Parameter Semantics · 15%Schema coverage is 100%, but the description adds valuable semantics beyond the schema. For example, it says 'rows, top to bottom: `name:radix:colour`' and references help commands, which clarifies the format. The description also explains that cursors are by number and marks can have names/notes, and it ties parameters to other tools (`decode`, `protocol`), helping the agent understand relationships.

  4

  Conciseness & Structure · 10%The description is very concise: two sentences, front-loaded with the main action. It uses compact examples and parentheses to add detail without verbosity. It earns its place, though it could perhaps be slightly more structured for complex workspace setup, but overall it is efficient.

  4

  Contextual Completeness · 10%Given the high schema coverage and the presence of nested objects, the description provides adequate context by pointing to help commands and examples. It explains the overall outcome ('answers as view does') and hints at scoping behavior. It doesn't describe return values, but since there is no output schema, and this is a setup action, that's acceptable. It's complete enough for a complex tool, though a bit more on reset behavior would help.

  params

  7 (1 required, 100% described)

  annotations

  readOnly=false destructive=true idempotent=true openWorld=false

  output schema

  no

  cost

  9

  bytes

  3868

  hash

  6db4eabb63f38357

• warningworkspace shadow-candidateworkspace (invocation cost 9) may be shadowed by values (cost 3): if both can answer the same question, an agent tends toward the cheaper call. Only the coherence evaluation can confirm the purposes overlap; if they do, make them disjoint and say so in both descriptions, or collapse the pair.
• infocommand no-output-schemacommand has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infofind no-output-schemafind has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infohelp no-output-schemahelp has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoinfo no-output-schemainfo has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoopen no-output-schemaopen has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infopresent no-output-schemapresent has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoprotocols no-output-schemaprotocols has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• inforecords no-output-schemarecords has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• inforeload no-output-schemareload has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• inforender no-output-schemarender has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infosessions no-output-schemasessions has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infosignals no-output-schemasignals has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infouse no-output-schemause has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infouser_view no-output-schemauser_view has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infovalue_at no-output-schemavalue_at has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infovalues no-output-schemavalues has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoview no-output-schemaview has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoworkspace no-output-schemaworkspace has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.

The badge shows the overall tier and score, and links here. The JSON is the same report the CLI's hosted mode prints.

[![TDQS](https://tdqs.dev/reports/shs1u2w5ee/badge.svg)](https://tdqs.dev/reports/shs1u2w5ee)

The same check from a terminal, a CI job or a script, with an API key from your account. Submitting spends one of the account's daily calls; reading the result spends nothing.

export TDQS_API_KEY=tdqs_...

# exit code 1 below B, so the command is the gate; uvx runs the same command from PyPI
npx mcp-tdqs score --file tools.json --hosted https://tdqs.dev --fail-under B

curl https://tdqs.dev/api/v1/reports \
  -H 'Authorization: Bearer tdqs_...' \
  -H 'Content-Type: application/json' \
  -d @tools.json

# poll the report it names until "status" is "completed"; this one is
curl https://tdqs.dev/api/v1/reports/shs1u2w5ee \
  -H 'Authorization: Bearer tdqs_...'

import { requestHostedReport } from 'mcp-tdqs';

const report = await requestHostedReport({
  apiKey: 'tdqs_...',
  hostedUrl: 'https://tdqs.dev',
  serverName: 'wtf',
  tools, // the tools/list result
});

if (report.score === null || !['A', 'B'].includes(report.score.serverScore.overallTier)) {
  throw new Error(`TDQS ${report.score?.serverScore.overallTier ?? 'failed'}: ${report.url}`);
}

from tdqs import parse_tool_definitions, request_hosted_report

parsed = parse_tool_definitions(tools_list)  # the tools/list result
report = request_hosted_report(
    api_key="tdqs_...",
    hosted_url="https://tdqs.dev",
    server_name="wtf",
    tools=parsed.tools,
)
tier = report.score.server_score.overall_tier if report.score is not None else None

if tier not in ("A", "B"):
    raise SystemExit(f"TDQS {tier or 'failed'}: {report.url}")