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

No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a read-only check via 'Check' and 'Counts', describes the count window ('since Monday'), and names the two data sources plus how they are combined. It omits minor details like timezone handling or output format, but the core behavior is transparent.

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 no filler. The first sentence states the purpose and threshold, while the second provides the necessary data-source detail. The structure is front-loaded and every clause 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?

For a zero-parameter, read-only quota tool, the description covers what is being counted, the time window, the threshold, and the source files. It does not describe the return format, which would be helpful, but the absence is acceptable given no output schema is declared.

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 effectively 100%. The description explains the meaningful inputs conceptually by naming the data sources and merge behavior, which is all that is needed here.

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 a specific check operation ('Check Work at a Startup weekly in-app application cap') and gives a concrete threshold (10/week). This distinguishes it from the sibling tools that handle authentication, search, submission, and listing.

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 usage context is clear: an agent should call this when it needs to know the current weekly application quota or remaining capacity. It does not explicitly name alternatives or exclusion cases, but with zero parameters and this narrow purpose, the intent is easy to infer.

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 behavioral disclosure burden. It does disclose key behaviors: it returns specific diagnostic arrays, accepts optional inputs, and requires login. However, it does not explicitly state that the tool is read-only/non-mutating, nor does it mention other potential side effects, limits, or error conditions.

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 core purpose and output, then details optional inputs and a prerequisite. Every clause adds information; there is no filler or 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 tool with no output schema, the description adequately explains return values (gaps[], wrong_dates[], etc.) and inputs, and flags the login requirement. It could be more complete by specifying what 'share/skills notes' contains or what triggers 'wrong_dates', but it already gives enough context for an agent to call the tool correctly with optional parameters.

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 100%, so the schema already documents both parameters. The description restates their purpose ('source_paths (resume/checklist markdown)', 'expect[] names for gap detection') but adds minimal new meaning beyond the schema. This is the baseline 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 uses a specific verb ('Diagnose') and resource ('profile entries'), and clearly distinguishes this audit tool from siblings like waas_get_profile, waas_update_profile, and waas_draft_profile by focusing on diagnostic output (gaps, wrong dates, etc.). An agent can immediately understand what this tool does and how it differs.

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 through context: it is for diagnosing profile issues, optionally using source_paths and expect[]. It states a prerequisite ('Requires login'). However, it does not explicitly say when to choose this over waas_preview_profile or waas_get_profile, and it lacks clear exclusions or alternative routing.

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

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

Annotations are absent, so the description carries the full burden. It discloses the files inspected (~/.waas-mcp/storage-state.json or cookie.txt), which adds some context, but it does not state whether the tool is read-only, what output it produces, or how it indicates success/failure. For a status check tool, this is notably incomplete.

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 concise sentence front-loads the action and resource, with the file path detail in a parenthetical. No wasted words; every element 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?

With no output schema and no annotations, the description should explain what the agent can expect from the call or when to use it, but it does not. The tool is simple, yet leaving out the return/status semantics and usage context makes it under-specified for an agent deciding how to act on the result.

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, so the schema already covers everything. Baseline 4 for zero params is appropriate; the description adds no parameter information, but none is needed.

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

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

States a specific verb ('Check') and resource ('Work at a Startup login session'), and even names the underlying storage files. This clearly distinguishes it from sibling tools like waas_search or waas_get_job, which perform entirely different actions.

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

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

No guidance on when to call this tool versus alternatives. It does not state that this should be used as a prerequisite before other waas tools, nor does it mention any conditions for usage. The agent is left to infer context from the name.

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

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

With no annotations, the description carries the full burden. It clarifies the tool does not write live, requires login conditionally, and returns a payload for dry_run, which is critical behavioral info. It doesn't disclose error handling or what happens when files are missing, but the core non-destructive behavior is well 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 three sentences with zero filler. It front-loads the primary purpose, immediately clarifies non-destructive behavior, and states the conditional login requirement. 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?

For a tool with 3 simple parameters, full schema coverage, and no output schema, the description is quite complete. It explains the output is an update_payload for dry_run, which is key. Missing are return structure details, but since no output schema exists, that could be a gap; however, the tool's simplicity and clear purpose mitigate this.

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 already covers all parameters at 100% with clear descriptions. The description adds value by hinting at file types (WAAS markdown, resume/bank files) and the semantics of compare_live, which supplements the schema. However, it doesn't detail how include_optional interacts with the payload, but schema covers its meaning.

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

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

The description clearly states it builds a paste-ready update payload from local drafts, a specific verb and resource. It distinguishes itself by explicitly noting it does not write live and pairs with waas_update_profile for dry_run, differentiating from siblings like waas_preview_profile and waas_update_profile.

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 preparing updates without writing, and mentions compare_live requires login. It does not explicitly list when not to use this tool versus alternatives, but the clear reference to waas_update_profile dry_run provides context. A slight gap is not stating scenarios where one should use waas_preview_profile or waas_audit_profile instead.

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 transparency burden. It discloses that the operation requires login, is validated, and defaults to a dry run. It does not explicitly state what happens when dry_run=false, but the schema's 'preview only' semantics plus 'Same write path' make the write behavior reasonably clear.

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

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

Three short sentences with no filler. The action and fields are front-loaded, followed by the dry-run default, the relationship to waas_update_profile, and the auth requirement. 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?

The description covers the core action, fields, validation, dry-run behavior, and login requirement. However, with no output schema and no annotations, it leaves out return values, precise validation rules, and a clear differentiation from waas_update_profile, so an agent may still be uncertain about edge behavior.

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

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

Schema description coverage is only 25%, so the description must compensate. It names all three editable fields and mentions validation, but does not add concrete constraints or formats for short_phrase, looking_for, or proud_project beyond what their parameter names imply.

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

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

The description states a specific action ('Update') and names the exact fields ('short_phrase / looking_for / proud_project'), making the tool's target unambiguous. It also connects to waas_update_profile by saying 'Same write path as waas_update_profile share fields', which helps distinguish it as the share-specific edit tool.

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 useful context: dry_run defaults to true, it shares a write path with waas_update_profile, and login is required. However, it does not explicitly state when to prefer this tool over waas_update_profile or other siblings, leaving the selection partly to inference.

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

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

With no annotations, the description carries the full burden. It does disclose the dry_run default and login requirement, which are key behaviors. However, it leaves the exact semantics of replace vs merge and the role of remove_ids/remove_names unspecified, and there is no annotation to fill these 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?

The description is a single, well-structured sentence. It front-loads the action, includes the maximum count and rating levels, and ends with the critical dry_run default. No filler or redundant phrasing.

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 5-parameter tool with no output schema and no annotations, this description is too thin. The two removal parameters (remove_ids, remove_names) are completely unexplained, and the merge/replace distinction is not elaborated enough for an agent to safely invoke the tool without guessing.

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 only 40%, so the description should compensate. It clarifies the mode and dry_run behavior, but it mostly repeats the enum and maxItems already present in the schema. It says nothing about remove_ids or remove_names, leaving two parameters effectively 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 states a specific operation ('Replace or merge') on a specific resource ('WAAS top skills') with clear constraints (max 10, rating levels). This clearly distinguishes it from siblings like waas_edit_share and waas_update_profile, which target different aspects of the profile.

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

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

It provides some usage context by naming the two modes (replace vs merge) and the default dry_run=true behavior, but it does not explicitly state when to prefer this tool over alternatives or mention exclusions. The intended usage is implied from the purpose, not explicitly routed.

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 present, so the description carries the full burden. It discloses a read-only intent with 'Fetch' and lists the returned data categories, which is useful. However, it does not mention authentication needs, error behavior, or response structure, leaving some transparency 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?

The description is a single front-loaded sentence with no filler. It communicates the action, resource, and key returned data efficiently.

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

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

For a simple one-parameter read tool, the description covers the core purpose and returned data. However, there is no output schema and no mention of auth or error behavior, so the description is minimally viable but not fully 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%, with the slug parameter clearly described as 'Company slug or /companies/acme URL.' The description does not repeat or extend parameter details, but the schema already provides sufficient meaning, so the 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?

The description clearly states the action ('Fetch') and resource ('company profile'), and adds useful scope ('founders, and open roles'). It implies differentiation from siblings like waas_get_job and waas_search by targeting a specific entity, though it does not explicitly name alternatives.

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 is provided about when to use this tool versus siblings such as waas_get_job or waas_search. There are no exclusions, prerequisites, or contextual cues beyond the tool name and resource, so the agent must infer 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?

No annotations are present, so the description carries the behavioral burden. It discloses that the tool works logged out for public pages and includes a workflow with safeguards like "Never auto-submit" and "Skip already_applied jobs." However, it does not explicitly state that fetching is read-only, describe error behavior, or clarify what happens for non-public jobs.

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 summary line is front-loaded and useful, and the workflow is numbered for readability. However, the description embeds a lengthy 10-step application workflow that concerns several sibling tools, not just waas_get_job. This is structured but not concise, and some steps go well beyond the tool's own behavior.

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 one-parameter fetch tool with no output schema, the description provides solid context: it names core returned fields (description, comp, visa, skills), explains logged-out access, and gives integration order relative to siblings. It could add return-format or error details, but the essential operational context 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 sole parameter job_id is already documented in the schema as "Numeric id or /jobs/123 URL," giving 100% schema description coverage. The tool description adds no additional parameter-level meaning beyond what the schema provides, so the baseline 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 opens with a specific verb and resource: "Fetch full job posting (description, comp, visa, skills)." This clearly distinguishes waas_get_job from siblings like waas_search or waas_list_applied. The title 'Get job posting' reinforces the same purpose without ambiguity.

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 required workflow explicitly positions this tool after waas_search or a user-provided URL and before waas_get_company and waas_inspect_application. It also notes "Works logged out for public pages," giving useful context about when authentication is not needed. It stops short of explicitly listing when-not-to-use alternatives, but the workflow 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 present, so the description carries the burden. It discloses the auth requirement ('Requires login'), signals a read-only operation via 'Fetch', and indicates data freshness with 'live'. It does not discuss errors or rate limits, but for a zero-parameter getter this is 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?

One sentence front-loads the action and resource, then compresses the field list with parentheticals and ends with the auth note. Every phrase 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?

For a no-argument read operation, the description tells the agent exactly what it will get (profile sections), whose profile ('your'), and what precondition is required (login). No output schema exists, but the field list provides the missing return-value context; no essential calling information is absent.

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

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

There are zero parameters and an empty schema, so there is no parameter semantics to clarify; baseline 4 applies. The description instead explains what will be returned (experience, education, skills, share copy, preferences), which adds value 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?

States a specific verb ('Fetch'), a concrete resource ('your live Work at a Startup candidate profile'), and enumerates the major profile sections. The word 'live' separates it from draft/preview siblings, so an agent can distinguish intent even without opening the tool.

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 gives clear context: use it to retrieve the current saved profile, and it flags that login is required. It does not explicitly name alternatives like waas_preview_profile or waas_draft_profile, but 'live' and 'your' are enough to imply the appropriate use case.

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

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

With no annotations provided, the description carries full behavioral disclosure. It explains exactly what the tool returns, what applicationType values mean, how applyBlocked should gate submission, and that external applications must be reported rather than auto-submitted.

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 front-loaded with what the tool returns, followed by a clearly numbered workflow. Though long, every line adds operational value: order, alternatives, stop conditions, and approval gates. The structure makes it easy to follow.

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 role in a multi-step application flow, the description covers prerequisites, ordering, conditional branches, auth handling, and safety requirements. It names return fields and applicationType variants even without an output schema, so an agent has enough context to invoke it correctly.

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

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

Schema coverage is 100%, and the schema already documents job_id as either a numeric id or a /jobs/123 URL. The description does not add parameter-level detail beyond that, so the baseline 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 states a precise verb and resource: inspecting an application form to return applicationType, required fields, external apply hints, and applied status. This clearly differentiates it from sibling tools like waas_get_job, waas_search, and waas_submit_application.

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 required WORKFLOW explicitly orders this tool after quota checks and job/company retrieval, names the sibling alternatives at each step, and gives clear stop conditions for external, needs_login, and weekly_limit_reached cases. It also instructs to skip already_applied jobs and never auto-submit.

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 behavioral burden. It discloses that the data comes from a local tracker file (~/.waas-mcp/applied.json), implying a local read operation with no network dependency, and 'List' signals non-destructive behavior. It does not mention ordering or return format, but the core behavioral context is 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 sentence that front-loads the core action and resource, then adds the useful local tracker path. Every word contributes value with 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 zero-parameter, local-only list operation, the description is largely complete: it states what is listed, the scope, and the data source. The only minor gap is the absence of return-shape details, since no output schema exists, but for a simple list operation this is not a significant obstacle.

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 100% schema description coverage, so there are no parameter semantics for the description to clarify. Per the baseline for zero-parameter tools, the description appropriately has nothing to add beyond confirming the scope.

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 ('List') and a clear resource ('jobs you've submitted via this MCP'), and it distinguishes this tool from siblings like waas_search and waas_get_job by scoping to the user's own submitted applications. The local tracker path further disambiguates its exact 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 clearly conveys that this tool is for listing jobs submitted through this MCP and stored locally, which implies it is the right choice when tracking one's own applications rather than searching all jobs. It lacks an explicit 'use X instead when...' statement, but the context is strong enough for an agent to decide correctly.

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 behavioral disclosure burden. It conveys that this is a read-only fetch operation, lists the returned content, and notes that login is required. This is meaningful context beyond the tool's name and title.

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. It front-loads the core purpose, lists the returned data fields, gives the intended use case, and states the auth requirement. 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?

This is a simple, parameterless, read-only preview tool with no output schema. The description covers what the tool returns, why it should be used, and its auth requirement. Nothing an agent needs to invoke it correctly is missing.

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, so parameter-semantic coverage is fully satisfied by the empty schema. The description appropriately avoids inventing parameter details; the baseline of 4 applies because there is no parameter information to provide.

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 ('Fetch') and resource ('founder/company-facing rendering of your WAAS profile'), and clarifies this is the same data as the in-app Preview iframe. This clearly distinguishes it from sibling tools like waas_get_profile or waas_update_profile, which deal with raw or editable profile data.

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

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

It explicitly states when to use the tool: after edits, to QA without asking the user to click Preview. It does not explicitly list exclusions or name alternative sibling tools, but the trigger condition is concrete enough for an agent to select it appropriately.

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 side effects and safety. It only mentions that the tool 'Builds the search URL automatically' and is a search operation, implicitly non-mutating, but does not state whether it modifies state, has rate limits, or what it returns. The 'Never auto-submit' instruction is about the agent's workflow, not the tool's behavior, so it does not clarify search 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 opening two sentences are concise and front-loaded. However, the description then appends a 10-step workflow that spans multiple sibling tools, making the definition overly long and diluting focus on the search tool itself. The workflow could be a separate reference; embedding it in this tool's description is not concise.

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 9 parameters (5 undocumented), no output schema, and no return-format description, the agent lacks critical context for invoking the tool correctly. The workflow mentions later steps (waas_get_job + waas_get_company) but does not describe what waas_search actually returns, how results are paginated, or how to handle ambiguous enums. This is incomplete for a structured search 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?

Input schema covers only 44% of parameters with descriptions (4 of 9). The description adds no meaning for sort_by, us_visa, job_type, has_equity, or has_salary. It merely refers to 'structured filters' generically. It even introduces 'weeklyQuota' which is not in the schema, adding confusion rather than compensating for the parameter coverage gap.

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

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

The first sentence clearly states the tool's function: 'Search YC Work at a Startup jobs with structured filters.' It also adds a distinct behavioral note ('Builds the search URL automatically'). Step 2 contrasts it with waas_get_job, helping differentiate it 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?

Step 2 provides a conditional alternative: use waas_search with structured filters, or waas_get_job if the user supplies a URL. The workflow also instructs to skip already_applied jobs. However, the guideline is embedded in a multi-step workflow rather than stated as a crisp when-to-use rule, and there is no explicit 'do not use' condition.

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

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

With no annotations, the description carries the full transparency burden, and it more than meets it: dry_run defaults to true, auto-submission is forbidden, explicit approval is required, weekly quota and applyBlocked are checked, and external/needs_login cases are handled. This is unusually clear about side effects and guardrails.

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?

Although long, the description is tightly structured: the one-line purpose is front-loaded, and the numbered workflow is dense with actionable instructions. The repetition of 'never auto-submit' and the approval requirement reinforces a critical safety rule rather than wasting space.

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 is highly complete for pre-submission behavior, covering quota checks, context gathering, inspection, dry-run approval, and blocked cases. It does not describe the expected result or error behavior after a real dry_run=false submission, which would be useful given there is 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 description adds meaning to 'answers' by pointing to waas_inspect_application fields and reinforces the dry_run default. However, job_id is only present in the schema and inferred from the workflow steps rather than explicitly described, leaving a small semantic gap.

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

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

The description clearly states the tool submits application answers and distinguishes it from sibling tools by referencing waas_inspect_application fields and the submission workflow. It also clarifies what this tool is not for: external applications, blocked/limit-reached applications, and login-required applications.

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 a mandatory 10-step workflow that names the exact sibling tools to call before submission and specifies conditions that should stop the agent from submitting. It explicitly states when not to submit and requires explicit user approval before dry_run=false.

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 transparency burden. It discloses the dry-run default, the before/after diff return, the approval requirement for real writes, and the login prerequisite. This is meaningful behavioral context beyond the schema, though it doesn't describe side effects or error behavior.

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

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

Three dense sentences, front-loaded with the action, then helpers, then the critical dry-run/approval guardrail. Every sentence earns its place; no filler or repetition.

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

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

The tool is complex (5 nested params, no output schema, low schema coverage), and the description covers the central safety flow (dry-run -> approval) but omits details like response format for real writes, error conditions, and how sections interact. Adequate but with clear gaps.

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

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

Schema description coverage is only 20%, so the description needs to compensate. It adds practical semantics for the experience helpers (fix_dates, set_current, rename, remove_match, remove_ids, order) and explains dry_run's role, but it doesn't explain the share, education, or skills payload semantics beyond what the schema already states.

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 states a specific verb and resource: 'Write Experience/Education, Skills, and/or Share on your WAAS profile.' That is clear, but it does not differentiate from sibling tools like waas_edit_skills and waas_edit_share, so it stops short of a 5.

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

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

Provides key usage guardrails: dry_run defaults to true, returns before/after diff, and dry_run=false requires explicit user approval; also states login requirement. However, it gives no explicit guidance on when to use this tool vs alternatives (e.g., waas_edit_skills for skills-only edits), so usage context is implied rather than explicit.

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