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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description explains the tool 'verifies' claims and returns a report, but doesn't state whether this is read-only, whether it modifies session state, what side effects occur, performance characteristics, or how the verification works. For a diagnostic/analysis tool with zero annotation coverage, more behavioral context is warranted.

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

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

The description is compact and well-structured with Args/Returns sections. It earns its space with the three-category result explanation (verified, unverified, inconsistencies). Minor waste: returning 'JSON with consistency check results' is partly redundant given that an output schema exists, but overall it's efficient and readable.

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

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

Given an output schema is present, return format doesn't need elaboration. The tool is moderately complex (a multi-faceted consistency analysis). However, the description covers the core behavioral scope and parameter. Gaps: no mention of failure modes, edge cases for empty sessions, or how results relate to registered documents/DSL. Adequate but not fully complete for a diagnostic tool.

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

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

Schema description coverage is 0%, and the description only restates the parameter name ('session_id: Session ID') without adding semantic detail — no explanation of what a valid session ID looks like, where to obtain one, or what happens with an invalid/absent session. The description does not compensate for the zero schema coverage, so the single parameter remains underdocumented in meaning.

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

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

The description clearly states 'Run full consistency check on the session' — a specific verb+resource combination. It explains what the check verifies (claimed vs unverified claims vs logical inconsistencies). It doesn't explicitly distinguish from sibling tools like parseltongue_get_state or parseltongue_query, though the scope ('full consistency check') is reasonably distinct.

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 use this tool versus alternatives. There's no statement of prerequisites (e.g., whether a session must exist first, whether documents must be registered before the check), no when-not-to-use guidance, and no mention of expected preconditions. The description implies usage (on a session) but doesn't explain context like when consistency checking is appropriate.

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

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

The description states that the tool 'clears all state' while 'keeping the session alive', which clarifies that this is a destructive operation on session content (not the session itself). It also states the return format (JSON with clear status). However, with no annotations provided, the description could add more behavioral context such as whether this is reversible, what 'all state' includes (registered documents, loaded DSLs, etc.), and any side effects on future operations.

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

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

The description is compact and follows the Args/Returns structure, covering the essential purpose in minimal words. The front-loaded first sentence clearly states the core behavior. It earns high marks for efficiency, though the Returns line is marginally useful as it just restates that a JSON status is returned.

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

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

For a single-parameter tool with an output schema, the description is reasonably complete. The first sentence distinguishes the destructive scope (clear all state) from session lifecycle (keep alive). However, given the sibling tools like register_document, load_dsl, and get_state, the description could clarify what 'all state' covers (e.g., does it clear loaded DSLs, registered documents, query history?) to help the agent understand full impact.

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

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

Schema description coverage is 0%, so the description must compensate. It names session_id in the Args section, which adds a small bit beyond the schema (the schema only has a type and title). However, it doesn't provide extra context about what session_id must refer to (e.g., a session created by parseltongue_create_session) or whether it accepts any valid session ID. With only a single, self-explanatory parameter, the marginal gap is modest.

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 clearly states the tool's purpose: 'Clear all state from a session, keeping the session alive.' This uses a specific verb (clear) with a specific resource (session state) and adds the important nuance that the session itself persists. It's distinct from siblings like get_state (read) and create_session (lifecycle), though it doesn't explicitly name those distinctions.

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

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

The description implies usage context: it's for when you want to reset a session's contents without destroying the session. It doesn't explicitly state when NOT to use it or offer alternatives (e.g., 'use parseltongue_create_session for a fresh session' or 'use parseltongue_query to review state first'). Given the sibling set, there's room for more explicit guidance on when this is the right choice versus creating a new session.

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 full behavioral disclosure burden. It doesn't state what happens on duplicate session_id (error? overwrite?), whether sessions expire, or what the status response contains. The description says 'JSON with session creation status' which is minimal.

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

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

The description is efficiently short with a clear purpose statement, an Args section documenting the single parameter, and a Returns note. Every sentence earns its place with minimal waste.

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?

This is a simple one-parameter creation tool with an output schema, so the completeness bar is lower. However, for a session lifecycle tool within a family of 8 siblings, the description doesn't clarify important context like duplicate handling, session limits, or how this fits into the workflow (create → register_document → load_dsl → check_consistency).

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%, so the description must compensate. The description does add a small amount of value by providing an example format ('sec-filing-review') for the session_id, clarifying it's a unique identifier. However, with only 1 parameter, the schema already conveys it's a required string identifier, so the added value is marginal.

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

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

The description states a clear verb+resource: 'Create a new Parseltongue verification session.' It specifies what it does (creates a session) and gives an example session_id format. It distinguishes itself from siblings like parseltongue_list_sessions or parseltongue_clear_session by being the session-creation tool, though it doesn't explicitly call out those distinctions.

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

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

The description implies usage (called before registering documents/loading DSL in a session workflow) but doesn't explicitly state when to use it vs alternatives like list_sessions or clear_session. No exclusions or prerequisites are given, such as whether a session already exists or needs to be cleared first.

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 disclosure burden. It correctly implies a read-only operation (getting reference docs), but doesn't state the size or format of the returned string, whether it's cached, whether network access is needed, or any mutation. The read-only nature is only implied, not explicit, and with zero annotations this is a gap.

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

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

The description is concise with two short sentences. The 'Returns: Full DSL reference as a string' is slightly redundant given the output schema exists, but it's not bloated. It's appropriately sized for a documentation-fetch tool, though front-loading could be marginally improved.

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 documentation reference tool with 0 parameters and an output schema, the description is largely adequate. However, it could mention that this is the foundational reference for using the other parseltongue_* tools, which would help establish workflow context. The completeness is acceptable given the tool's simplicity, but leaves the relationship to sibling tools unstated.

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

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

The tool has 0 parameters, so there's nothing for the description to elaborate on. With 100% schema description coverage and no parameters to document, the input schema fully defines the tool's inputs. Baseline 4 for a zero-parameter tool is appropriate.

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

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

The description clearly states it 'Gets the Parseltongue DSL reference documentation' with a specific verb+resource. It's distinguishable from siblings since no other tool would fetch DSL reference docs. However, the 'Returns: Full DSL reference as a string' section is somewhat redundant with the output schema present, and it doesn't differentiate from what siblings like parseltongue_load_dsl might offer, which could be a complementary action.

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's no explicit when-to-use guidance or exclusions. It doesn't clarify when an agent should consult this reference vs. loading the DSL (parseltongue_load_dsl) or when it's appropriate to reference the documentation during a workflow. The context implies it's for understanding the DSL, but no explicit trigger conditions or alternatives are mentioned.

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 disclosure burden. It does state the return contents (facts, derives, axioms, verification status) which is useful. However, it doesn't disclose behavior if the session doesn't exist, whether it's a read-only operation (implied by 'get' but not stated), or performance/latency characteristics. Some value added beyond the schema, but not comprehensive.

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?

Description is compact and front-loaded with the core purpose in the first line. The Returns section and Args section are appropriately placed. Minor redundancy: 'Get current state of the session' followed by restatement of returns. Slightly under the 5 mark because the return value explanation partially duplicates the intent.

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 don't need exhaustive detail in the description, and the description does list the key returned fields (facts, derives, axioms, verification status). However, this is a state-retrieval tool in a session-based workflow; the description doesn't explain how the state relates to other session tools (e.g., does it show the same data that create_session and register_document affect?). Adequate but leaves workflow context implicit.

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

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

Schema description coverage is 0%, but with only 1 parameter (session_id) the description mentions it in the Args section with a 'Session ID' label. The description adds marginal value by naming the parameter in context, and a single simple string parameter doesn't require deep semantic explanation. With minimal schema, the description names the param which is adequate given its simplicity.

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?

Clear purpose: 'Get current state of the session' with specific verb (get) and resource (session state). Distinguishes from siblings by listing what it returns (facts, derives, axioms, verification status) - this differentiates it from query, list_sessions, and others. Not a perfect 5 because it relies on the session_id param rather than stating a distinct use case scope, but the purpose is specific and clear.

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 guidance on when to use this tool vs alternatives. It doesn't explain how this differs from parseltongue_query (querying session facts) or parseltongue_check_consistency. No exclusions or alternatives noted. The description implies it's for retrieving full session state but provides no decision guidance for the agent.

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 full behavioral disclosure burden. It merely states what it returns ('JSON with list of sessions') but doesn't disclose whether sessions are sorted, paginated, what session fields are included, or whether this is a read-only operation. The 0-parameter tool has the safety profile entirely unaddressed.

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

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

The description is extremely short and front-loaded with the purpose. The Returns section is slightly redundant with the 'List all active sessions' line and could arguably be trimmed, but there's no waste given there's no parameter content needed.

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

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

Given this is a simple 0-parameter list operation with an output schema present, the description is reasonably complete. However, given no annotations and an empty input schema, the description could still add value by disclosing behavioral traits like whether sessions are ordered, how many are returned, or how to interpret the list. It's minimally adequate but leaves the return semantics open.

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

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

The tool has 0 parameters with 100% schema coverage, so there's nothing for the description to add. Per guidelines, 0 params warrants a baseline of 4 since the description has no parameter documentation burden.

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

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

The description states it lists active sessions with a specific verb and resource. However, it doesn't clarify what 'active' means versus other possible session states or distinguish it from siblings like get_state or dsl_reference. The purpose is clear but lacks distinguishing 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?

No guidance on when to use this tool versus alternatives. With siblings like create_session, get_state, and clear_session, there's no context explaining when listing sessions is appropriate or how it differs from checking a specific session's state.

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 disclose that the tool returns 'verification status including any quote mismatches (hallucinations)', which is useful behavioral context about what the tool checks. However, it doesn't state whether loading replaces existing session content, appends to it, or requires a valid session to exist. For a mutation-like operation with zero annotations, more behavioral disclosure would be expected.

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

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

The description is reasonably structured with a summary line, a list of parsed content types, and an Args/Returns section. The content list (facts, axioms, defterms, derives, diffs) is useful and compact. Minor redundancy exists since Args/Returns restate what parameters and output schema already convey, but the structure is efficient.

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 tool parses complex DSL content, returns verification results including hallucination detection, and has siblings covering sessions, documents, and consistency checking. An output schema exists (so return format isn't the description's burden), but given the complexity of DSL loading and the 0% schema coverage, the description could explain what 'quote mismatches' mean, how loading interacts with existing session state, and why this differs from register_document. It's minimally adequate.

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%, so the description must compensate. It does enumerate the two parameters (session_id and dsl_source) with brief explanations ('Session ID' and 'Parseltongue DSL source code'). However, it adds no format details—DSL source syntax, expected size, encoding, or version constraints are all absent. The explanation of dsl_source as 'Parseltongue DSL source code' is somewhat tautological for someone unfamiliar with the DSL.

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 clearly states the verb ('Load Parseltongue DSL into the session') and specifies the resource (DSL content) with what it parses (facts, axioms, defterms, derives, diffs). It distinguishes from siblings like create_session and register_document since it's specifically about loading DSL source. Could be slightly stronger in naming the session target explicitly, but the core purpose is clear.

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

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

The description provides no guidance on when to use this tool versus siblings like parseltongue_dsl_reference, parseltongue_register_document, or parseltongue_check_consistency. It's ambiguous whether this is the initial ingest step, an update mechanism, or how it relates to session lifecycle. No exclusions or alternative recommendations are provided.

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

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

No annotations are provided, so the description carries the full burden. It fails to disclose whether this is a read-only evaluation, whether it can mutate state, what the query's side effects might be, whether the session must have a loaded DSL first, or what error behavior looks like for malformed WFFs. Returns are described only as 'JSON with query result' without structure.

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

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

The docstring-style structure (Args/Returns) is familiar and compact, with zero wasted prose. However, the content is under-specified—merely parroting parameter names rather than enriching them—so while concise, it sacrifices substantive information for brevity.

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?

Despite an output schema existing (helps with return contract), this is a domain-specific query tool (parseltongue, WFF, sessions, DSL) with no in-description guidance about formula syntax, session requirements, or relationships to sibling tools. The description leaves the agent to discover critical context about what a WFF is and what querying entails.

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?

Input schema has 0% description coverage and both params (session_id, wff) have only type+title. The description merely restates the parameter names in the Args section without adding syntax, format, or semantics. Notably, the wider description (WFF, session) is in the Args/Returns, which is the only added value over schema. It fails to explain what a valid wff looks like or where session_id originates.

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

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

The description states it queries the system with a well-formed formula (WFF), giving a verb+resource that distinguishes it from session/document management siblings. However, 'query the system' is somewhat generic and doesn't clarify what kind of query (e.g., does it evaluate a CSL/DSL formula, a safety condition, a temporal query?). The term 'WFF' likely ties to parseltongue_check_consistency or dsl_reference siblings but the relationship isn't explicit.

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 provided on when to use this vs alternatives. It doesn't mention that session_id must come from parseltongue_create_session, or how this relates to check_consistency, load_dsl, or the dsl_reference tools. The agent has to infer context from sibling names.

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 provided, the description carries the full burden. It explains the side effect of registration (fact extraction becomes possible with :evidence block citations), which goes beyond the basic mechanical description. It doesn't address things like whether re-registering the same name overwrites, whether session must exist, or content size limits, but the evidence-citation behavior is genuinely useful behavioral context.

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

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

The description is compact, front-loaded with the primary purpose, includes an Args block and Returns block, and adds the important evidence-citation detail early. No wasted prose. Slightly more verbose than strictly necessary, but the structure is clear and scannable.

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

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

There is an output schema available for the JSON return, so the Returns line is sufficient. The tool has only 3 simple string parameters with no nesting, making it moderately simple. The description covers purpose, side-effect behavior, parameters, and return type. It doesn't address edge cases (duplicate names, non-existent session), but for a simple registration tool this is reasonably complete.

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

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

Schema description coverage is 0%, so the description must fully compensate. It provides meaningful semantics for all three parameters: session_id as 'Session ID', name as 'Document name (referenced in :evidence blocks)', and content as 'Document text content'. The parenthetical on name adds real value beyond the schema, explaining how 'name' is used downstream for citation.

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 clearly states the verb ('Register') and resource ('a source document'), and explains the purpose: 'for evidence grounding' with facts that can 'cite it with :evidence blocks'. It distinguishes from siblings like query, check_consistency, and get_state which operate on already-registered data, whereas this one ingests new documents.

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

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

The description explains the mechanism ('Facts extracted from this document can cite it with :evidence blocks'), which implies when use is appropriate — registering documents that should be evidence sources. However, it does not explicitly state when NOT to use it or name alternative tools, and doesn't mention prerequisites like requiring an existing session before registration.

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