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

With no annotations, the description carries full burden. It discloses that authorizing makes logging in and writing on the host no longer dry-run, and that revoking stops real mutations. It also notes it's the gremlin mutation opt-in, not discovery verification. Side effects are implied but not exhaustive (e.g., no mention of permissions or rate limits).

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: a few sentences with front-loaded purpose, no redundant words. It efficiently conveys the tool's intent, usage, and caveats.

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

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

No output schema exists, but the description explains behavioral outcomes (authorize/revoke) and differentiates from discovery verification. It mentions ownership requirements and host format. Adequate for an agent to decide when to use this tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining host is a bare hostname with an example, and clarifies allow_mutation's default and effect. Note is optionally mentioned but no extra semantics.

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 authorizes real mutations for the gremlin on a host, distinguishes it from discovery DNS-domain verification, and specifies it is not related to payments. The verb 'authorize' and resource 'domain' with mutation context are specific and differentiated from siblings.

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

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

The description explains when to use (to authorize mutations), how to revoke (set allow_mutation=false), and what constitutes a valid host (bare hostname, host you own or staging). It explicitly differentiates from discovery verification. No explicit 'when not to use' is given, but context is clear.

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 fully carries the burden: it discloses the tool is mutating, idempotent, returns a URL for human action, and explains the error case (409 no_stripe_customer) with remediation steps.

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

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

Three sentences, front-loaded with the main action and return value. Every sentence adds value: purpose, error handling, and behavioral traits. No extraneous 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?

Given no output schema, the description explains the primary return (portal_url) and error handling. It is fairly complete, though additional detail about the response format would elevate it to 5. However, it is sufficient for an agent to understand and invoke the tool.

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

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

Schema coverage is 100% and already provides detailed descriptions for both parameters. The tool description adds no additional meaning beyond what is in the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states it opens the Stripe customer portal for the workspace, returning a URL for human management of subscription, card, or invoices. It distinguishes from siblings by mentioning prufa_upgrade_plan as a prerequisite when no customer exists.

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 describes when to use (manage subscription, card, invoices) and what to do on error (pass back 409 and redirect to prufa_upgrade_plan). Does not explicitly list when not to use, but the context is sufficient.

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, description discloses mutating and idempotent nature, and that payment is handled via external URL. Lacks rate limits or auth details but covers key behaviors.

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 concise sentences plus key tags; no wasted words. Front-loaded with essential purpose and outcome.

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

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

No output schema but description states return value (checkout URL). All params documented. Sibling tools indicate this is a distinct purchase action; sufficient for selection.

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 already covers all param descriptions (100%), but description adds context about idempotency key and checkout URL, enhancing understanding beyond 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?

Verb 'Buy' specifies action, resource 'prepaid credit pack' is precise, and description distinguishes from subscription changes (contrasts with prufa_upgrade_plan).

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 states use case: 'when workspace is low on credits but you don't want to change the plan', providing clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses the core behavior: confirms the flow, makes it runnable, idempotent, and optionally accepts a corrected spec. It does not cover error cases or what happens if the flow is already confirmed, but it is sufficient for safe usage.

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 efficient sentences. The first states the purpose and a key constraint; the second covers required input, optional override, and idempotency. No unnecessary words.

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

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

The description covers inputs and outcome, but lacks details on return values, error handling, or what the response looks like. Since no output schema exists, this is a gap, though the schema covers parameter details.

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 67% (2/3 parameters described). The description adds value beyond the schema for the 'spec' parameter, explaining its optional overriding behavior. However, it does not add detail for flow_id or idempotency_key beyond what the schema provides.

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 confirms a draft flow to make it runnable, using the specific verb 'Confirm'. It distinguishes from sibling tools like prufa_edit_flow (which edits drafts) and prufa_run_flow (which runs confirmed flows) by specifying the state transition.

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 clear context: confirm a draft flow to make it runnable. It implicitly indicates when to use this tool, but it does not explicitly contrast with alternatives like prufa_edit_flow for editing the draft 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?

With no annotations, the description fully compensates by disclosing key behaviors: the flow does NOT run yet, returns a 201 draft with step spec and detected variables, and is idempotent. No contradictions.

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

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

Four informative sentences with no fluff. Purpose stated first, followed by parameters, return value, and usage context. Every sentence earns its place.

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

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

Given the tool's complexity, lack of output schema, and siblings, the description is complete. It explains the return value, includes review instruction, and directs to confirm_flow. No missing critical information.

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 description adds meaning beyond the schema: explains url, test_case, name, and idempotency_key purpose. Schema coverage is 75%, but the description enriches all parameters, especially idempotency_key.

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 'compile a plain-language test case into a reviewable DRAFT flow spec', specifying the verb and resource. It distinguishes itself from sibling prufa_confirm_flow by emphasizing that this only creates a draft and does not run.

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 clear guidance: pass target url and test_case, optionally name. It explicitly states the next step ('review the draft, then call prufa_confirm_flow') and distinguishes from the sibling tool.

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

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

With no annotations, the description carries full burden. It discloses idempotency and a specific error case (409 flow_in_use), but does not mention other behavioral traits like required permissions, rate limits, or response format. The description adds some value beyond the schema.

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

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

The description is extremely concise, consisting of two short sentences with a crucial note. It is front-loaded and every word serves a purpose.

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

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

Given no output schema and no annotations, the description covers the core action, an error condition, and idempotency. For a simple delete tool with 2 parameters, this is fairly complete but could optionally mention the response format.

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 50% (flow_id lacks description, idempotency_key is described). The description says 'by id' for flow_id, which is redundant and adds no new meaning. For idempotency_key, the schema already explains it. The description does not compensate for the missing schema description.

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

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

The description clearly states 'Delete a flow by id' which is a specific verb+resource. It distinguishes from sibling tools like prufa_create_flow, prufa_edit_flow, and prufa_get_flow by being the delete operation.

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

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

The description explains the prerequisite condition (flow used by a monitor returns 409) and the remedy (pause or delete that monitor first). However, it does not explicitly name alternative tools like prufa_pause_monitor or prufa_delete_monitor, though it implies their use.

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?

Discloses idempotency, retention of past runs, and revocation of deploy hook. No annotation support available, so description carries burden; no contradictions.

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?

Extremely concise: 3 key points in 2 sentences. No filler.

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

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

Covers main behavioral aspects for a delete operation. Could mention undoability or permissions, but sufficient for simple tool.

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

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

Schema coverage is 50%, but description adds no new parameter info beyond schema's idempotency_key description. The 'Idempotent' statement reduces redundancy but doesn't clarify monitor_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?

Clearly states 'Delete a monitor' and details effects: stops future runs, revokes deploy hook, retains history. Distinguishes from sibling tools like pause_monitor.

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?

Implied usage from 'Delete a monitor,' but no explicit when-to-use vs alternatives (e.g., pause_monitor) or prerequisites (e.g., [Pro] plan).

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, description carries full burden. It discloses the key behavioral trait that editing returns the flow to DRAFT state, and that the operation is idempotent. Does not detail auth needs, rate limits, or error handling, but covers major 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 concise sentences. First sentence defines action and required parameters. Second sentence provides critical behavioral note. No unnecessary words.

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

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

Lacks description of return value or error conditions, which is important for a state-changing tool with no output schema. However, covers key behavioral context (draft state, idempotency key) and sibling differentiation. Somewhat complete but missing return info.

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 67% (flow_id lacks schema description). Description adds context for flow_id (implied by 'Pass flow_id') and reinforces spec's role as 'full replacement spec'. Idempotency_key is well-described in schema; description adds no new semantics. Baseline 3 due to coverage, with marginal added value.

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 'Replace' and resource 'flow's spec'. It explicitly lists required parameters (flow_id, spec) and distinguishes from siblings like prufa_create_flow and prufa_confirm_flow by focusing on replacement.

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?

Provides explicit usage context: any edit returns to DRAFT and requires calling prufa_confirm_flow again. Mentions idempotent behavior. Does not explicitly state when not to use or alternatives, but the note is strong guidance.

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

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

No annotations are provided, so the description carries the full burden. It describes a read operation but does not disclose any side effects, authentication requirements, rate limits, or limits on data returned. For a simple get, it lacks details about what happens if discovery_id is invalid.

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

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

The description is a single sentence with a list of returned fields and a cross-reference to another tool. It is efficient but could be improved by separating the field list or using bullet points for clarity.

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

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

For a simple tool with one parameter and no output schema, the description covers the essential purpose and a follow-up action. However, it is incomplete regarding parameter details and behavioral context, such as what constitutes a valid discovery_id.

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

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

The schema coverage is 0%, and the description does not explain the discovery_id parameter beyond its implied role. No format, constraints, or examples are given, leaving the agent to infer meaning from context.

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 retrieves a discovery run's status and the surfaced flows, listing specific fields. It distinguishes from siblings like prufa_run_discovery (which initiates runs) and prufa_confirm_flow (which confirms drafts).

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 use after a discovery run and mentions the follow-up action (prufa_confirm_flow). However, it does not explicitly state when not to use it or list alternatives like prufa_get_run for run 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 must carry the full burden of behavioral disclosure. It only states that the tool gets findings and mentions flat machine-readable format, but does not disclose whether it is read-only, required permissions, rate limits, error behavior, or side effects. Minimal 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?

Description is extremely concise with two sentences, no fluff. Verb and resource are front-loaded. Every sentence adds value: first states purpose and format, second states optional filtering.

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

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

For a simple get tool with 2 parameters and no output schema, the description gives basic purpose and filtering. However, it does not describe return value format (e.g., array of objects), possible errors, or state what a 'finding' is. With no annotations or output schema, more context would be beneficial.

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 50% (finding_key has description, run_id does not). Description adds value by explaining that finding_key filters to a single finding, but does not elaborate on run_id meaning. With half parameters undocumented in schema, description provides some additional context but not full compensation.

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?

Description clearly states the tool gets persisted findings for a run, specifies flat machine-readable format, and explains filtering by finding_key. It is specific about the resource (findings for a run) and distinguishes from siblings like prufa_get_run or prufa_get_report.

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?

Description implies when to use (retrieve findings for a run) and how to filter, but lacks explicit guidance on when not to use, prerequisites, or mentions of alternative tools among siblings. No exclusions or context 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?

With no annotations, the description carries full burden. It usefully notes that credential names are returned but not their values. However, it does not disclose whether the operation is read-only, requires authentication, or any side effects.

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

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

The description is a single, well-structured sentence that states the action, required input, and output content. Every word adds value; there is no redundancy or filler.

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

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

For a simple retrieval tool with one parameter and no output schema, the description covers the key return elements (spec, status, credential names). It could mention error cases or permissions, but overall it is adequate for the tool's complexity.

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

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

The schema has 0% coverage (no description for flow_id). The description indicates that the parameter is the flow's ID, but provides no additional details about format, source, or constraints. A simple string parameter does not require much explanation, but more could be added.

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 retrieves a single flow by ID and lists the returned fields (compiled spec, status, credential names). This distinguishes it from sibling tools like prufa_list_flows (which lists multiple flows) and prufa_edit_flow (which modifies).

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 the tool is for getting detailed information about a specific flow, but it does not explicitly state when to use it versus alternatives like prufa_list_flows or prufa_get_report. No when-not-to-use or prerequisite information is 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 full burden. It discloses that it returns config and state fields, and the '[Pro]' tag suggests a plan requirement. However, it does not describe error behavior (e.g., missing monitor), permission needs, or side effects.

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

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

The description is a single sentence that front-loads the core purpose. It is concise, but could benefit from additional structure (e.g., separating config and state). No superfluous words.

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

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

Given the simplicity (1 param, no output schema, no nested objects), the description provides fundamental details. However, it lacks explanation of output format, error cases, or usage context, leaving the agent to guess about return structure.

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 input schema has one parameter (monitor_id) with 0% description coverage. The description adds no context about what monitor_id is, where to get it, or its format. For a tool with low schema coverage, the description must compensate but fails to do so.

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 'Get', the resource 'one monitor', and specifies what is returned: 'config + latest state (status, cadence, last run, deploy-hook metadata)'. This distinguishes it from sibling tools like prufa_list_monitors (listing all) and mutation tools.

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

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

The description implies usage for retrieving a single monitor's details but provides no explicit guidance on when to use this vs. alternatives (e.g., list_monitors) or when not to use it. No prerequisites or exclusions 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?

With no annotations provided, the description carries the full burden. It discloses the OR relationship between run_id and share_token and recommends the latter. It doesn't specify behavior when neither is provided (likely error), rate limits, or response details. This is adequate but leaves some gaps.

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 concise sentences with no wasted words. Key information is front-loaded: what the tool does, and immediately followed by input options and recommendation.

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 no output schema and only two optional parameters, the description covers the essential context: input alternatives and a recommendation. It doesn't describe the output format, but for a simple retrieval tool this is likely sufficient. Could add note about response structure if not obvious.

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

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

Schema coverage is 100% with both parameters described. The description adds value by explaining the mutual exclusivity and recommending share_token, which is not evident from the schema alone. This goes beyond a baseline of 3.

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

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

The description clearly states it gets a JSON report for a run, distinguishing it from sibling tools like prufa_get_run which retrieves a run object. The verb 'Get' and resource 'JSON report for a run' are specific and unambiguous.

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

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

The description explicitly tells when to use this tool (to get the report for a run) and recommends the share_token parameter. It implicitly distinguishes from alternatives by focusing on report retrieval. However, it doesn't explicitly state when not to use it or mention alternative tools for related tasks.

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 should disclose behavioral traits like read-only nature, idempotency, or required permissions. It does not. It only states the operation, leaving the agent uncertain about safety or side effects.

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

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

The description is very concise (one sentence) and front-loads the core purpose. However, it could be rephrased to include essential details without adding length.

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 the simplicity (1 param, no output schema), the description covers the basic purpose but fails to mention return format, error scenarios, or whether it returns the full run object. Completeness is adequate but not thorough.

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%, meaning the description adds no meaning beyond the schema. It does not explain what 'run_id' is, how to obtain it, or any constraints. The single parameter is completely undocumented.

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

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

The description clearly states the action ('Get'), the resource ('run'), and the purpose ('status by id'). It also lists possible status values, which adds specificity and distinguishes from sibling tools like prufa_list_runs (which lists runs) and prufa_get_flow (which gets flows).

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 when you have a run ID and need its status, but does not explicitly state when to use this tool versus alternatives (e.g., prufa_list_runs for finding runs). No guidance on prerequisites or exclusion 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 provided, but the description uses 'Get' which strongly implies a read-only, non-destructive operation. It does not explicitly state side effects or safety, but the verb is sufficient.

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, no fluff. First sentence states the output, second gives usage guidance. Front-loaded with essential information.

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

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

No output schema exists, but description lists all return components (credit usage, trial state, upsell block, message_for_human). Combined with usage context, it provides a complete picture for the agent.

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?

No parameters exist, so schema coverage is 100% trivially. The description adds meaning by detailing the output fields (credit usage, trial state, upsell block), providing context beyond the empty 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?

The description clearly states the tool returns workspace credit usage, trial state, and upsell block. It distinguishes from siblings like prufa_buy_credits and prufa_billing_portal by focusing on read-only usage info.

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 advises to use before costly runs to check balance and relay message_for_human if low. This provides clear context for when to invoke the tool.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns tier, usage/credits, trial state, and upsell blocks, and even details what gets gated when the trial ends. However, it does not mention authentication needs or side effects, though as a read-only 'get' tool, no destructive behavior is 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?

Two sentences, front-loaded with 'Get the current workspace', and no unnecessary words. Every sentence adds value by listing what is included and a special behavior (upsell block).

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 no output schema or annotations, the description provides sufficient detail about the tool's return values (tier, usage/credits, trial state, upsell block) to enable correct use. There are no parameters to explain, and the description fully compensates for missing structured documentation.

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 input schema has no parameters, so the description adds all meaning beyond the schema. It explains the output content in detail. Per calibration, with 0 parameters and high schema coverage, a baseline of 3 is appropriate, but the description's thoroughness warrants a 4.

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 'get' and the resource 'workspace', and lists specific aspects returned (tier, usage/credits, trial state, upsell block). It effectively distinguishes this from siblings like prufa_get_usage (which likely focuses on usage details) and prufa_billing_portal.

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 for fetching workspace status, but does not explicitly mention when to use this tool versus alternatives or provide any when-not guidance. Sibling tools exist (e.g., prufa_get_usage, prufa_upgrade_plan) but no comparisons are made.

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 burden. It clearly discloses sensitive behavior (returns decrypted passwords) and includes a critical security restraint. However, it does not describe behavior when no saved logins exist (e.g., returns empty list or error), which is a minor gap.

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

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

The description is extremely concise: one sentence conveys purpose, sensitivity, scope, and usage instruction. Every word earns its place; no fluff.

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?

Although there is no output schema, the description specifies the return value as 'DECRYPTED email+password,' which is sufficient to understand the return content. It does not detail the exact structure (e.g., single object vs. array) or error handling, but given the tool's simplicity, this is 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?

With zero parameters and 100% schema description coverage, baseline is 4. The description does not need to add parameter info; it correctly implies the tool requires no input.

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 returns decrypted credentials for previously used logins, with a specific verb ('returns') and resource ('DECRYPTED email+password'). It distinguishes from siblings by specifying it's for gremlin runs in the current workspace, contrasting with tools like prufa_set_flow_credentials that set rather than retrieve credentials.

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 states when to use: 'so a kickoff can reuse them' and provides a direct usage instruction: 'pass them straight into prufa_run_gremlin's credentials.' Also gives a clear negative guideline: 'Never print these values' and 'Only for the owning workspace,' leaving no ambiguity about safe handling.

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?

Although no annotations are provided, the description clearly states it is always free and requires no token, indicating no authentication or cost. The term 'probe' suggests a simple, non-destructive read operation. This adds behavioral context beyond the empty schema.

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

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

The description is extremely concise with two short sentences. The first sentence immediately states the purpose, and the second adds key behavioral info. No unnecessary words.

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

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

For a tool with no parameters and no output schema, the description covers the essential purpose and behavioral traits (free, no token needed). It is sufficient for an agent to correctly select and invoke this health check 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?

The input schema has zero parameters, and schema description coverage is 100% (vacuously). The description adds value by explaining the tool is a free, tokenless health check, which is not apparent from the schema alone.

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

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

The description clearly states it probes the Prufa API and MCP server, which is a health check. This is distinct from all sibling tools, which focus on specific operations like auth, billing, flows, monitors, etc. The verb 'probe' and the resource are specific and unambiguous.

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

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

The description implies this is a health check, free and requiring no token, but does not explicitly state when to use or when not to use. No alternatives are mentioned, but among siblings there is no other health check tool, so the guidance is adequate but not 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. It states the tool returns data (not destructive) and mentions sorting and inclusion of suppressed alerts. However, it does not disclose any authentication requirements, rate limits, or behavioral details beyond the obvious read operation.

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

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

The description is a single sentence that directly states the tool's output, ordering, and special inclusion. Every word adds value; it is highly concise and front-loaded with the most important information.

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

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

Despite the tool's simplicity, the description lacks a full account of the return format. It mentions alert history and suppression reasons, but does not describe fields like timestamp, severity, or identifiers. With no output schema, the description should provide more detail about the returned objects.

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 input schema has zero parameters, so schema coverage is 100%. The description does not need to explain parameters. Baseline for 0 parameters is 4, which is met since the description adds no unnecessary parameter info.

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 returns alert history from the delta-engine ledger, sorted newest first, and includes suppressed alerts with suppression reasons. The name also implies listing. No sibling tool lists alerts, so differentiation is not needed.

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 alternatives. It does not mention when not to use it or suggest any prerequisites or context. For a simple list tool, some basic context would help.

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 burden. It clearly lists the returned fields (id, domain, status, etc.) and mentions the TXT record for pending domains, which is behaviorally transparent. However, it does not explicitly state that the operation is read-only or describe any rate limits or authentication requirements.

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

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

A single sentence that is perfectly concise, front-loaded with purpose, and includes a detailed list of fields. Every word earns its place without redundancy.

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

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

For a simple list tool with no parameters and no output schema, the description provides complete information: the action (list), the scope (workspace's discovery domains), and all returned fields (including conditionally for pending domains). No gaps remain.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty). The description adds value by enumerating the output fields, which compensates for the lack of parameters. Baseline 4 is appropriate as there are no parameters to document.

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 'List' and resource 'this workspace's discovery domains', and distinguishes from sibling tools like prufa_register_discovery_domain and prufa_verify_discovery_domain by specifying the exact fields returned.

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 for viewing domains but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The list of returned fields is informative, but the context of when to use this tool versus other discovery domain tools is left implicit.

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 must disclose behavioral traits. It indicates a read operation (listing) but does not mention potential side effects, pagination, or rate limits. For a simple list, this is adequate but not exemplary.

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

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

The description is a single sentence with no unnecessary words, efficiently conveying the tool's purpose and output.

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 no parameters and no output schema, the description covers the essential action and return fields (status, metadata). It could mention that it lists all flows in the workspace, but it is sufficiently complete for a list operation.

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 input schema has no parameters (coverage 100%). The description does not add parameter-level info since there are none, meeting the baseline of 3 for high schema coverage.

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 action (list) and the resource (flows), and specifies that it returns status and metadata, distinguishing it from siblings like prufa_get_flow or prufa_confirm_flow.

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 (e.g., prufa_get_flow for details, prufa_confirm_flow for status changes). The description implies a simple list but offers no when-not or explicit context.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not state whether the operation is read-only, destructive, or requires authentication. While listing is likely safe, the description omits key behavioral traits beyond the list content.

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?

Single sentence with clear verb 'List' at the start. No redundant or filler language. Every word adds value: scope (authorized hosts), action (real gremlin mutations), returned fields, and plan level. Excellent 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?

For a simple list tool with zero parameters and no output schema, the description covers what is returned (hosts with fields and default policy). It does not mention pagination, ordering, or limits, but given the tool's simplicity, this is nearly complete. Lacks mention of potential empty result 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?

Input schema has zero parameters, so baseline is 4 per guidelines. Description adds no parameter information, but no parameters exist. The description's content about output fields does not relate to parameters, but that is acceptable given the empty 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?

Description clearly states the tool lists authorized hosts for real gremlin mutations, including specific fields (allow_mutation flag, note, created_at) and default policy. The [Pro] designation adds context. This verb+resource combination is distinct from sibling tools like prufa_list_discovery_domains or prufa_authorize_domain.

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?

Description implies usage (to see authorized hosts) but provides no explicit guidance on when to use vs. alternatives like prufa_list_discovery_domains or prufa_authorize_domain. No 'when not to use' or context for exclusions. Adequate but lacks proactive guidance.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It reveals a 50-delivery limit and explains the never_fired flag, but does not disclose read-only nature, authorization needs, or any side effects.

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

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

The description is two sentences with no filler. The main action is front-loaded, and the second sentence adds essential context about the never_fired flag.

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

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

No output schema exists, so the description should clarify the return format. It mentions a list of deliveries and CI snippets, but omits fields, ordering, or pagination. Adequate but not complete.

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

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

Schema description coverage is 0%, so the description must explain the parameter. It implies 'monitor_id' identifies the monitor, but does not specify format, source, or other details. This is minimal compensation.

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 lists a monitor's last 50 deploy-hook deliveries and provides CI snippets. The mention of 'never_fired:true' adds specific behavior. It distinguishes from sibling tools like prufa_list_monitors by focusing on deliveries.

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 the tool should be used when needing delivery history or CI snippets, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives.

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 must disclose behavioral traits, but it only includes a '[Pro]' tag. It does not mention permissions, side effects, pagination, or limits, leaving agents with minimal guidance.

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?

Single sentence, no wasted words, perfectly front-loaded with the core action and resource.

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

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

For a simple list-all tool with no parameters and no output schema, the description is nearly complete. It could hint at return structure, but the lack is minor.

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

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

No parameters exist, so the baseline is 4. The description does not need to explain parameter semantics beyond what the schema already provides.

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 action (list) and resource (monitor) with scope (every in this workspace), distinguishing it from sibling tools like prufa_get_monitor which retrieves a single monitor.

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 for listing all monitors but does not explicitly mention when to use alternatives like prufa_get_monitor for specific monitors or contrast with other list 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?

With no annotations provided, the description bears full burden. It only discloses 'auth required' but omits read-only nature, rate limits, or other behavioral traits. The list operation is implicitly non-destructive but not confirmed.

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

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

The description is a single sentence that conveys the core function without fluff. It is appropriately front-loaded, though it could incorporate parameter details without losing 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?

Given the simplicity (1 parameter, no output schema), the description is incomplete: it does not explain 'recent', default limit, pagination, or ordering. The parameter is completely undocumented, leaving the agent with insufficient context.

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%, yet the description does not mention the single parameter 'limit'. It adds no meaning beyond the schema's default value, leaving the agent uninformed about its effect or usage.

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 action (List) and resource (recent runs) with scope (in this workspace). It implicitly distinguishes from siblings like prufa_get_run (single run) or prufa_list_flows (flows), but lacks explicit differentiation.

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

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

No guidance on when to use this tool versus alternatives like prufa_get_run or prufa_list_flows. There are no when-not contexts or prerequisites mentioned beyond 'auth required'.

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 covers key behaviors: stops cadence, keeps history, idempotent, and [Pro] feature. It does not detail what happens to running instances or permission requirements, but for a pause action it is sufficient.

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 concise: four short statements covering purpose, effect, state, and plan requirement. No wasted words.

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

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

Given no output schema and simple parameters, the description is largely complete. It could mention the return value (e.g., updated monitor), but the core functionality is well-covered.

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 50% (only idempotency_key described in schema). The description adds no additional parameter context beyond the schema. The monitor_id parameter is left unexplained, but the schema provides its type.

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 'Pause a monitor' with the specific verb and resource. It distinguishes from siblings like prufa_resume_monitor and prufa_delete_monitor by describing the effect (stops cadence, keeps history, idempotent).

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 when to use (to pause a monitor) and notes idempotency, but does not explicitly exclude alternatives or state prerequisites. However, the sibling context makes usage clear.

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 provided, so description carries full burden. It discloses that the result is a draft (not final), returns specific fields (flow_id, status, review_url), and explains idempotency key behavior. No contradictory claims.

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 efficient sentences. First sentence front-loads purpose and resource. Second sentence adds critical behavioral context (draft status, return values, [Pro] tag). No filler.

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

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

Covers return format and idempotency. Lacks mention of error cases or prerequisites (e.g., existence of gremlin report). However, given the tool's simplicity (3 params, no output schema), the description is fairly 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 coverage is 100% and description adds meaning: path_index is zero-based, share_token is public share token, idempotency_key's retry safety explanation adds value beyond schema definitions.

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?

Clearly states the tool imports a reproduced gremlin path (by its index) as a DRAFT flow. The verb 'import' and resource 'gremlin path' are specific, and the draft status distinguishes it from sibling tools like prufa_confirm_flow or prufa_create_flow.

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?

Explains when to use (import a reproduced path as draft) and what comes next (review + confirmation required). It implies the need for a subsequent confirmation step, but does not explicitly list alternatives or contexts where this tool should be avoided.

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 must disclose behavioral traits. It explains the verification workflow, the purpose of idempotency_key, and the test_payments_opt_in flag. However, it does not mention whether the operation is destructive, rate limits, or required permissions beyond the [Pro] prefix. Still, it provides substantial transparency.

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 and well-structured, with the main purpose upfront. Every sentence adds value: the core action, the follow-up step, the optional parameter, and a clarifying note. No wasted words.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description is quite complete. It covers the workflow, response contents, idempotency, and a parameter use case. It could mention behavior for already-verified domains, but overall it provides sufficient context for correct tool usage.

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

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

Schema coverage is 100%, but the description adds meaning beyond parameter descriptions. It explains that the response includes a verification object, that idempotency_key replays return original response, and the effect of test_payments_opt_in. This extra context elevates the score above the baseline of 3.

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

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

The description clearly states the tool registers a domain for full-auto discovery and returns a DNS TXT record for verification. The verb 'register' and resource 'domain' are specific, and it distinguishes from sibling tools like prufa_verify_discovery_domain and prufa_revoke_discovery_domain.

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 when to use this tool (register domain for verification), what the response contains (verification object), and the next step (call prufa_verify_discovery_domain after publishing the TXT record). It also notes the test_payments_opt_in parameter and that this authorization is separate from gremlin mutation opt-in, providing clear context.

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

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

No annotations are provided, but the description discloses key behaviors: it returns a new run_id, blocks or returns queued state based on wait, and mentions idempotency_key for safe retries. It does not cover potential errors or rate limits.

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

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

Two sentences, front-loaded with the main action, then details on wait and idempotency. No wasted words, highly 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?

Despite no output schema, the description adequately explains return values ('new run_id' and 'report' for wait=true). All essential parameters are covered, and the [Pro] tier hint is included.

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 description adds meaning beyond the input schema by explaining the wait parameter behavior in detail, while the schema only provides defaults. The schema covers 67% of parameters, and the description compensates for the missing wait description.

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

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

The description uses a specific verb ('Re-dispatch a past gremlin run') and resource ('gremlin run') and clearly distinguishes from sibling tools like prufa_run_gremlin (which creates new runs) and prufa_get_run (which fetches existing ones).

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 states when to use ('re-dispatch a past gremlin run with the SAME intent') and explains the wait behavior, but does not explicitly mention when not to use or provide alternatives like prufa_run_gremlin for different parameters.

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 full burden for behavioral disclosure. It conveys useful behavior: immediate execution of the next scheduled run, return to normal cadence, and idempotency. However, it omits potential error cases (e.g., if monitor is not paused), authentication requirements, or side effects beyond resumption. Partial transparency.

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 concise: three short sentences front-loading the action and key behaviors. Every sentence adds value: the action, the immediate execution effect, and idempotency. No wasted words, making it efficient for an AI agent to process.

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

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

For a simple resume operation, the description covers the core action and key behavioral trait (immediate execution). However, it lacks details on edge cases (e.g., state when already running), potential errors, return value (no output schema), and the role of the idempotency_key parameter. Adequate but not fully complete for a tool with no annotations and no output schema.

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

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

The input schema has 2 parameters (monitor_id required, idempotency_key optional) with 50% schema description coverage (idempotency_key has a description in schema, but monitor_id does not). The description adds no parameter-level information, failing to compensate for the missing schema description of monitor_id. An agent must infer its purpose from context.

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 action: 'Resume a paused monitor.' It specifies the effect ('The next scheduled run fires immediately, then it returns to its cadence'), making the purpose unambiguous. The verb 'Resume' and resource 'monitor' are specific, and the tool is distinguished from siblings like prufa_pause_monitor and prufa_start_monitor by explicitly targeting a paused state.

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 alternatives. It does not mention prerequisites (e.g., monitor must be paused), nor does it exclude scenarios (e.g., if monitor is already running). No explicit 'when to use' or 'when not to use' information is 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; description discloses key behaviors: de-authorization, refusal of future discovery, tearing down disposable identities, response content, and idempotency. Lacks details on reversibility or error handling but adequate for its simplicity.

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. Every word adds value. No redundancy.

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

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

Given no output schema or annotations, description is largely complete. It explains the action, consequences, idempotency, and response. Could mention error conditions or prerequisites but not critical.

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

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

Schema coverage is 100%; description mentions response reports identities_torn_down but adds no extra meaning for the two parameters beyond what the schema provides (domain_id and idempotency_key). Baseline 3 applies.

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

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

Clearly states 'De-authorize a discovery domain' with specific consequences (future discovery refused, disposable identities torn down) and idempotency. Differentiates from siblings like 'prufa_authorize_domain' (opposite action) and 'prufa_register_discovery_domain' (registration).

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?

Implied usage: use when you need to revoke a domain's authorization. The sibling 'prufa_authorize_domain' is the inverse. However, no explicit when-not or alternatives 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?

Since no annotations are provided, the description carries full burden. It discloses one-time response, immediate expiration of old secret, idempotency, and behavior of idempotency_key. This is rich behavioral context, though it could mention potential side effects like delivery failure if CI is not updated.

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 compact sentences with no extraneous words. The critical action and caveats are front-loaded. Every sentence adds value.

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

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

With 2 parameters, no output schema, and no annotations, the description covers the essential behavioral details (one-time secret, idempotency). Missing a brief note on response format or example, but overall sufficient.

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 50% (idempotency_key described). The description adds meaning for idempotency_key (prevents re-execution on retries) but does not describe 'monitor_id' beyond its necessity. It partially compensates 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?

The description uses the specific verb 'rotate' with the resource 'monitor's deploy-hook signing secret', making the action unambiguous. It distinguishes itself from sibling tools like 'prufa_start_monitor' or 'prufa_trigger_monitor' by focusing on secret rotation, which is unique.

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 clear guidance: store the new secret immediately and update CI before the next delivery because the old secret dies at once. It does not explicitly state when not to use it, but the context is sufficiently directive.

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 fully discloses key behaviors: free, anonymous, idempotent, blocking vs. non-blocking via wait, return types (findings JSON or queued state), and the workspace_unlock restriction for anonymous results. All important traits are 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?

The description is a single, well-structured paragraph that front-loads the core purpose. Every sentence adds value without redundancy. However, it is dense, which might slightly reduce readability; a minor structure improvement could break it into bullet points.

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 no output schema, the description adequately covers return values (findings JSON with grading and queued state), idempotency, free tier, and the workspace unlock block. All pertinent information for an agent to use the tool correctly is present.

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

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

The schema coverage is 0%, but the description adds meaning to both parameters: 'url' is clearly the target URL, and 'wait' is explained with its effect on blocking vs. polling. The description clarifies the default value and behavior, which goes beyond the schema's minimal naming.

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 opens with a clear action: 'Run a one-shot public-page QA audit on a URL.' It uses a specific verb and resource, and the context distinguishes it from sibling tools like prufa_get_report (fetching reports) and prufa_run_flow (running flows).

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 explicitly states when to use the tool: for a free, no-key-required audit. It also explains when not to rely on it (anonymous limitations lead to deeper checks needing a workspace) and provides an alternative: prufa_setup_workspace. The wait parameter behavior is clearly explained, including polling with prufa_get_report.

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?

Describes start of discovery, return object fields, idempotency_key behavior, and error conditions. No annotations provided, so description carries full burden. Could mention limits on concurrent discoveries.

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

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

Two sentences with essential details, front-loaded with purpose. No fluff, every sentence earns its place.

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

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

Covers return fields, prerequisites, errors, and polling. Missing details like polling interval or status values, but output schema is absent so description compensates.

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 50% (only idempotency_key has schema description). Description adds meaning: url is target, idempotency_key for retry safety. Without description, url's purpose would be vague.

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?

Description clearly states it starts a full-auto discovery run on a URL, crawls site, infers user flows, and drafts them. It distinguishes from sibling tools like prufa_get_discovery (polling) and prufa_authorize_domain (domain setup).

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?

Explicit prerequisites (paid/trial tier, verified domain) and error handling (403, 404), plus polling instruction (prufa_get_discovery). Could be improved by explicitly stating when not to use (e.g., use prufa_run_audit for other purposes).

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?

Discloses key behaviors: returns 202 accepted, idempotent with key, credentials encrypted/not stored, fails on draft. No annotation given, so description carries burden. Missing details on side effects like credit consumption or rate limits, but overall adequate.

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?

Concise, front-loaded with main action, then returns, then credential details, then condition and idempotency. No superfluous information. Every sentence adds value.

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 3 params, nested objects, and no output schema, the description covers purpose, prerequisites, return value, follow-up, credential handling, idempotency, and failure case. Lacks error response details but acceptable for a run tool returning 202.

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 67% (2 of 3 params described). Description adds meaning: explains credentials object structure with example, clarifies idempotency key effect. Flow_id lacks description but is self-evident. Compensates for schema gaps effectively.

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 action ('Execute a CONFIRMED flow') and specifies the resource (flow). It distinguishes from siblings like prufa_confirm_flow and prufa_get_report by mentioning prerequisites and follow-up endpoint.

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?

Provides guidance on when to use: only for confirmed flows, with note to confirm drafts first. Mentions alternatives for storing credentials (prufa_set_flow_credentials). Lacks explicit comparison with other run tools (prufa_run_audit, etc.) but sufficiently covers common usage.

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 full burden and reveals key behaviors: dry-run unless authorized, no payments, credential requirements, wait behavior, plan-dependent step budget. Lacks error/timeout details but still strong.

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?

Packed with information but slightly lengthy. Front-loaded with core purpose, then conditions and details. Could be more concise but well-structured with clear sections.

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 no output schema and a complex tool, the description covers purpose, usage, behavior, dependencies, parameters, and plan limits. Defines return format for wait=true/false. Very 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 coverage is 50%; description adds context for url, wait, credentials, and idempotency_key beyond schema. Provides usage guidance for wait and idempotency, and prerequisite for credentials.

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 runs a gremlin chaos-QA session on a URL, imitating a difficult user with plain-code detectors. It distinguishes itself from sibling tools like prufa_run_audit and prufa_run_flow.

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 mentions when to use (stress-test real flows beyond deterministic audit), when not to use (mutations only dry-run unless authorized), and alternatives (prufa_authorize_domain, prufa_get_usage for budget).

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 provided, so description carries full burden. Discloses write-only behavior ('values are never returned'), idempotency, and response format (lists only names). Covers all essential behavioral traits without contradiction.

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?

Only three sentences, each adding value: first states purpose, second explains how to use (required params), third describes response and idempotency. Front-loaded with key information, no redundancy.

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

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

Given the tool has 3 parameters (one nested object), no output schema, and no annotations, the description fully covers what the tool does, what to pass, behavioral traits (write-only, idempotent), and response content. No gaps remain for an agent to misinterpret.

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 covers 67% (credentials and idempotency have descriptions). Description adds context: flow_id is identified as a required identifier; credentials map to 'the spec's {{VARIABLES}}', linking to flow spec variables. This supplements the schema's sparse flow_id 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?

Clearly specifies 'Store reusable, WRITE-ONLY credentials for a flow', indicating the verb (store) and resource (credentials for a flow). Distinguishes from sibling tools like prufa_create_flow, prufa_edit_flow, prufa_run_flow by highlighting the credential storage purpose.

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?

Provides context: credentials are stored for later runs to avoid resending them. Implicitly suggests using this when you have credentials to reuse, but does not explicitly list alternatives or when not to use. The idempotency mention offers guidance on safe retries.

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 describes validation behavior (422 errors) and response structure (cells and locked_events). It also indicates a Pro limitation. However, it does not disclose destructive nature or auth requirements.

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

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

Two sentences, front-loaded with action, no redundant information. Every sentence provides essential detail about the tool's operation.

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 description covers return values and validation, but lacks information about permissions and side effects. Given no output schema, it provides adequate context for a setter 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?

The schema has 100% coverage and the description adds value by explaining validation of keys and types, and the locked_events concept. This adds context beyond the schema's description of the parameter.

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

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

The description clearly states the tool sets the notification routing matrix, a specific verb-resource combination. It distinguishes from sibling tools by focusing on notification routing, which is unique among the listed tools.

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

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

The description provides context on when to use the tool (to set routing), but does not explicitly exclude alternative tools. It mentions validation and response behavior, which guides usage implicitly.

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 fully discloses creation behavior, trial duration, gated features, token persistence, and idempotency. No contradictions.

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 thorough and logically structured, but slightly verbose. Every sentence serves a purpose, so still high quality.

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 complexity (setup vs read, trial, credits, idempotency) and no output schema, the description covers all necessary aspects for correct agent use.

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

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

Schema coverage is 100%, but description adds value by explaining that name and owner_email are ignored when token is set, and idempotency_key behavior (replays return original response).

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 bootstraps or reads a Prufa workspace, with specific verb+resource. It distinguishes from siblings by focusing on workspace setup, which is unique among many sibling tools.

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

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

Explicit guidance is given: when to create vs read, idempotency key for retries, and alternatives like prufa_upgrade_plan or prufa_buy_credits for post-trial actions.

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 discloses idempotency via idempotency_key, that deploy_hook is returned once and must be stored immediately, and that free-tier gets a 402 with a pass-through hint. It does not detail failure modes or monitor creation timing.

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 well-structured with front-loaded purpose in 4 sentences. Slightly verbose but no unnecessary words; could be tightened slightly while maintaining clarity.

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 no output schema, the description explains the deploy_hook return and storage requirement, plus idempotent behavior. Missing details like monitor ID or status, but sufficient for a start operation.

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 description adds meaning beyond schema for all 4 parameters: url, cadence (enum repeated), flow_id (contrast with plain audit), and idempotency_key (makes retries safe). Compensates for 50% schema coverage with clear context.

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 starts a persistent monitor that re-runs QA audits on a cadence and fires a deploy hook on regression deltas. It uses specific verbs ('Start') and resources ('monitor'), and distinguishes from one-off tools like prufa_run_audit.

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 explicit context on when to use flow_id vs plain audit and mentions free-tier behavior (402 error with checkout hint). However, it does not explicitly contrast with sibling tools like prufa_run_audit or prufa_trigger_monitor.

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 discloses key behaviors: rate limit (1 per 60s), dedup on concurrent runs, idempotency, and Pro tier requirement. It does not detail the return format or error conditions, but covers the most important behavioral traits.

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 three sentences with zero waste. Each sentence adds distinct value: action, constraints, idempotency + tier. Front-loads the core purpose and then details caveats 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?

Given no output schema and only 2 params, the description covers rate limits, dedup, and idempotency. It does not explain the response shape (though mentions deduped:true) or monitor_id format. For a simple trigger tool, it is nearly complete but could detail error handling or response on success.

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 has 50% description coverage (only idempotency_key described). The description adds context for idempotency_key ('pass one to make retries safe') but does not describe monitor_id. The overall behavior (trigger a run) clarifies the role of monitor_id indirectly, but parameter-specific additions are minimal.

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 ('Trigger') and resource ('a monitor run') with immediate context ('right now (out of band)'). It distinguishes from siblings like prufa_start_monitor or prufa_run_flow by specifying it's for monitors and happens immediately, with dedup behavior.

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 constraints (rate cap, dedup, idempotent) but does not explicitly guide when to use this tool over siblings like prufa_get_run, prufa_list_runs, or prufa_pause_monitor. It implies on-demand triggering but lacks explicit comparisons or scenarios.

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 provided, so the description bears full responsibility. It discloses that the tool is mutating and idempotent, describes the return value, and notes the agent's role restriction. However, it lacks details on side effects (e.g., what happens if already subscribed) or dependencies (e.g., workspace setup).

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 concise: three sentences with no redundancy. Each sentence adds critical information: purpose, human action requirement, and behavioral characteristics (mutating, idempotent, trial).

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 no output schema, the description adequately explains the return value ('Stripe checkout_url'). It covers the trial, idempotency, and agent limitation. It could mention error scenarios or prerequisites, but the tool is simple enough that this level of detail suffices.

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 input schema has 100% description coverage, so the baseline is 3. The description does not add meaningful parameter information beyond the schema; it only lists the tier options already in the enum. The idempotency_key behavior is already well-described in the schema.

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

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

The description clearly states the tool's purpose: 'Subscribe or upgrade this workspace to a paid plan' and lists the specific tiers ('starter | pro | team'). It distinguishes itself from sibling billing tools like prufa_billing_portal (manage existing) and prufa_buy_credits (purchase credits) by focusing on plan subscription/upgrade.

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 explicit guidance: the agent never enters card details and returns a Stripe checkout URL for the human to open. It describes the trial period and idempotency behavior. It could be improved by noting when not to use (e.g., if workspace already on a plan), but the context is clear enough.

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 fully explains idempotency, the return statuses ('verified' vs 'pending'), and that DNS propagation may be needed. It provides sufficient behavioral context for an agent to understand what to expect.

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 two sentences, front-loaded with the action, and every word adds value. No redundant information.

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

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

Given the lack of output schema, the description adequately explains the return statuses. It covers the essential behavior for a verification tool but could mention potential errors or prerequisites (e.g., domain must be registered).

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

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

Schema coverage is 100%, providing descriptions for both parameters. The overall description adds value by explaining how the parameters relate to the outcome (status based on DNS resolution), though it does not add per-parameter specifics beyond the schema.

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

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

The description clearly states it checks the DNS TXT proof for a registered discovery domain, specifying the action and resource. It distinguishes from siblings like prufa_register_discovery_domain and prufa_list_discovery_domains by focusing on verification.

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 after registering a domain to verify the TXT record. It provides clear context but does not explicitly list when not to use or mention alternative tools for other actions.

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 exist, so the description is the sole source of behavioral disclosure. It reveals idempotence, the need for a saved card for auto_recharge, and partial updates. However, it does not cover permissions, error states, or return value 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?

The description is a single well-structured sentence with a parenthetical clarification for auto_recharge. It front-loads the core action and covers key details without redundancy.

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

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

Given the complexity (10 parameters, no output schema), the description adequately covers what the tool does and how to use it. It explains partial updates and idempotency. However, it does not describe the return value or error conditions, which would be helpful.

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 low (20%), but the description adds meaningful context for several parameters. For example, auto_recharge is explained as 'auto-buys credits when a launch is blocked on an empty balance — needs a card on file,' and auto_recharge_credits/auto_recharge_monthly_limit_cents are grouped. However, parameters like display_name and email_alerts_enabled lack elaboration.

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 updates workspace settings and enumerates specific settings (display_name, usage webhook, overage opt-in, auto_recharge, etc.), distinguishing it from sibling tools that deal with domains, billing, flows, or monitors.

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 advises to pass only keys to change and notes that at least one setting is required. It also explains idempotent behavior. While it doesn't explicitly compare to alternatives, the sibling tool names are distinct enough that usage context is clear.

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