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

With no annotations, the description carries the full burden and largely meets it: it discloses the deterministic weighted rubric with explicit weights, the decision taxonomy (APPLY/MAYBE/DO_NOT_APPLY/MANUAL_REVIEW), hard-reject reasons, and learnable-vs-critical gap classification. It does not address side effects, whether the master profile is fixed/implicit, or rate limits, but behavioral disclosure is unusually strong for a no-annotation tool.

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 dense sentences that front-load the method (weighted rubric) before the outputs. The weight enumeration is long but earns its place by disclosing the scoring model; no filler sentences.

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 compensates by enumerating return contents (breakdown, decision, hard-reject reasons, gap categories), which is what an agent needs to consume results. The nested JobPosting structure and the implicit master-profile dependency are the remaining 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 coverage is 100%, so the single 'job' parameter is documented in the schema as a JobPosting object; the description adds no format or structural detail beyond that. One noteworthy implicit dependency — that scoring happens against a 'master profile' not passed as a parameter — is mentioned but not clarified. 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?

States a specific verb and resource ('Score a job posting against the master profile') and names the exact scoring mechanism, making it clearly distinct from siblings like tailor_resume or track_application. An agent immediately knows this is the evaluation/scoring 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?

Usage is implied by the scoring semantics (use it to decide whether to apply), but there is no explicit when-to-use statement, no when-not conditions, and no named alternatives among the siblings. The context is reasonably inferable but not spelled out.

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 carry the behavioral burden, and it does disclose a real trait: LEARNING/UNSUPPORTED skills are deliberately never surfaced as competencies, so callers understand the filtering rule. However, it omits that this is a read-only operation, how results are ordered or structured, and whether anything is mutated.

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 front-loads the core purpose ('what the master profile can and cannot support') and uses the colon clause to enumerate the two result categories. 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?

With no output schema, no annotations, and no parameters, the description is the sole carrier of meaning, and it does explain the two output categories and the exclusion rule. It stops short of describing the shape of the returned data (labels, grouping, counts), which is the remaining gap for a reporting 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 tool takes zero parameters, so there is nothing for the description to document and the baseline of 4 applies. The schema being empty and closed ('additionalProperties: false') is consistent with the no-argument nature of the call.

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 concrete action and resource: return the master profile's supported/unsupported skills, breaking them into printable skills by label and items recorded as LEARNING or UNSUPPORTED. That is specific enough to distinguish it from siblings like tailor_resume or validate_resume, though it never explicitly contrasts itself with them.

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

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

There is no statement of when to call this versus alternatives such as tailor_resume or validate_resume, nor any prerequisite or exclusion. The intended use (audit what the profile can back up) is only implied by the word 'support'.

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 and no output schema, the description carries the full disclosure burden. It does reveal the return content (all applications plus a status breakdown), which is genuinely useful, but it says nothing about authentication, pagination, ordering, or whether the set can be filtered or is unbounded.

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 short sentence that front-loads the verb and resource with zero filler. Nothing could be removed without losing meaning.

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 tool this is close to sufficient, and the return content is sketched. However, no output schema exists, so the description should be doing more work on what the returned counts/records look like and when this view is preferable to the other pipeline tools.

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 zero parameters, so there is nothing to document and no ambiguity for the agent to resolve. Baseline 4 applies since no parameter detail is required.

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 concrete action and resource: returning all tracked applications plus a per-status count. It is clear enough to distinguish from write-oriented siblings like track_application and update_application_status, though it never names a sibling or scope boundary explicitly.

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

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

There is no when-to-use statement, no mention of alternatives such as profile_summary, and no trigger conditions (e.g., 'use to review your job search pipeline'). The agent must infer that this is the read/list counterpart to the other application 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, the description carries the full burden and does well: it discloses the strong non-fabrication invariant ('never adds a skill, employer, metric or certification'), the validation gate, and the failure mode (is_final=false plus listed blocking issues). It omits permissions, whether the result is persisted, and the cost/behavior of the version parameter.

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 tight sentences, front-loaded with the core action and immediately followed by the key constraint and failure behavior. 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 generation semantics, invariant, and failure return are covered, which offsets the absence of an output schema. However, the nested 'job' object's expected fields and the meaning of 'version' are undocumented, leaving a real gap for an agent that must construct the call.

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

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

Schema description coverage is 0% and two parameters exist, one of them a nested object ('job') with no documented shape. The description explains the purpose of neither 'job' nor 'version' (e.g., what the version increments or selects), so it fails to compensate for the 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?

States a specific verb and resource ('Generate a role-specific resume') and precisely defines the mechanism: reordering and selecting from the master profile plus a factual-validation gate. It is distinguishable from show_pipeline/track_application, but it never names the sibling validate_resume even though it performs validation, leaving a small ambiguity an agent must resolve itself.

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?

Usage is implied: this is the tool for producing a tailored resume for a given job. There is no explicit when-to-use vs. when-not, and no guidance on choosing between this and validate_resume or analyse_job even though their scopes overlap.

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 and does disclose real behavior: dedup key (company + normalised role + canonical URL), idempotency, and the promise never to overwrite history. It omits write/auth implications and what happens to the score/decision values when an existing entry is returned instead of created.

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 tight sentences, with the core upsert behavior and dedup rule front-loaded. No filler, though the dedup clause is dense and slightly jargon-heavy ('normalised role', 'canonical URL') without definition.

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 mutation tool with no annotations, no output schema, and a fully undocumented nested 'job' object at 0% coverage, the description covers the key idempotency/integrity behavior but leaves the return shape, auth needs, and score/decision semantics unaddressed.

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

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

Schema coverage is 0%, so the description must compensate; it helpfully names the fields used for deduplication (company, role, canonical URL), which are inside the otherwise opaque nested 'job' object. It says nothing about the 'score' or 'decision' parameters, leaving their semantics entirely to 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 states a specific verb+resource (add a job to the application tracker / return the existing entry) and clarifies the scope through its idempotent upsert semantics. It does not explicitly name a sibling like update_application_status or show_pipeline, so differentiation is inferred rather than stated.

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?

Usage is implied: the idempotent 'or return the existing entry' behavior tells the agent it need not pre-check for duplicates. However, there is no explicit when-to-use vs when-to-use-an-alternative guidance, and no mention of update_application_status for changing status on an existing row.

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 a genuinely non-obvious trait — history is appended, never rewritten — which tells the agent this is a non-destructive, history-preserving mutation. However it says nothing about whether transitions are validated (can DISCOVERED jump to OFFER?), required permissions, 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?

Two tight sentences with zero filler; the core action is front-loaded and the behavioral caveat follows immediately.

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 3-parameter mutation tool with no annotations and no output schema, the description covers the key history semantics but omits transition validity, permissions, and the meaning of the note parameter. Adequate, but there are clear gaps an agent would want filled.

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

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

Schema description coverage is 0%, so the description must compensate and it largely does not. The 'status' enum is self-documenting in the schema, but neither the required application_id nor the optional 'note' field is explained anywhere, leaving the agent guessing at what note does.

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 and resource ('Move an application to a new status') plus the scoping behavior. It is clear on its own, but it never names or contrasts with siblings like track_application or show_pipeline, so sibling differentiation is left to inference.

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

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

There is no statement of when to reach for this tool versus track_application or show_pipeline, and no prerequisites or preconditions (e.g., whether the application must already exist). Usage is only implied by the tool 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 provided, so the description carries the full burden. It usefully discloses that this is a standalone validation/gate operation (implying non-destructive, independently invoked), but says nothing about failure behavior, whether it blocks anything, or what a validated/failed result looks like.

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, front-loaded with the core action followed by the routing condition. 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?

With no annotations, no output schema, and an opaque nested 'resume' object, an agent still lacks what the validation checks, what the resume object must contain, and what success/failure returns. It does not compensate for the missing structured data.

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?

One parameter with 0% schema description coverage and a nested object whose structure is entirely undocumented. The description only says the input is a 'resume object', adding no field-level meaning beyond the schema's bare type declaration.

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?

Specific verb+resource: it runs a 'factual-validation gate' over a 'resume object', which is a clearly identifiable operation distinct from tailor_resume (generation) and analyse_job. It does not explicitly name any sibling as the alternative, but the purpose is 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?

It gives an explicit when-to-use condition: invoke it for resumes 'edited by hand or generated elsewhere', and the word 'independently' signals it is not part of the normal pipeline. No when-not or named alternative, but the context is clear enough to route correctly.

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