CareerProof MCP

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

Annotations already establish the safety profile (non-readOnly, non-destructive). The description adds valuable behavioral context that the operation is 'Free' (cost). However, it omits whether adding an artifact triggers immediate model retraining, queuing behavior, or persistence details.

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?

Efficiently structured with the core action front-loaded. Each sentence delivers distinct value (purpose, use cases, parameter enum values, cross-references, cost). The enum lists are slightly redundant with schema coverage but aid quick scanning.

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 100% schema coverage, present annotations, and lack of output schema, the description is appropriately complete. It covers the operation purpose, parameter semantics, data sources, and cost. Absence of return value documentation is acceptable given no output schema is defined.

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

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

With 100% schema coverage, the baseline is 3. The description adds significant value by explaining semantic context for text_content ('rubric notes, evaluation criteria text') and explicitly stating that model_id should be sourced from specific sibling tools, aiding the agent in chaining calls correctly.

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 specific action ('Add'), resource ('plain text artifact'), and purpose ('teach a custom eval model'). It effectively distinguishes from sibling tool atlas_upload_custom_eval_artifact by emphasizing 'plain text' and 'free-form descriptions' versus file uploads.

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 clear positive usage guidance ('Use for free-form descriptions...rubric notes') and explicitly references sibling tools atlas_create_custom_eval_model and atlas_list_custom_eval_models for sourcing the model_id parameter. Lacks explicit negative guidance (when not to use vs alternatives).

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

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

Annotations indicate write/ non-idempotent operation (readOnlyHint: false, idempotentHint: false). The description adds critical behavioral context not in annotations: cost ('2 credits'), return format ('AI response text and a conversation_id'), and the 'no tool use' constraint. It also explains session state management (omitting vs including conversation_id).

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

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

Four sentences total with no waste. Front-loaded with purpose and cost, followed by sibling comparison, return value disclosure, and session management instructions. Every clause conveys distinct information necessary for invocation.

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

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

Despite no output schema, the description discloses return values (text and ID). It adequately covers the complexity of a stateful, credit-based chat tool by explaining cost, conversation threading mechanics, and output format—sufficient for correct agent usage without external documentation.

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

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

Input schema has 100% description coverage. The description reiterates the conversation_id usage pattern ('Omit... to start new; include... to continue'), but this largely mirrors the schema description 'Existing conversation ID to continue a thread (omit to start new)'. With full schema coverage, this meets the baseline without significant additional semantic depth.

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 ('Send') and resource ('Atlas Advisor') with clear scope ('lightweight hiring advice'). It explicitly distinguishes itself from sibling 'atlas_chat' by noting it is 'Faster and cheaper' and has 'no tool use', making the differentiation immediate and actionable.

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

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

Provides explicit comparison to sibling tool 'atlas_chat' (faster/cheaper), defines the specific use case ('best for general hiring questions'), and notes the constraint 'no tool use'. This gives the agent clear criteria for selection vs. the more extensive 'atlas_chat' alternative.

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 indicate non-read-only and non-idempotent behavior; the description adds critical operational context not in annotations: cost model (3 credits), latency expectations (2-3 minutes for complex queries), return value structure (AI response text + conversation_id), and capability scope (live tool use). No contradictions with annotations.

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

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

Four sentences with zero waste: opening establishes purpose/cost/capabilities, second sentence covers return values (crucial given no output schema), third explains conversation threading, fourth covers context linking and latency. Information is front-loaded and densely packed.

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?

Compensates effectively for missing output schema by documenting return values (text + conversation_id). Covers essential operational constraints: credit cost, time complexity, and integration points with sibling tools (atlas_list_contexts). Would benefit from explicit differentiation from atlas_advisor_chat, but remains highly complete for invocation purposes.

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

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

Input schema has 100% description coverage, establishing a baseline of 3. The description largely restates schema semantics for context_id and conversation_id, though it usefully emphasizes the 'omit to start new' pattern for conversation_id. It does not significantly enhance understanding of the 'message' parameter beyond the schema's 'User message' definition.

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

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

Clearly states the action (send message to Atlas AI assistant), specifies cost (3 credits), and enumerates specific capabilities (workforce intelligence, salary benchmarks, competitor intel). However, it does not explicitly differentiate from sibling tool 'atlas_advisor_chat', leaving potential ambiguity about which conversational AI to use.

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

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

Provides explicit guidance on conversation lifecycle (omit conversation_id to start new, include to continue) and references sibling tool 'atlas_list_contexts' for obtaining valid context_id values. Lacks explicit comparison to alternative chat tools (e.g., atlas_advisor_chat) but effectively explains the threading and context-aware usage patterns.

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 confirm destructive/idempotent nature; the description adds valuable behavioral context not in annotations: the revert target state ('AI-inferred rubric') and operational cost ('Free'). No contradictions with annotations.

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 zero waste: first states action and outcome, second specifies parameter provenance, third states cost. Efficiently front-loaded with the critical destructive action.

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

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

For a single-parameter destructive operation with no output schema, the description adequately covers the action, prerequisite data sources, and side effects (reversion to AI rubric). The annotations handle safety hints, so the description doesn't need to repeat them.

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

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

With 100% schema description coverage, the baseline is 3. The description repeats the schema's explanation of model_id source (from create/list tools) without adding additional semantic context like format constraints or validation rules.

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 specific verb 'Clear' with specific resource 'rubric overrides for a custom eval model' and clarifies the end state ('reverting to the AI-inferred rubric'). This clearly distinguishes it from siblings like atlas_set_custom_eval_rubric_overrides and atlas_get_custom_eval_rubric.

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 clear context by specifying the model_id source tools (atlas_create_custom_eval_model or atlas_list_custom_eval_models) and notes cost ('Free'). Lacks explicit when-not-to-use guidance comparing it to set_overrides, but the revert behavior implies the 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?

Adds valuable context beyond annotations: specifies the return structure ('Returns a context object with id'), declares cost ('Free'), and confirms workflow position. Annotations already establish the safety profile (destructive: false, readOnly: false), so the description appropriately focuses on return value and cost rather than repeating safety warnings.

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

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

Four sentences with zero waste. Front-loaded with the core action, followed by return value, integration instructions, and metadata (cost/workflow position). Each sentence delivers distinct, high-value information necessary for tool selection.

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?

Adequate for workflow integration but gaps remain in input documentation. While it correctly identifies the return value (id) and mentions output schema exists, the description lacks guidance on the required company_name parameter, the is_default flag behavior, or the complex hiring_context object structure with its nested budget ranges.

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

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

With only 14% schema description coverage, the description partially compensates by introducing the 'company profile' concept (mapping to company_name) and 'hiring context' object purpose. However, it fails to explain critical parameters like is_default, company_size enum values, or the nested budget_ranges structure, leaving significant semantic gaps for the 6 undocumented parameters.

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 explicitly states the specific action ('Create a new hiring context'), the resource type ('company profile'), and the purpose ('for organizing candidates and JDs'). It effectively positions this as the entry point to the Atlas ecosystem, clearly distinguishing it from sibling tools like atlas_upload_candidate or atlas_create_jd.

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?

Excellent guidance provided: explicitly states 'This is the first step in the Atlas workflow' (when to use), and details exactly how the output integrates with siblings ('Use this id as context_id in atlas_upload_candidate, atlas_create_jd...'). This creates a clear dependency map for the agent.

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

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

Annotations cover safety profile (readOnly=false, destructive=false). The description adds valuable behavioral context: specifies the return value format ('model object with id'), discloses cost ('Free'), and explains workflow integration. Does not contradict annotations.

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?

Five sentences total, all essential: purpose, return value, downstream usage, prerequisites, and cost. Well-structured with purpose front-loaded and workflow dependencies logically sequenced. No wasted words.

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

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

Despite no output schema, the description compensates by specifying the key return value ('id'). It covers prerequisites, downstream integration, and cost. Minor gap: could mention uniqueness constraints or error behavior given idempotentHint=false, but adequate for invocation.

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

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

Schema has 100% description coverage, establishing baseline 3. The description reinforces the source of client_context_id but does not add significant semantic meaning beyond the schema for the parameters themselves (name, description).

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

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

The description states the specific action ('Create'), resource ('custom evaluation model'), and domain ('hiring context'). It clearly distinguishes from sibling tools by explicitly listing five downstream tools where the returned ID is consumed, establishing its role as the workflow entry point.

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?

Excellent guidance provided: explicitly names prerequisite tools ('Requires client_context_id from atlas_create_context or atlas_list_contexts'), lists five specific downstream tools for the returned model_id, and notes cost ('Free'). This clearly establishes when to use the tool versus its siblings.

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 indicate non-idempotent write operations (readOnlyHint=false, idempotentHint=false). The description adds valuable behavioral context not in annotations: it discloses that the tool is 'Free' (cost behavior) and summarizes the return value structure ('Returns a JD object with 'id' and stored content') despite the existence of an output schema. It does not disclose side effects of multiple invocations.

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?

Five sentences with zero redundancy. Front-loaded with purpose ('Create a job description...'), followed by return values, downstream usage, prerequisites, and cost. Every sentence provides distinct, actionable information.

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

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

Given the presence of an output schema and annotations, the description provides complete contextual coverage: it explains the return object, prerequisites, cost model, and integration with sibling tools. No critical gaps remain for an agent to invoke this tool 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 67% (title lacks description). The description compensates effectively for context_id by specifying exact sibling tools to obtain it (atlas_create_context or atlas_list_contexts), adding crucial semantic meaning. However, it fails to clarify the 'title' parameter, which is undocumented in both schema and description, though 'content' is adequately covered by the schema's 'Full JD text'.

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 specific action ('Create a job description') and resource within a specific domain ('hiring context'). It effectively distinguishes itself from sibling tools by explicitly listing downstream consumers of its output (atlas_fit_match, atlas_fit_rank, etc.), clarifying its role in the workflow.

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

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

Provides explicit prerequisites ('Requires context_id from atlas_create_context or atlas_list_contexts') and clear guidance on how to use the output ('Use JD content as jd_text in...'). It names specific sibling tools for both input sourcing and output consumption, creating a clear decision tree for the agent.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. Description adds valuable behavioral context beyond annotations: explicitly states cascade effects ('removes... all associated artifacts and rubrics') and cost structure ('Free').

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

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

Four sentences with zero waste: action definition, destruction scope, parameter source, and cost. Front-loaded with the core verb and efficiently structured.

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?

Complete for a single-parameter destructive operation. Covers action, cascade impact, parameter sourcing, and cost. No output schema exists, so return value explanation is not expected.

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

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

Schema coverage is 100%, but description adds crucial provenance context for model_id ('from atlas_create_custom_eval_model or atlas_list_custom_eval_models'), guiding the agent on how to obtain valid values beyond just the numeric type.

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

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

Specific verb 'Delete' + resource 'custom evaluation model' clearly defines scope. Distinguishes from siblings like atlas_update_custom_eval_model and atlas_create_custom_eval_model by explicitly referencing the latter as sources for the required parameter.

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 clear prerequisites by specifying that model_id comes from atlas_create_custom_eval_model or atlas_list_custom_eval_models. Lacks explicit 'when not to use' guidance (e.g., vs. updating), but the cascade warning implies permanent removal.

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 already declare readOnly/idempotent/destructive hints. Description adds crucial behavioral details: 'Returns base64-encoded PDF content' (output format), 'Free' (cost), and completion requirement. No contradiction with annotations.

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?

Five efficient sentences front-loaded with action, then return format, prerequisites, and parameter source. Zero waste—every sentence provides unique value not duplicated in structured fields.

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

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

For a single-parameter download tool with good annotations, description adequately covers return format (base64 PDF), cost, prerequisites, and parameter sourcing without needing output schema documentation.

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

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

Schema has 100% coverage (baseline 3), but description adds meaningful provenance context: 'report_id from atlas_start_report response or atlas_list_reports', helping the agent understand parameter sourcing beyond the schema definition.

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 specific action 'Download' with resource 'completed report as PDF', clearly distinguishing from sibling 'atlas_get_report' (which checks status) and 'ceevee_download_report' (different namespace).

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

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

Explicitly states prerequisite: 'Confirm report status=completed via atlas_get_report(report_id) first'. Also identifies parameter source from 'atlas_start_report response or atlas_list_reports', providing clear workflow 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?

Annotations indicate openWorldHint=true and idempotentHint=false; the description adds critical context that the external data is 'industry KB data' and that invocations cost 8 credits. It also discloses return structure (fit score 0-100, strengths, gaps, recommendations) which annotations cannot convey.

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?

Information-dense with zero wasted words. Front-loads the key differentiator (KB augmentation), followed by cost, behavioral traits (synchronous), and return values. Slightly dense structure but 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?

Excellent completeness given no output schema exists: it manually documents the return structure (fit score, strengths, gaps, recommendations, market context), explains the cost model, and differentiates from the sibling tool. No gaps remain for a 3-parameter 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?

With 100% schema description coverage, the baseline is 3. The description adds minimal semantic value beyond the schema, primarily noting that parameters come from 'same sources as atlas_start_fit_match'—useful for cross-tool navigation but not deep parameter semantics.

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

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

The description opens with a specific verb+resource ('Enhanced FIT match with knowledge base augmentation') and immediately distinguishes itself from sibling tool atlas_start_fit_match by contrasting 'augments with industry KB data for richer insights' against the basic version.

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

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

Provides explicit cost signal '(8 credits)' and synchronicity status to guide invocation decisions. References sibling tool atlas_start_fit_match to establish relationship, though it could more explicitly state when to prefer this over the basic version (e.g., 'Use when market context is required').

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

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

Annotations indicate mutation (readOnlyHint: false) and non-idempotency, but description adds critical behavioral context: 8-credit cost model, synchronous execution, and return format (array with rationale). Does not contradict annotations. Could mention error handling or rate limits for a 5.

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?

Seven information-dense sentences with zero waste. Front-loaded with core purpose and cost, followed by return value, features, prerequisites, and workflow guidance. Every sentence earns its place.

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

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

Given no output schema exists, description adequately covers the return value structure ('array of interview questions with rationale'). Prerequisites, cost, synchronous nature, and sibling relationships are fully documented for this 5-parameter workflow 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?

With 60% schema coverage, description compensates well by explaining pressure_level semantics (supportive/standard/aggressive), jd_text purpose (role-targeted questions), and prerequisite sources for context_id/candidate_id. Only gap is num_questions, which has schema constraints but no descriptive text.

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 specific verb (Generate) + resource (interview questions) + scope (tailored to candidate's profile). Explicitly distinguishes from sibling tool 'atlas_interview_followup' by stating this is for initial generation while the sibling is for follow-up probing.

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

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

Explicitly names the alternative tool for subsequent steps ('use atlas_interview_followup for follow-up probing'). Clear prerequisites stated: requires context_id from atlas_list_contexts and candidate_id from atlas_list_candidates. Also clarifies optional jd_text sourcing.

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?

Strong: Annotations declare read-only/idempotent/safe properties. Description adds critical behavioral context not in annotations: state requirement (must be completed), cost ('Free'), and return structure ('scores, competency breakdown, and recommendations'). Does not contradict annotations.

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?

Perfect efficiency: Four sentences covering (1) core action, (2) return payload, (3) parameter source, (4) prerequisites/cost. Zero waste, front-loaded with the essential verb, every clause adds distinct value.

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

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

Complete for tool complexity: Single-parameter read-only tool with no output schema. Description compensates for missing output schema by detailing return contents (scores, breakdowns, recommendations) and covers workflow prerequisites comprehensively.

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?

Exceeds baseline: With 100% schema coverage, baseline is 3. Description adds valuable provenance context specifying analysis_id originates from 'atlas_start_gem_analysis response or atlas_list_analyses', helping the agent understand the data flow beyond the schema's type definition.

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?

Excellent: Specific verb 'Retrieve' + resource 'completed analysis result' + key 'by analysis ID'. Clearly distinguishes from sibling 'atlas_start_gem_analysis' (which creates) and 'careerproof_task_status' (which checks completion) by stating it fetches results and requires completion first.

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?

Outstanding: Explicitly states prerequisite 'check with careerproof_task_status first' and condition 'Only works after analysis is completed'. Identifies exact sibling tools that produce the required ID (atlas_start_gem_analysis, atlas_list_analyses). Includes cost signal 'Free'.

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?

Confirms readOnlyHint with 'Read-only summary'. Adds valuable context beyond annotations: cost ('Free'), dependency requirements (context_id source), and chaining behavior ('no downstream chaining'). Does not disclose rate limits or cache behavior, but annotations cover safety profile.

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

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

Four distinct information units across three sentences: purpose/data contents, prerequisites, behavioral traits, cost. Front-loaded with primary action. Zero redundancy—every clause adds unique value not present in structured fields. Optimal density for an output-schema-backed tool.

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 100% schema coverage, comprehensive annotations (readOnly, idempotent, destructive, openWorld), and existence of output schema, the description provides sufficient context without needing to document return values. Prerequisites and cost disclosure complete the picture for agent decision-making.

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

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

Schema coverage is 100% and already documents context_id source. Description reinforces with 'Requires context_id from atlas_create_context or atlas_list_contexts' but adds no new semantic meaning (format constraints, validation rules) beyond what the schema provides. Baseline 3 appropriate given schema completeness.

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 'Get' + resource 'talent analytics dashboard data' + scope 'hiring context'. Parenthetical details (candidate stats, analysis coverage, fit score distributions) clearly distinguish this from sibling tools like atlas_get_analysis or atlas_get_candidate which retrieve individual records rather than dashboard aggregations.

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

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

Explicitly states prerequisite: 'Requires context_id from atlas_create_context or atlas_list_contexts'. Indicates usage pattern with 'no downstream chaining needed' (terminal operation). Missing explicit 'when not to use' or named alternatives for detailed candidate retrieval.

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 already confirm read-only/idempotent/safe behavior, so description appropriately focuses on adding output semantics ('scores and competency breakdowns') and workflow constraints. Notes 'Free' (cost behavior) not covered in annotations. Could improve by describing error behavior if called before completion, but covers happy-path prerequisites well.

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?

Five short sentences, each earning its place: purpose, return format, prerequisite check, input source, and cost. Front-loaded with the core action. No redundant phrases or boilerplate. Exceptionally efficient.

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

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

Strong coverage for a batch workflow tool: explains return structure (compensating for missing output schema), defines prerequisite state (completed), and identifies parameter source. Sibling differentiation is clear. Minor gap: doesn't describe failure modes (e.g., what happens if status isn't completed).

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 'Batch job ID from atlas_start_batch_gem response'. Description echoes this ('job_id from atlas_start_batch_gem response') without adding new validation rules, format details, or semantic constraints beyond the schema. Baseline 3 appropriate when schema carries full load.

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

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

Clear specific verb ('Get') and resource ('results from a completed batch GEM job'). Explicitly distinguishes from sibling status-checking tool (atlas_get_batch_gem_status) and starting tool (atlas_start_batch_gem) by specifying this retrieves final results. Mentions return structure ('array of per-candidate analysis results') adding specific domain context.

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

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

Provides explicit prerequisite workflow: 'Check atlas_get_batch_gem_status(job_id) first to confirm status=completed'. Names the exact sibling tool to use beforehand. Also clarifies input provenance ('job_id from atlas_start_batch_gem response'), establishing the full tool chain sequence.

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?

While annotations declare readOnly/idempotent hints, the description adds crucial behavioral context: specific status enum values (pending/running/completed/failed), progress percentage return value, and cost characteristics ('Free'). No contradictions with annotations.

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

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

Four sentences with zero waste: (1) purpose, (2) return values, (3) conditional next step, (4) parameter source + cost. Front-loaded with action verb and perfectly sized for the tool's complexity.

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

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

Despite lacking output schema, description fully documents return values (status states + progress percentage) and workflow integration. For a single-parameter polling tool with strong annotations, this is 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 job_id fully documented. Description reinforces the parameter's source (atlas_start_batch_gem response) but doesn't add syntax or format details beyond the schema. Baseline 3 appropriate since schema carries the load.

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 uses specific verb 'Check progress' with resource 'batch GEM job' and clearly distinguishes from sibling tools like atlas_get_batch_gem_results (for final results) and atlas_start_batch_gem (for initiation).

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

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

Explicitly states workflow: use this to poll status, then 'When status=completed, fetch results with atlas_get_batch_gem_results(job_id)'. Also clarifies job_id provenance ('comes from atlas_start_batch_gem response'), establishing clear before/after relationships.

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 already establish read-only, idempotent, non-destructive traits. Description adds valuable cost information ('Free') and workflow context about checking parse status before proceeding to analysis steps.

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

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

Three well-structured sentences: purpose, usage guideline, and prerequisites/cost. Every sentence conveys unique information with zero redundancy.

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

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

Given the presence of an output schema and comprehensive annotations, the description provides complete context including workflow prerequisites, cost, and return content without needing to detail the output structure.

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

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

With 100% schema description coverage, the baseline is 3. Description mentions 'Free' (not in schema) but the provenance information for context_id is slightly misleading (implies it comes from atlas_upload_candidate/list_candidates like candidate_id, rather than atlas_create_context/list_contexts as per 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 specific action ('Get full candidate detail'), identifies the resource (candidate), and specifies what is returned (parsed CV content and parse status). Distinguishes from siblings like atlas_upload_candidate by focusing on retrieval rather than creation.

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

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

Explicitly states when to use ('verify CV parsing is complete... before starting analysis') and identifies prerequisite steps requiring IDs from specific sibling tools (atlas_upload_candidate or atlas_list_candidates).

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 cover safety profile (readOnly, idempotent, non-destructive). Description adds valuable context: cost ('Free'), return data structure ('per-candidate evaluation scores and dimension breakdowns'), and state prerequisite (must be 'completed'). Does not cover error cases or rate limits.

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

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

Five information-dense sentences with zero waste. Front-loaded with purpose, followed by return value, prerequisites, parameter source, and cost. 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 single-parameter retrieval tool with no output schema, the description adequately covers prerequisites, return value structure, parameter provenance, and cost. Combined with comprehensive annotations and schema, no gaps remain.

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

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

Schema has 100% description coverage ('Batch ID from atlas_start_custom_eval_batch response'). The description reinforces this source but does not add additional semantic meaning, syntax details, or examples beyond the schema. Baseline 3 is appropriate for high-coverage schemas.

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 specific action ('Get all results') and resource ('completed custom eval batch'), and distinguishes itself from the sibling tool atlas_get_custom_eval_batch_status by clarifying this returns actual results (scores and breakdowns) versus status information.

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

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

Provides explicit prerequisite ('Confirm status=completed via atlas_get_custom_eval_batch_status first') and parameter sourcing ('batch_id from atlas_start_custom_eval_batch response'), directly naming the sibling tools required for proper workflow sequencing.

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?

While annotations cover safety (readOnly/idempotent), the description adds valuable behavioral context: it discloses cost ('Free'), return payload ('status and progress'), and the specific state transition condition ('completed') that triggers the next tool in the sequence.

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

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

Four efficient sentences with zero waste: purpose ('Check progress...'), return value ('Returns status...'), conditional workflow ('When status...'), input provenance ('batch_id from...'), and cost ('Free'). Information is front-loaded and actionable.

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?

Adequate for a single-parameter status tool. It compensates for the missing output schema by describing the return value ('status and progress'). Could be improved by enumerating possible status values (e.g., pending, running, failed), but the sibling tool integration guidance provides sufficient context for successful invocation.

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

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

With 100% schema coverage, the baseline is 3. The description mirrors the schema's guidance about batch_id originating from atlas_start_custom_eval_batch but does not add additional semantic details like format constraints or validation rules beyond the schema.

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

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

The description opens with a specific verb ('Check') and resource ('custom evaluation batch'), clearly distinguishing it from sibling tools like atlas_start_custom_eval_batch (which creates) and atlas_get_custom_eval_batch_results (which fetches final 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?

Explicitly defines the workflow: use this tool to check status, and when status='completed', use atlas_get_custom_eval_batch_results. Also specifies the batch_id source (from atlas_start_custom_eval_batch response), preventing confusion about parameter origins.

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 already declare the operation as read-only, idempotent, and non-destructive. The description adds valuable behavioral context not present in annotations: the cost ('Free') and the specific structure of returned data ('dimensions, weights, artifacts summary, and rubric status'), which compensates for the missing output schema.

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

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

The description consists of two highly efficient sentences. The first front-loads the action and resource with specific detail fields; the second provides sourcing and cost constraints. No words are wasted, and every clause delivers actionable information.

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

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

For a simple read-only retrieval tool with one parameter and strong annotations, the description is complete. It compensates for the missing output schema by detailing the return structure in the text, and the 100% schema coverage means no additional parameter documentation is needed.

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

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

With 100% schema description coverage, the baseline is 3. The description repeats the parameter sourcing information already present in the schema ('model_id from atlas_create_custom_eval_model or atlas_list_custom_eval_models') but does not add additional semantic meaning, constraints, or format details beyond what the schema provides.

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

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

The description uses a specific verb ('Get') with a clear resource ('custom evaluation model') and enumerates the specific data returned ('dimensions, weights, artifacts summary, and rubric status'). This distinguishes it from sibling tools like atlas_list_custom_eval_models (which likely returns summaries) and atlas_create_custom_eval_model.

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

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

The description provides explicit guidance on sourcing the required parameter ('model_id from atlas_create_custom_eval_model or atlas_list_custom_eval_models') and includes cost information ('Free'). While it doesn't explicitly state 'when not to use' alternatives, the parameter sourcing instructions effectively indicate prerequisite workflows.

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 cover safety profile (readOnly/idempotent), so description appropriately focuses on return value semantics ('evaluation dimensions, scoring criteria, and any user overrides') and cost ('Free'). Adds meaningful behavioral context beyond structured metadata.

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

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

Four sentences with zero waste: purpose, return payload, parameter sourcing, and cost. Front-loaded with action and resource, efficiently structured for quick comprehension.

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?

Adequately complete for a single-parameter getter tool. Despite no output schema, description conceptually covers return contents. Combined with comprehensive annotations and full schema coverage, no critical gaps exist.

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

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

With 100% schema description coverage, the baseline is 3. The description reinforces the schema's sourcing guidance for model_id but does not add additional syntax, format details, or semantic nuances beyond what the schema already provides.

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

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

The description uses specific verb 'Get' with clear resource 'rubric for a custom eval model' and distinguishes from siblings by specifying it retrieves 'current' rubric including 'user overrides'—contrasting with atlas_infer_custom_eval_rubric (generation) and atlas_set/clear_custom_eval_rubric_overrides (mutation).

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

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

Provides explicit sourcing guidance for the model_id parameter ('from atlas_create_custom_eval_model or atlas_list_custom_eval_models'), implying the workflow context. However, lacks explicit when-not-to-use guidance comparing retrieval vs. inference scenarios.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive). The description adds useful context about the return payload structure (interview quality scores, communication assessment, recommendations) and workflow prerequisites, but does not disclose error states, rate limits, or polling behavior.

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

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

The description is appropriately front-loaded with purpose and prerequisites, but the final sentence 'Free.' is ambiguous (unclear if referring to cost, freedom, or text type) and wastes space without adding clear value, slightly undermining the otherwise efficient structure.

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

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

For a single-parameter read operation with strong annotations, the description adequately compensates for the missing output schema by detailing what the results contain and provides the critical workflow prerequisite (checking careerproof_task_status) necessary for correct invocation.

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

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

With 100% schema description coverage, the session_id parameter is already well-documented. The description reinforces the parameter's origin by referencing atlas_start_dialogue_assessment but does not add significant semantic meaning beyond what the schema provides, warranting the baseline score.

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 ('Get') and resource ('assessment results for a dialogue session'), and distinguishes from siblings like atlas_get_analysis or atlas_get_candidate by specifying the dialogue/interview context and return contents (interview quality scores, communication assessment, and recommendations).

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 explicit workflow guidance with 'Confirm assessment is completed via careerproof_task_status first,' indicating when to use the tool (only after completion). It also clarifies the tool chain by referencing atlas_start_dialogue_assessment as the source for session_id.

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 declare readOnly/idempotent/safe properties. The description adds valuable behavioral context not in structured data: it discloses the return payload ('Returns status and progress percentage') compensating for the missing output schema, and notes 'Free' suggesting no cost or consumption. Does not contradict annotations.

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

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

Four tightly constructed sentences with zero redundancy: purpose (sentence 1), return values (2), workflow transition (3), parameter source (4), plus cost note (5). Every element earns its place; information is front-loaded with the core action stated 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 simple status-checking tool with 2 parameters, read-only annotations, and no output schema, the description is complete. It explains what the tool returns (compensating for missing output schema), documents the parameter sources, and maps the full workflow from start to results via sibling 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?

With 100% schema description coverage, the schema already fully documents both parameters and their relationships to atlas_start_jd_fit_batch. The description repeats this relationship ('batch_id comes from...') but adds no new semantic depth or format constraints beyond the schema documentation. Baseline 3 appropriate for high-coverage schemas.

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 ('Check') and clear resource ('progress of a JD-FIT batch job'). It effectively distinguishes from sibling tools by explicitly naming atlas_get_jd_fit_results for fetching final results and atlas_start_jd_fit_batch as the origin of required IDs.

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

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

Provides explicit workflow guidance: states 'When complete, fetch results with atlas_get_jd_fit_results(context_id)' indicating when to stop using this tool and switch to the alternative. Also specifies the prerequisite ('batch_id comes from atlas_start_jd_fit_batch response'), clarifying the temporal dependency chain.

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?

While annotations confirm the read-only, idempotent, non-destructive nature of the call, the description adds crucial behavioral context: the return structure ('ranked candidates with fit scores, strengths, and gaps') and cost ('Free') which annotations do not cover.

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?

Five efficient sentences front-load the purpose, followed by return value description, workflow prerequisite, parameter source, and cost. Zero redundancy; every clause delivers unique actionable information.

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

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

For a single-parameter read operation, the description adequately compensates for the missing output schema by detailing the return structure and provides prerequisite guidance. A perfect score would require mention of error states (e.g., calling before batch completion).

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

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

With 100% schema description coverage for the context_id parameter, the baseline is 3. The description repeats the parameter source guidance found in the schema ('from atlas_create_context or atlas_list_contexts') without adding additional semantic details like format constraints or examples.

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 precise action ('Get JD-FIT results') and target resource ('for a context'), clearly distinguishing this retrieval tool from its siblings like atlas_start_jd_fit_batch or atlas_get_jd_fit_batch_status.

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

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

Explicitly states the prerequisite workflow ('Confirm batch is complete via atlas_get_jd_fit_batch_status first'), effectively defining when to use this tool versus when to check status instead, and implicitly when not to use it (before completion).

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 already declare readOnly/idempotent/destructive hints, so description focuses on adding domain-specific context: enumerates status values (pending/generating/completed/failed), lists return fields (title, type, summary), and notes cost ('Free'). Does not mention rate limits or error behaviors, preventing a 5.

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?

Five sentences, zero waste: purpose, return values, conditional next-step, parameter source, and cost. Front-loaded with the core verb and resource. Every sentence provides distinct value not redundant with structured fields.

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 single-parameter status tool with no output schema, the description comprehensively covers the state machine, return fields, workflow integration with three sibling tools, and cost. No gaps remain for an agent to invoke this 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%, providing baseline 3. The description mentions report_id sources but adds minimal semantic detail about the parameter itself (type, format) beyond the schema's existing documentation.

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 specific action 'Get report status and metadata' with clear scope. Explicitly distinguishes from sibling atlas_download_report by specifying this tool only retrieves status/metadata while the sibling handles PDF downloads.

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

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

Provides explicit workflow guidance: 'When status='completed', download the PDF with atlas_download_report(report_id)'. Also specifies valid sources for the report_id parameter (from atlas_start_report or atlas_list_reports), establishing clear prerequisites.

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?

Adds essential behavioral context beyond annotations: the synchronous/long-running nature (30-60s), cost ('Free'), and mechanism ('analyzes all uploaded artifacts'). Does not contradict annotations (readOnlyHint: false aligns with active 'infer/generate' verbs). Minor gap: does not address idempotentHint: false implications (subsequent calls may generate different rubrics).

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?

Five sentences, zero waste. Front-loaded with purpose ('Infer...'), followed by mechanism, performance characteristics, parameter provenance, and cost. Every sentence delivers unique, non-redundant value not found in structured fields.

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

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

Given no output schema exists, the description adequately describes the conceptual output ('evaluation dimensions with scoring criteria') and operational context. Could improve by sketching the return structure or noting the non-idempotent behavior, but sufficient for a single-parameter inference 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?

With 100% schema description coverage, the baseline is 3. The description repeats the schema's guidance on model_id sourcing but adds no additional semantic details, examples, or format constraints beyond what the structured schema already provides.

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

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

The description opens with a specific verb-resource pair ('Infer an evaluation rubric') and scope ('from the model's artifacts'). It clearly distinguishes from siblings like 'atlas_get_custom_eval_rubric' (retrieve existing) and 'atlas_set_custom_eval_rubric_overrides' (manual update) by emphasizing the AI-driven generation aspect ('AI analyzes... generates').

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 critical operational constraints ('synchronous AI call that may take 30-60 seconds') and prerequisites ('model_id from atlas_create_custom_eval_model'). However, it lacks explicit guidance on when to prefer this over manual rubric creation via sibling tools or what prerequisites (uploaded artifacts) are needed for successful 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?

Adds critical context beyond annotations: cost ('1 credit'), synchronous execution, and output structure ('Returns a follow-up question with probing rationale'). Annotations cover safety profile (not read-only, not destructive), so description appropriately supplements with operational details rather than repeating safety flags.

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

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

Four dense sentences: purpose/output, workflow instruction, and behavioral requirements. Each sentence earns its place with zero redundancy or filler. Front-loaded with the core action.

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

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

Given no output schema, description adequately explains return values ('follow-up question with probing rationale'). Covers credit cost and required parameters. Only gap is lack of explanation for pressure_level enum behavior, which would complete the picture.

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

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

With 80% schema coverage, baseline is 3. Description adds workflow context linking original_question and candidate_answer to atlas_generate_interview output, which is valuable. However, it fails to document the pressure_level parameter (undocumented in schema), leaving a gap in semantic 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?

States specific action (Generate a follow-up question), resource (interview question), and scope (based on candidate's answer). Clearly distinguishes from siblings by mentioning it returns a 'follow-up question with probing rationale' and is used 'after atlas_generate_interview'.

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

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

Explicitly states when to use ('Use after atlas_generate_interview'), what parameters to pass from that prior tool's output ('pass the original_question from that tool's output'), and notes execution model ('Synchronous').

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 confirm read-only, idempotent, non-destructive behavior. The description adds valuable context missing from annotations: the return payload structure ('array with each analysis's id, type, status, and scores') and cost ('Free'). Deducted one point for not mentioning pagination behavior or result limits.

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

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

Four sentences covering purpose, return format, sibling relationships, and prerequisites. Every sentence adds unique value; no repetition of schema or annotation content. Front-loaded with the primary action.

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

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

Given no output schema exists, the description adequately compensates by describing return fields. Prerequisites are clearly stated. For a 3-parameter list tool, this is nearly complete; would benefit from mentioning pagination or maximum result limits.

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

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

Schema coverage is 67% (two parameters fully described, analysis_type lacks description). The description mentions 'optional type filtering' which provides semantic context for the analysis_type parameter, but does not explain the enum values (gem_full, gem_lite, etc.). With medium schema coverage, this meets the baseline but doesn't fully compensate for the undocumented parameter.

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

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

The description opens with a specific verb ('List') and clear resource ('analyses for a candidate'), immediately establishing scope. It distinguishes from sibling atlas_get_analysis by explaining this returns summary data (id, type, status, scores) while the sibling retrieves 'full details'.

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

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

Explicitly states prerequisites ('Requires context_id and candidate_id from atlas_list_candidates') and provides clear alternative guidance ('Use the analysis id with atlas_get_analysis to retrieve full details'). The 'optional type filtering' phrase clarifies when to use the analysis_type parameter.

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 declare readOnly/idempotent/destructive hints. Description adds valuable behavioral context not in annotations: cost ('Free'), return structure ('array of candidate objects'), and downstream consumption pattern. No contradictions with annotations.

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?

Five sentences, each serving distinct purposes: action definition, return structure, workflow integration, prerequisites, and cost. Information is front-loaded with the primary verb and contains zero redundancy.

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

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

Given low complexity (1 parameter, 100% schema coverage) but absence of output schema, description fully compensates by detailing the return structure ('array...with id field') and workflow relationships. No gaps remain for agent invocation.

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

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

With 100% schema coverage (baseline 3), description adds semantic value by specifying the data lineage for context_id ('from atlas_create_context or atlas_list_contexts'), guiding the agent on how to source the parameter value.

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

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

Description uses specific verb 'List' with resource 'candidates' and scope 'in a hiring context'. It distinguishes from sibling 'atlas_get_candidate' by emphasizing 'all' and 'array' return type, while clarifying the specific hiring domain context.

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

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

Provides explicit prerequisite ('Requires context_id from...') and workflow integration ('Use candidate id as candidate_id in...'), establishing clear context for when to use the tool. Lacks explicit 'when-not-to-use' guidance or direct alternative comparison (e.g., vs. atlas_get_candidate), preventing a 5.

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 cover safety profile (readOnly, idempotent, non-destructive). The description adds valuable behavioral context not in annotations: return format ('array of context objects'), specific field details ('id'), and cost ('Free'). No contradictions with annotations.

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

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

Three sentences with zero waste: purpose, return structure, and usage guidance with cost. Information is front-loaded and each sentence earns its place. No redundant or filler text.

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

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

Given no output schema exists, the description adequately explains return values (array of objects with id fields) and the tool's integration point in the broader workflow. It could be improved by briefly explaining what constitutes a 'hiring context', but covers the essential integration pattern well.

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

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

With 0% schema description coverage for the 'include_inactive' boolean parameter, the description fails to compensate. It does not mention the parameter at all, leaving agents to infer its purpose solely from the parameter name, despite the low schema coverage requiring descriptive compensation.

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

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

The description clearly states the specific action ('List all hiring contexts') and scope ('for the authenticated user'), distinguishing it from sibling atlas_create_context. It effectively identifies this as a retrieval operation for hiring context 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?

Explicitly identifies when to use the tool by listing specific sibling tools (atlas_upload_candidate, atlas_create_jd, etc.) that require the returned context_id. This establishes clear workflow dependency: call this first, then use the id elsewhere.

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 already establish read-only/idempotent safety. Description adds valuable behavioral context: specifies the return object structure (id, type, label, notes, upload status) compensating for missing output schema, and notes 'Free' indicating no cost constraints.

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

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

Four sentences, zero waste. Front-loaded with core action, followed by return format, parameter source, and cost. Every clause delivers distinct value (purpose, shape, prerequisites, pricing).

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

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

For a single-parameter listing tool with no output schema, the description fully compensates by describing return values and upload status details. Prerequisites and cost are covered. Annotations handle safety profile. Nothing critical 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?

Schema coverage is 100%, so baseline is 3. Description repeats the schema's explanation of model_id origin without adding additional semantic details (e.g., format constraints, validation rules) beyond what's in the structured 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?

Specific verb ('List') + specific resource ('artifacts uploaded to a custom eval model') clearly distinguishes this from siblings like atlas_list_custom_eval_models (lists models, not artifacts) and atlas_upload_custom_eval_artifact (uploads, not lists).

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 clear prerequisite guidance by specifying that model_id comes from atlas_create_custom_eval_model or atlas_list_custom_eval_models. Lacks explicit 'when not to use' or alternative comparisons, but the prerequisite chain is well-defined.

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 already establish the read-only, idempotent, non-destructive nature. The description adds valuable behavioral context not in the structured data: the specific return structure ('array of model objects with id, name, description, and status') and cost ('Free'). It appropriately compensates for the missing output schema.

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

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

Four short sentences efficiently cover: (1) purpose, (2) return structure, (3) downstream usage, and (4) cost. Every sentence earns its place with no redundancy. Information is front-loaded with the core purpose.

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

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

Given the tool's simplicity (no parameters, read-only list operation) and absence of an output schema, the description is complete. It describes the return format, notes authentication requirements, explains how the results integrate with the broader tool ecosystem, and mentions cost—all essential for agent decision-making.

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

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

The input schema contains zero parameters. Per the rubric, 0 params establishes a baseline of 4. The description correctly does not invent parameters, and the 'for the authenticated user' phrasing clarifies the implicit scope limitation without requiring explicit parameters.

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 explicitly states the specific verb 'List', the resource 'custom evaluation models', and the scope 'for the authenticated user' and 'all'. It clearly distinguishes this from siblings like atlas_get_custom_eval_model (singular retrieval) and atlas_create_custom_eval_model (creation) through the 'List all' phrasing.

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 explicit post-retrieval usage guidance ('Use model id in artifact, rubric, and evaluation tools') and notes the cost ('Free'). While it doesn't explicitly contrast when to use this versus atlas_get_custom_eval_model, the zero-parameter nature and 'List all' phrasing make the use case clear.

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

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

While annotations cover safety profile (readOnlyHint, destructiveHint), the description adds valuable behavioral context: return structure ('array of JD objects with id, title, and content') and cost ('Free'). Does not contradict annotations.

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

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

Four sentences with zero waste: purpose, return format, workflow integration, and prerequisites/cost. Information is front-loaded and 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 simple list operation with no output schema, the description adequately explains return values (array structure and fields), mentions cost, and provides workflow context. Given the single parameter and strong annotations, this is 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%, so the schema already fully documents the context_id parameter including its source. The description reinforces this ('Requires context_id from...') but does not add new semantic information like format details or examples beyond the schema.

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

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

The description opens with a specific verb ('List') and resource ('job descriptions'), clearly distinguishing this from sibling tools like atlas_list_candidates or atlas_list_contexts by specifying the scope ('for a hiring context').

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

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

Explicitly identifies downstream dependencies by naming specific sibling tools ('atlas_fit_match', 'atlas_fit_rank', 'atlas_start_jd_fit_batch') where the output should be used, and clearly states the prerequisite ('Requires context_id from...').

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 already declare read-only, idempotent, non-destructive nature. Description adds valuable behavioral context not in structured data: return value structure ('array of report objects with id, report_type...') and cost characteristics ('Free'). Does not mention pagination or rate limits, but otherwise supplements annotations well.

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

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

Four sentences, each earning its place: purpose, return schema, sibling differentiation, and cost. Front-loaded with action verb. No redundant or wasteful text despite including return value documentation that compensates for missing output schema.

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 list tool, the description is complete. It documents the return structure (compensating for lack of output schema), references related tools, and states cost. No gaps remain given the tool's simplicity and rich annotations.

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 contains zero parameters. Per scoring rules, 0 parameters establishes a baseline of 4. Description correctly implies no filtering is possible ('List all'), which aligns with the empty schema.

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

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

States specific verb 'List' with resource 'generated reports' and scope 'all'. Explicitly distinguishes from siblings by contrasting with atlas_get_report ('for details') and atlas_download_report ('download completed PDFs'), clarifying this is the enumeration entry point.

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

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

Provides explicit workflow guidance: 'Use the report id with atlas_get_report for details or atlas_download_report to download completed PDFs.' This clearly indicates when to use this tool (listing/overview) versus alternatives (retrieval/download).

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?

While annotations cover read-only/idempotent/destructive hints, the description adds crucial behavioral context: cost structure (free), exact enumeration of return content (16 types with specific fields), and categorical breakdown (RECRUITMENT, WORKFORCE_PLANNING, STRATEGIC_HR with counts). Could mention pagination or caching, but covers key operational traits.

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

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

Three highly information-dense sentences with zero waste. First sentence enumerates output fields, second provides usage sequencing, third gives categorical taxonomy and cost. Front-loaded with the most critical information (what it returns).

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

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

Despite lacking an output schema, the description comprehensively details the response structure (16 types with descriptions, categories, costs, and required/optional fields). Combined with clear annotations and explicit sibling relationships, this provides complete context for agent invocation.

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 contains 0 parameters (empty object). With no parameters to document, the baseline score of 4 applies. The description appropriately focuses on return value semantics rather than inventing parameter documentation where none exists.

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') with exact resource scope ('all 16 available report types') and enumerates specific returned fields (descriptions, categories, credit costs, input fields). It clearly distinguishes this discovery tool from the sibling 'atlas_start_report' by positioning it as a prerequisite for discovering valid report_type values.

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

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

Provides explicit sequencing instruction ('Call this BEFORE atlas_start_report') with clear rationale ('to discover valid report_type values and the exact inputs each type requires'). Also notes cost behavior ('Free'), giving complete context for when to invoke versus alternatives.

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

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

Annotations declare idempotentHint=true and destructiveHint=false; the description adds valuable context by clarifying the replacement semantics ('Replaces any existing overrides') and disclosing cost ('Free'). No contradictions with annotations. Could mention validation errors or requirements.

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

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

Five sentences efficiently structured: action definition, capability explanation, behavioral warning, parameter sourcing, and cost. Every sentence earns its place with no redundancy or filler. Front-loaded with the core action.

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 setter tool with 2 parameters and no output schema, the description adequately covers the operation's purpose, side effects (replacement), prerequisites (model_id source), and cost. Lacks explicit error handling or validation details, but sufficient for invocation.

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%, establishing baseline 3. The description adds conceptual context for the overrides parameter (explaining it customizes 'AI-inferred rubric' with specific operations like adjusting weights/renaming dimensions) and reinforces model_id sourcing. Elevates slightly above baseline.

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 'Set rubric overrides for a custom eval model' with specific capabilities (adjust weights, rename dimensions, add scoring criteria). It distinguishes from siblings by emphasizing 'without re-inferring' (contrasting with atlas_infer_custom_eval_rubric) and 'replaces existing overrides' (contrasting with clearing or appending).

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 clear context on when to use (customizing without re-inferring) and warns about replacement behavior ('Replaces any existing overrides'). Mentions valid sources for model_id. Could be improved by explicitly stating when to use atlas_clear_custom_eval_rubric_overrides instead, but the contrast is implied.

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 declare mutation safety profile (readOnly=false, destructive=false, idempotent=false). Description adds critical behavioral context not in annotations: credit cost model, asynchronous polling pattern, prerequisite data state (CV parsing), and temporal dependency chain (poll until completed). No contradictions with annotations.

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?

Five sentences covering: (1) core action + cost, (2) return value, (3) polling workflow with specific tool names, (4) ID sourcing prerequisites, (5) data state prerequisites. Zero redundancy; front-loaded with essential action; each sentence advances the agent's understanding of how to invoke and manage the async workflow.

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 complex async operation with no output schema, description comprehensively covers the complete lifecycle: initiation → polling → results retrieval. Addresses hidden complexity including credit costs, data prerequisites, and tool dependencies. Sufficient for an agent to correctly orchestrate the full batch workflow without additional documentation.

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

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

Schema coverage is 67% (analysis_type lacks description). Description adds semantic value by specifying sourcing for the two required parameters (context_id from atlas_list_contexts, candidate_ids from atlas_list_candidates), which is crucial for correct invocation. Does not compensate for missing analysis_type description, but schema enums provide partial 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?

Description states specific verb (Start) + resource (batch GEM analysis) + scope (across multiple candidates). Explicitly distinguishes from single-candidate sibling atlas_start_gem_analysis by emphasizing 'batch' and 'multiple candidates', and distinguishes from other batch operations by specifying 'GEM analysis'.

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

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

Provides explicit workflow: returns job_id → poll with atlas_get_batch_gem_status → fetch results with atlas_get_batch_gem_results. Names specific prerequisite tools (atlas_list_contexts, atlas_list_candidates) and data state requirements (CVs must be fully parsed). Includes cost disclosure (10 credits per candidate) for economic decision-making.

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?

Adds critical cost information (5 credits per candidate) not in annotations. Clarifies the async/non-blocking nature requiring polling. Annotations indicate readOnlyHint=false and idempotentHint=false; the description aligns by implying resource creation (returns new batch_id) without claiming idempotency or read-only status.

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 well-structured sentences covering: 1) Purpose and cost, 2) Return value and polling workflow, 3) Prerequisites. No filler words; information density is high and front-loaded.

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?

Excellent coverage of the complex async workflow and billing implications for a batch operation. Minor gap: does not explain optional parameters (template_id, detail_level) or what constitutes brief vs standard vs deep evaluation levels, though the async workflow explanation compensates for lack of 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?

With 60% schema coverage, the baseline is 3. The description mentions the 3 required parameters but largely repeats schema descriptions (context_id from atlas_list_contexts, etc.) without adding usage context. It completely omits the 2 optional parameters (template_id, detail_level), failing to compensate for schema gaps.

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 specific action (Start batch evaluation), resource (multiple candidates using custom evaluation model), cost (5 credits per candidate), and distinguishes from siblings by specifying the custom model workflow vs other batch operations like atlas_start_batch_gem.

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

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

Explicitly describes the async lifecycle: returns batch_id, poll with atlas_get_custom_eval_batch_status, fetch results with atlas_get_custom_eval_batch_results. Also lists prerequisites requiring context_id, candidate_ids, and custom_model_id from specific sibling 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?

Annotations declare idempotent=false and readOnly=false. Description adds critical behavioral context: cost (5 credits), exact return value (task_id), polling requirement, and specific resultType parameter needed for fetching. Does not contradict annotations.

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

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

Three sentences dense with essential information. Front-loaded with purpose, followed by workflow, then constraint. Slightly dense but no waste given the complexity of the async lifecycle that must be communicated.

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

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

Despite no output schema, fully compensates by documenting the task_id return value and complete polling workflow (status check → result fetch). For a single-parameter async task starter, this is comprehensive.

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

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

Schema has 100% coverage (baseline 3). Description adds semantic value by specifying the model_id must be from an 'existing' custom eval model (constraint not explicit in schema) and links model_id to the resource_id parameter in the result fetching workflow.

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 specific action 'Start async inference', target resource 'custom evaluation model', and outcome 'auto-generate evaluation dimensions'. Also notes cost '5 credits'. Clearly distinguishes from sibling tools like atlas_start_custom_eval_batch by focusing on single-model 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?

Provides explicit async workflow guidance (poll with careerproof_task_status, fetch with careerproof_task_result) and prerequisites (model_id must be from existing model). However, lacks explicit comparison to sibling atlas_start_custom_eval_batch for when to use batch vs single 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?

Annotations indicate mutation (readOnlyHint=false) and non-idempotency (idempotentHint=false). The description adds critical behavioral details: async execution pattern (returns task_id requiring polling), credit consumption (10 credits), and the exact orchestration pattern with other tools. No contradictions with annotations.

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

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

Four sentences cover: purpose/cost, return value, polling workflow, and input validation. Information is front-loaded with the core action, followed by operational details. No redundant words or tautologies.

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

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

Despite no output schema, the description fully compensates by documenting the return value (task_id) and the complete async lifecycle. For an async initiation tool, it provides sufficient context about side effects (credit consumption), return format, and necessary follow-up actions.

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% (1 parameter fully documented). The description reinforces the validation constraint ('must be from an existing dialogue session') and contextualizes how the session_id is used in the downstream workflow (with atlas_get_dialogue_results), adding value beyond the schema definition.

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 explicitly states the tool 'Start[s] async assessment of dialogue/interview transcripts in a session' with specific verb (start assessment), resource (dialogue transcripts), and scope (in a session). It clearly distinguishes from sibling analysis tools by emphasizing the async nature and credit cost.

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

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

Provides explicit multi-step workflow: poll with careerproof_task_status until completed, then fetch results with atlas_get_dialogue_results. Names specific sibling tools for the complete process. Also notes the prerequisite ('session_id must be from an existing dialogue session') and cost constraint (10 credits).

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?

Adds critical behavioral context beyond annotations: discloses credit cost (8 credits), async nature requiring polling, and specific return values (task_id and analysis_id). Annotations only indicate it's a non-destructive write operation; the description explains the full lifecycle and cost model.

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?

Five tightly constructed sentences with zero redundancy. Front-loaded with purpose and cost, followed by return values, workflow, prerequisites, and alternatives. Every sentence conveys essential information for tool selection and invocation.

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?

Thoroughly covers the async operation pattern despite lacking an output schema. Explains what to expect (task_id/analysis_id), how to proceed (polling), credit cost, and prerequisite data requirements. Complete for an async task initiation 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?

With 100% schema description coverage, the baseline is 3. The description reinforces parameter requirements by listing them as prerequisites with their source functions, though it omits some source options present in the schema (e.g., omits atlas_create_context for context_id). No additional semantic depth provided beyond schema.

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

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

Explicitly states the action ('Start an async fit match'), target resource (single candidate against job description), and cost (8 credits). Clearly distinguishes from sibling batch tools by specifying 'single candidate' and explicitly naming alternatives for multiple candidates.

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

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

Provides explicit workflow guidance (poll with careerproof_task_status, then fetch with careerproof_task_result), prerequisite data sources (context_id from atlas_list_contexts, etc.), and clear alternative tools for different use cases (atlas_start_fit_rank for multiple candidates).

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 indicate mutation (readOnlyHint: false) and non-idempotency. Description adds critical cost information ('8 credits'), return value structure ('task_id and analysis_id'), and specific polling parameters ('result_type=fit_rank'), providing essential operational context beyond the structured hints.

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?

Efficiently structured with zero waste: cost and action front-loaded, followed by return values, polling workflow, prerequisites, and alternative tool. Every clause provides actionable information for an agent orchestrating the async workflow.

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?

Comprehensive despite no output schema. Description compensates by detailing return values (task_id, analysis_id) and complete next-step instructions for result retrieval. Credit cost and prerequisite data sources are explicitly documented, satisfying requirements for this async initiation 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?

With 100% schema coverage, baseline is 3. Description adds valuable sourcing context beyond raw schema, specifying that context_id comes from atlas_list_contexts, candidate_ids from atlas_list_candidates (reinforcing minimum 2), and jd_text can be from atlas_list_jds or raw text.

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 specific action ('Start an async rank'), target resource ('multiple candidates against a job description'), and scope. Explicitly distinguishes from sibling tool atlas_start_jd_fit_batch by clarifying this is for ranking while the alternative is for 'async batch processing with more detail'.

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

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

Provides explicit prerequisites ('Requires context_id from atlas_list_contexts...'), workflow instructions ('Poll with careerproof_task_status, then fetch result with careerproof_task_result'), and clear alternative recommendation ('use atlas_start_jd_fit_batch 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?

Adds critical behavioral context not in annotations: async nature requiring polling, credit costs (10 cr vs 5 cr), and CV parsing prerequisites. Annotations indicate non-idempotent write operation (readOnlyHint: false, idempotentHint: false), which aligns with 'Start' language. Does not disclose duration estimates or error states, preventing a 5.

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

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

Four dense, information-rich sentences with zero waste. Front-loaded with action and return values, followed by polling workflow, prerequisites, and cost structure. Every clause earns its place in the async workflow explanation.

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 an async job initiation tool without output schema, the description comprehensively covers the full lifecycle: initiation, polling mechanism, result retrieval (two alternative methods), prerequisites, and cost implications. Sufficient for correct agent orchestration.

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

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

Schema has 100% coverage establishing baseline 3. Description adds valuable credit cost metadata ('10 cr', '5 cr') for the analysis_type enum values, aiding agent cost-benefit decisions. Could reference context_id/candidate_id acquisition beyond schema descriptions for higher score.

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 explicitly states the tool 'Start[s] an async GEM (10-factor competency) analysis' with specific resource (GEM analysis) and scope (10-factor competency). It distinguishes itself from siblings like atlas_start_jd_analysis or atlas_start_fit_match by specifying the GEM/competency focus and analysis types (gem_full, gem_lite, career_path).

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

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

Provides explicit prerequisites ('Candidate CV must be fully parsed first -- verify with atlas_get_candidate') and complete workflow guidance ('Poll with careerproof_task_status(task_id) until status=completed, then fetch results with atlas_get_analysis...'). Names specific sibling tools for polling and result retrieval, creating a clear usage chain.

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?

Adds valuable behavioral context beyond annotations: discloses cost ('5 credits'), confirms synchronous execution ('no polling needed'), and clarifies dependencies ('Does not require a context or candidate'). Annotations indicate this is not read-only (readOnlyHint: false) and interacts with external systems (openWorldHint: true), which aligns with the description's mention of 'live web search' for salary data. No contradictions present.

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

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

Three sentences with zero waste. Front-loaded with specific functionality and cost, followed by execution characteristics, ending with workflow guidance. Every sentence earns its place with dense, actionable information.

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

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

Given the tool's complexity (multi-dimensional analysis with credit cost) and lack of output schema, the description adequately covers the analysis scope, cost model, and workflow integration. Minor gap: does not describe the return structure or format, though it lists the five analysis dimensions which provides implicit output guidance.

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

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

With 50% schema description coverage (industry_hint and location_hint lack schema descriptions), the description partially compensates by referencing 'raw JD text' (supporting jd_text) and 'salary benchmarking' (supporting include_live_search). However, it fails to explain the purpose of industry_hint and location_hint optional parameters, leaving semantic gaps for half the parameter set.

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 provides a specific verb (analyze), clear resource (job description text), and enumerates five specific analysis dimensions (market competitiveness, clarity issues, bias detection, salary benchmarking, skills extraction). It clearly distinguishes this from sibling tools by specifying it works on raw JD text without requiring a context or candidate.

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

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

Explicitly states prerequisites ('Does not require a context or candidate'), input format ('accepts raw JD text'), and execution pattern ('Synchronous -- returns results directly'). Critically, it provides clear workflow guidance: 'Use results to refine JDs before running atlas_start_jd_fit_batch,' explicitly naming the sibling tool that depends on this output.

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

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

Discloses critical cost information ('3 credits per candidate') not found in annotations. Explains async pattern requiring polling. Clarifies fallback behavior when jd_content is omitted. Aligns with annotations (readOnlyHint=false, idempotentHint=false) by implying a non-idempotent creation operation that returns a new batch_id.

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?

Perfectly structured and front-loaded: sentence 1 states purpose and cost; sentence 2 return value; sentence 3 workflow; sentence 4 fallback logic; sentence 5 prerequisites. No redundant words, every sentence provides actionable guidance.

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?

Comprehensive for an async batch operation without output schema. Explains the full lifecycle (start → poll → fetch), return value (batch_id), cost structure, and prerequisite data sources. Annotations provide safety hints (non-destructive), while description provides operational context.

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

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

Schema coverage is 60% (3/5 params documented). Description reinforces semantic context for context_id and candidate_ids by specifying their source functions, but fails to explain the two undocumented parameters: jd_title (unclear if metadata or functional) and use_kb_enhancement (undefined boolean). Compensates partially but leaves significant gaps.

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?

Excellent specific purpose: 'Start a batch JD-FIT analysis: match multiple candidates against a job description' includes specific verb (Start/match), resource (JD-FIT analysis), and scope (batch/multiple). Distinguishes from single-candidate siblings (atlas_start_fit_match) by emphasizing 'batch' and 'multiple candidates'.

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

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

Provides explicit workflow: poll with atlas_get_jd_fit_batch_status until complete, then fetch with atlas_get_jd_fit_results. States prerequisites ('Requires context_id from atlas_list_contexts'). Clarifies fallback behavior ('If jd_content is omitted, uses the context's active JD') and references specific sibling tools for the full lifecycle.

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?

Adds significant operational context beyond annotations: discloses 15 credit cost, explains async pattern (returns IDs requiring polling), specifies PDF output format, and describes completion criteria (status='completed'). Annotations already cover safety profile (non-destructive write), so description adds workflow and cost transparency.

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

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

Single compound sentence efficiently packs cost, prerequisites, return values, polling mechanics, and download instructions. Front-loaded with core action 'Start async generation'. Every clause is essential for correct API usage; zero wasted words despite high information density.

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?

Excellent coverage for an async mutation tool with no output schema. Compensates for missing output_schema by documenting return values (report_id, task_id), polling behavior, and final download format. Credit cost disclosure is critical for user decision-making.

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

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

With 100% schema description coverage, the schema already documents parameters thoroughly (including examples like 'candidate_evaluation'). Description reinforces the dependency on atlas_list_report_types but adds no new parameter semantics beyond what's in the schema descriptions.

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

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

Description clearly states 'Start async generation of a research report' with specific verb (Start/async generation) and resource (research report). The async workflow and PDF output distinguish it from synchronous sibling tools like atlas_chat or atlas_get_report.

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

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

Provides explicit prerequisite: 'Call atlas_list_report_types first'. Details complete polling workflow using careerproof_task_status or atlas_get_report, and specifies atlas_download_report for final retrieval. Explicitly names alternative tools for each lifecycle phase.

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 already indicate idempotent, non-destructive writes. The description adds valuable context that the operation is 'Free' (cost) and 'Returns the updated context object' (confirming output), but does not disclose error behaviors (e.g., what happens if context_id is invalid) or side effects beyond the annotations.

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

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

Extremely concise at four short sentences with zero redundancy. Information is front-loaded with the action verb, followed by prerequisites, return value, and cost. Every sentence delivers distinct value (purpose, dependency, output, pricing).

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?

Adequate for basic usage given the existence of an output schema (so return values need not be detailed), but insufficient for the input complexity. The hiring_context parameter contains deeply nested properties (budget_ranges, open_roles, etc.) that warrant explanation, yet the description treats it as a flat field alongside simple strings.

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

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

With only 11% schema description coverage, the description partially compensates by mapping concepts like 'name' to company_name and 'size' to company_size, and highlighting the required context_id. However, it fails to document four parameters (location, is_active, is_default, company_website) and provides no guidance on the complex nested structure of the hiring_context object.

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

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

The description clearly states the tool updates 'hiring context details' with specific fields (name, industry, size, hiring context), providing a concrete verb and resource. It implicitly distinguishes from sibling tools like atlas_create_context by emphasizing the update operation and requirement for an existing context_id.

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

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

Explicitly states the prerequisite that context_id must come from atlas_create_context or atlas_list_contexts, providing clear dependency guidance. However, it lacks explicit guidance on when to use this versus creating a new context or which fields are optional versus required for an update.

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?

While annotations declare idempotentHint=true and readOnlyHint=false, the description adds valuable behavioral context: it discloses that the operation is 'Free' (cost transparency) and explicitly states the return value ('Returns the updated model object'), which is crucial given the lack of an output schema. No contradictions with annotations.

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

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

The description is efficiently structured with zero waste: the first sentence establishes the core operation and scope, the second identifies the ID source, and the final two fragments concisely disclose return behavior and cost. Every statement earns its place without redundancy.

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

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

Given the tool's complexity (updating evaluation models with nested dimension/weight objects) and lack of output schema, the description adequately covers the return object and cost. However, it could be improved by clarifying whether omitted fields result in partial updates versus requiring full object replacement, which is critical for a mutation 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?

With 100% schema description coverage, the schema already documents all five parameters. The description adds semantic grouping by categorizing the fields as 'metadata' and mapping them to the schema properties, but does not provide additional syntax guidance, examples, or constraint explanations beyond what the schema already supplies.

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 ('Update') and clearly identifies the resource ('custom evaluation model') and specific updatable fields ('name, description, inferred dimensions, weights'). It effectively distinguishes this from sibling tools like 'atlas_create_custom_eval_model' and 'atlas_list_custom_eval_models' through both naming and the explicit reference to retrieving model_id from those tools.

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

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

The description provides clear prerequisite guidance by specifying that 'model_id' comes from 'atlas_create_custom_eval_model or atlas_list_custom_eval_models'. However, it lacks explicit guidance on when NOT to use this tool versus similar siblings like 'atlas_set_custom_eval_rubric_overrides' or 'atlas_clear_custom_eval_rubric_overrides'.

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?

While annotations declare readOnlyHint=false and destructiveHint=false, the description adds critical behavioral context: CV parsing is asynchronous (key timing info), returns a candidate object with 'id' (compensating for missing output schema), and notes the tool is 'Free' (cost transparency). Does not contradict annotations.

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?

Six efficient sentences with zero waste. Front-loaded with purpose, followed by async behavior, return value usage, workflow prerequisites, dependency resolution, and cost. Every sentence earns its place with specific actionable information.

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

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

Given the multi-step workflow complexity (upload → async parse → status check → downstream usage), no output schema, and 7 parameters, the description provides sufficient context. It explains the return value structure, the async lifecycle, and integration points with sibling tools, though it could briefly note error handling or the optional parameters' purposes.

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 57% (moderate). The description adds semantic context for context_id (where to obtain it) and file (CV PDF/DOCX content), but does not compensate for the three undocumented parameters in the schema (notes, candidate_name, candidate_email). Baseline appropriate for partial coverage.

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

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

The description clearly states the specific verb (Upload), resource (candidate CV), format constraints (PDF/DOCX), and target (hiring context). It distinguishes this from sibling tools like ceevee_upload_cv by specifying the 'hiring context' scope and atlas_ prefix workflow.

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?

Excellent guidance: explicitly names four specific sibling tools (atlas_start_gem_analysis, atlas_fit_match, atlas_generate_interview, batch tools) to use the returned candidate_id with, specifies atlas_get_candidate as the prerequisite check for parsing completion, and identifies context_id sources (atlas_create_context or atlas_list_contexts).

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?

Beyond the annotations (which indicate it's a write operation), the description adds valuable behavioral context: the 'Free' cost disclosure, the base64 encoding requirement, file format constraints (PDF/DOCX), and the semantic meaning of quality labels (strong/weak/mixed). No contradiction with annotations exists.

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?

Every clause earns its place: action definition, format/encoding constraints, enum listings for artifact_type, enum listings plus semantics for label, model_id sourcing, and cost. Information is front-loaded and densely packed without redundancy.

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

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

For a machine learning training-data upload tool, the description adequately covers prerequisites (model_id source), file constraints, cost, and labeling semantics. Given the lack of output schema, it appropriately focuses on input requirements, though it could briefly mention whether uploads trigger immediate processing or require separate training initiation.

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?

Despite 100% schema coverage (baseline 3), the description adds meaningful value by explaining what the 'label' parameter represents ('how this artifact exemplifies quality'), explicitly enumerating valid artifact_type values, and clarifying the base64 encoding requirement for the file parameter which aids correct invocation.

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 specific action (Upload), resource (file artifact), and purpose (to teach a custom eval model). It explicitly distinguishes this from sibling text-based tools by emphasizing 'file artifact' and specifying PDF/DOCX formats, while also listing the specific artifact types (CV, JD, template).

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 explicit guidance on obtaining the model_id parameter by referencing sibling tools (atlas_create_custom_eval_model or atlas_list_custom_eval_models). While it implies this is for file uploads versus text (contrasting with atlas_add_custom_eval_text_artifact), it could more explicitly state when to prefer this over the text-based alternative.

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 confirm read-only/idempotent nature, but the description adds critical workflow context (prerequisite status check) and the complex ID mapping logic. The 'Free' notation is slightly ambiguous but suggests no consumption cost.

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?

Information-dense but necessary given the complexity of 6 result types with different ID requirements. Structure flows logically from purpose → prerequisite → ID mapping table → exception. Only minor clutter is the trailing 'Free.'

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?

Comprehensive for a complex multi-type retrieval tool. Without output schema, it appropriately focuses on input requirements, documenting all result_type variations and their corresponding ID sources from sibling 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?

Despite 100% schema coverage (baseline 3), the description adds significant value by documenting ID provenance (e.g., 'from atlas_start_gem_analysis') and explicitly noting the jd_fit_batch exception requiring context_id instead of resource_id.

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

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

The description explicitly states 'Retrieve the full result of a completed async task' with a specific verb and resource. It clearly distinguishes from sibling 'careerproof_task_status' by stating this retrieves results while implying the other checks status.

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

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

Provides explicit workflow guidance: 'Call careerproof_task_status first to confirm status='completed'.' This establishes clear prerequisites and sequencing with an alternative tool.

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

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

Annotations cover safety profile (readOnly/idempotent). Description adds crucial behavioral context: specific status enum values, polling frequency recommendation, cost ('Free'), and workflow transition logic not present in structured fields.

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

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

Four dense sentences with zero waste. Front-loaded with purpose, followed by return values, workflow transition, polling guidance, parameter source, and cost. Logical progression.

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?

Comprehensive for an async status tool. Covers lifecycle (pending→completed), polling mechanics, result retrieval handoff, and input provenance. Presence of output schema means detailed return structure doesn't need expansion.

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

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

Schema has 100% coverage (baseline 3). Description augments task_id semantics by enumerating specific async start tools that generate valid IDs (atlas_start_gem_analysis, etc.), helping the agent understand valid parameter sources.

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

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

Clear specific verb ('Check') and resource ('status of any async task'). Explicitly distinguishes from sibling 'careerproof_task_result' by stating when to use each (status vs. full results).

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

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

Provides explicit workflow guidance: use for polling, then switch to careerproof_task_result when 'completed'. Lists prerequisite task sources (atlas_start_* tools). Includes operational polling interval (5-10 seconds).

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?

Beyond annotations (readOnlyHint: false, etc.), the description adds critical operational context: '5 credits' cost and '20-30s' latency. It also discloses return values (positioning snapshot, narrative lens, flags) despite no output schema being present.

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

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

Four sentences with zero waste: sentence 1 defines action/cost/timing, sentence 2 lists return values, sentence 3 establishes pipeline position, sentence 4 gives parameter sourcing instructions. Information is front-loaded and dense.

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

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

Given this is a multi-step pipeline tool with no output schema, the description comprehensively covers what gets returned (session_id, lens, flags), the orchestration pattern, credit costs, and parameter provenance. No critical gaps remain for agent invocation.

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

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

With 100% schema coverage establishing a baseline of 3, the description adds valuable semantic context by specifying that cv_version_id comes from 'ceevee_upload_cv or ceevee_list_versions' and explaining that session_id is used to resume existing sessions in the pipeline context.

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

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

Description uses specific verb 'Run' with resource 'market positioning analysis on a CV version' and clearly distinguishes itself as 'step 1 of the 3-step positioning pipeline' from siblings like ceevee_get_opportunities and ceevee_confirm_lens.

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

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

Provides explicit workflow guidance with arrow notation showing the full pipeline (analyze_positioning -> ceevee_get_opportunities -> ceevee_confirm_lens), specifies to 'Pass the returned session_id to subsequent steps', and indicates prerequisite tools for obtaining cv_version_id.

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?

Adds cost information ('2 credits') not present in annotations. Describes return structure ('AI response with optional edit suggestions, source citations, and a conversation_id') despite absence of output schema. Explains stateful conversation threading behavior, complementing the idempotentHint=false annotation. Does not disclose rate limits or error behaviors.

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

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

Two dense sentences with zero waste. First sentence covers action, cost, and prerequisites. Second sentence covers return values and threading logic. Information is front-loaded and structured logically.

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 conversational tool without output schema, description comprehensively covers: cost, prerequisites, return value structure, and conversation state management. Given the complexity of threading and credit consumption, this is sufficiently 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?

While schema has 100% coverage (baseline 3), description adds valuable context: specifies exact sibling tools to obtain cv_version_id, and explains the conversation_id lifecycle (omitting starts new, including continues thread). This operational context exceeds the schema's static definitions.

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

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

Specific verb (Send) + resource (message to CeeVee AI) + scope (CV optimization guidance) clearly stated. Distinguishes from sibling tools by specifying domain (CV optimization vs analysis/review functions in other ceevee_* tools).

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

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

Excellent prerequisite guidance ('Requires a cv_version_id') with explicit pointer to getter tools (ceevee_upload_cv or ceevee_list_versions). Clear threading instructions (omit vs include conversation_id). Lacks explicit comparison to similar chat tools (e.g., atlas_advisor_chat) but context implies CV-specific 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?

Annotations indicate non-read-only, non-destructive operation. Description adds critical operational context missing from annotations: cost (5 credits), latency (20-30s), and return structure (before/after text, trade-off notes, PDF URLs). Does not contradict annotations.

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?

Information-dense yet readable. Front-loaded with core action and cost, followed by return values, pipeline positioning, and cross-references. Every sentence conveys distinct operational or navigational information without redundancy.

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

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

Compensates effectively for missing output schema by detailing return values (section edits array with before/after text, trade-off notes, optional PDF URLs). Addresses pipeline context, cost, timing, and sibling relationships. Thorough for a complex 8-parameter workflow 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?

With 100% schema coverage, baseline is 3. Description adds valuable semantic context by specifying data lineage—parameters should be sourced from prior pipeline steps (ceevee_analyze_positioning, ceevee_get_opportunities)—helping agents understand not just what to pass, but where to obtain values.

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 verbs (confirm, generate) and resources (narrative lens, CV edits) clearly stated. Explicitly distinguishes itself as 'step 3 (final step) of the positioning pipeline,' differentiating it from sibling tools like ceevee_analyze_positioning and ceevee_explain_change.

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?

Excellent sequential guidance: identifies itself as step 3, specifies prerequisite ('Pass confirmed_lens from ceevee_analyze_positioning'), notes optional enrichment data from prior steps, and explicitly references ceevee_explain_change for understanding specific edits, providing clear alternative pathways.

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?

While annotations confirm read-only/idempotent safety, the description adds critical behavioral context: the return format ('base64-encoded PDF content'), cost ('Free'), and state prerequisites ('completed'). Does not cover rate limits or error scenarios, preventing a 5.

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

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

Four sentences with zero waste: purpose, return format, workflow prerequisites, and cost. Information is front-loaded and densely packed without redundancy.

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

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

For a single-parameter download tool, the description is complete: output format is specified (compensating for lack of output schema), prerequisites are documented, and cost is disclosed. No gaps remain for an agent to invoke this tool 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?

With 100% schema description coverage, the baseline is 3. The description repeats the schema's guidance on report_id sourcing from sibling tools but does not add semantic nuance (e.g., number format, validation rules) beyond what the schema already provides.

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

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

The description opens with a precise action ('Download') and resource ('completed CeeVee report as PDF'), clearly distinguishing it from sibling atlas_download_report and metadata tools like ceevee_get_report by specifying the PDF output format and CeeVee 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?

Provides explicit prerequisites: 'Only call after ceevee_get_report confirms status=completed'. Also traces the data lineage for report_id back to specific sibling tools (ceevee_generate_report, ceevee_list_reports), establishing clear workflow sequencing.

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 indicate readOnlyHint=false and idempotentHint=false, suggesting potential side effects. The description adds critical behavioral context missing from annotations: the '(1 credit)' cost and that it 'Returns a detailed rationale.' However, it doesn't clarify the implications of idempotentHint=false (whether retries cost multiple credits) or what happens if invalid IDs are provided.

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

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

Four sentences efficiently structured: purpose with cost upfront, parameter source explanations, and return value description. Every sentence provides distinct value (cost info, parameter provenance for both params, return type). No redundancy with schema or annotations.

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

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

Given no output schema exists, the description compensates by stating it 'Returns a detailed rationale for the recommended change.' It covers the credit cost and workflow integration. Could improve by mentioning error scenarios (e.g., invalid change_id) or retry behavior given idempotentHint=false, but adequately complete for a 2-parameter consumption 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?

With 100% schema description coverage, the baseline is 3. The description elevates this by adding semantic context about parameter provenance—specifically which sibling tools generate the required IDs—and provides concrete examples for change_id ('e.g., '1', '2''). This workflow context goes beyond the schema's technical definitions.

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

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

The description clearly states the tool 'Get[s] a detailed explanation of a specific edit from a positioning review' with specific verb and resource. It distinguishes itself from generic retrieval tools by specifying it concerns 'positioning review' edits and explicitly notes the '(1 credit)' cost, differentiating it from free lookup operations.

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

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

Provides explicit workflow guidance by stating exactly where parameters originate: 'change_id comes from the edits array returned by ceevee_confirm_lens or ceevee_full_review' and 'cv_version_id from ceevee_upload_cv or ceevee_list_versions.' This creates a clear dependency chain with sibling tools, telling the agent precisely when to invoke this tool (after obtaining edits from those specific sources).

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?

Adds critical context beyond annotations: credit cost, execution duration (30-60s), and return value structure ('positioning snapshot, detected lens, targeted edits with trade-offs') compensating for missing output schema. Does not contradict annotations (readOnlyHint: false aligns with autonomous review creation).

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

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

Four dense sentences with zero waste: action/components/cost upfront, sibling differentiation second, return values third, parameter sourcing fourth. 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 complex, credit-consuming composite tool with no output schema, the description adequately covers returns, cost, timing, and prerequisites. Minor gap: does not specify error behavior or whether results are persisted/cached given idempotentHint: false.

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 80% (high), so baseline applies. Description mentions 'cv_version_id' source but largely repeats schema information. Does not significantly augment understanding of jd_text, requested_lens, or include_opportunities beyond what the schema provides.

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

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

States specific action ('Run autonomous full CV review'), composite components ('positioning + lens detection + targeted edits + optional opportunities'), and explicitly distinguishes from the 3-step pipeline siblings (ceevee_analyze_positioning -> ceevee_get_opportunities -> ceevee_confirm_lens).

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

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

Explicitly identifies when to use ('Alternative to the 3-step pipeline') with specific tool names, provides cost ('10 credits') and timing ('30-60s') for decision-making, and notes prerequisite steps ('cv_version_id from ceevee_upload_cv').

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?

Adds substantial context beyond annotations: discloses 15-credit cost, 2-3 minute duration, exact polling limits (40 polls/20 min max), specific status values ('completed', 'failed'), and timeout behavior. Matches readOnlyHint: false with 'generate' write operation.

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

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

Information-dense and well-structured with clear POLLING section and upfront cost/timing details. The enumeration of 17 report categories adds length but provides necessary discovery value given the lack of enums in the schema. No wasted 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?

Comprehensive for a complex async workflow with no output schema. Covers the full lifecycle (initiation → polling → download/error/timeout), credit costs, timing constraints, and enumerates all valid report categories to compensate for the open-ended string parameter.

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

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

Schema coverage is 100% so baseline is 3. Description adds valuable context by explaining that 'inputs' contains report-specific fields like role_title/industry and that cv_version_id enables 'CV-aware reports', plus the critical instruction to consult ceevee_list_report_types for valid report_type values.

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 ('Generate') with clear resource ('CeeVee career-intel report') and explicitly distinguishes this from siblings by detailing the async workflow requiring subsequent calls to ceevee_get_report and ceevee_download_report.

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

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

Provides explicit prerequisites ('Call ceevee_list_report_types first'), step-by-step polling protocol ('every 30 seconds, up to 40 times'), and clear branching logic for completion/failure/timeout states with specific sibling tool names for each action.

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