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?

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?

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?

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?

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.