RTK Motion — Motion Capture, Biomechanics, and Threat Intelligence

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

No annotations provided, so description carries full burden. Discloses 'Free, no payment required' (cost transparency) and explains behavioral contract for different path inputs (what return structures to expect at root/category/lesson levels). Could mention read-only safety or auth requirements to reach 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?

Three sentences, zero waste. Front-loaded with purpose ('Browse hierarchical catalog...'), followed by path behavior specification, ending with cost constraint. Each sentence conveys distinct value (purpose, usage logic, cost).

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 single parameter and no output schema, description compensates by detailing return values for different traversal levels (file inventory, pricing, MCP tool names). Covers domain context (motion-capture, threat-intel, rehab-biomechanics). Complete enough for selection and basic 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%, but description adds significant semantic value beyond schema. Schema only states 'Catalog path to browse' with examples; description explains the functional mapping of different path patterns (no path→root, category→children, lesson→inventory/pricing/tools), clarifying the hierarchical navigation logic.

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

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

Specific verb+resource: 'Browse hierarchical catalog of motion-capture, threat-intel, and rehab-biomechanics datasets.' Distinguishes from siblings by emphasizing navigation/discovery versus data retrieval (get_* siblings) or search (search_catalog). Domain specificity clarifies scope.

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 contextual guidance for the path parameter: 'No path → root categories. Category path → children. Lesson path → file inventory...' Implicitly differentiates from search_catalog by emphasizing hierarchical traversal, though explicit 'when to use search vs browse' statement would strengthen this to 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?

With no annotations provided, description carries full burden and successfully discloses critical behavioral traits: $10 USDC cost per file, latency constraints (<500 ms), and required payment workflow sequence (send USDC, then pass payment_tx). Missing return value format prevents 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?

Extremely dense and front-loaded: opens with resource type and use cases, follows with technical specs, then cost and payment instructions. No redundant words; every sentence conveys essential domain, performance, or financial 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?

Adequately covers purpose, technical specifications, and payment requirements for a paid retrieval tool, but lacks description of return values (file content, URL, or path) which is significant given no output schema exists. Missing error handling for failed payments.

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 with clear descriptions. Description adds valuable workflow context for payment_tx ('Pass payment_tx after sending USDC'), establishing temporal sequence not evident in schema alone. Baseline 3 for high schema coverage, with minor addition.

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 output format (BVH skeletal animation) and precise use cases (robotic_grappling_training, biomechanical_rehab_validation) that distinguish it from siblings like get_keypoints_3d or get_video_url. Technical specs (120 Hz, 24-joint) further clarify scope.

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 positive use cases (grappling training, rehab validation) and mandatory payment workflow, but lacks explicit differentiation from similar data retrieval tools (e.g., when to choose this over get_keypoints_3d) or exclusion criteria.

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

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

With no annotations provided, the description bears full responsibility for behavioral clarity. It indicates a safe read operation (no destructive hints) and specifies the output format (text .calib file). It does not mention permissions or side effects, but for a retrieval tool, this is adequate.

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

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

The description is two sentences long, with no wasted words. It front-loads the core purpose and provides necessary context in a compact form. Every sentence serves a clear function.

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

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

For a simple retrieval tool with one optional parameter and no output schema, the description is sufficiently complete. It explains what the tool returns, when it is needed, and the output format. The term 'FREE' is slightly ambiguous but does not detract from completeness.

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

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

The input schema has 100% description coverage for the single parameter 'lesson_path'. The tool description adds no additional semantic information about the parameter beyond what the schema already provides (default behavior and example). Baseline score of 3 is appropriate given high schema coverage.

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

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

The description clearly identifies the tool as retrieving multi-camera calibration parameters (intrinsics and extrinsics) and specifies the output as a .calib file. It distinguishes itself from sibling tools like get_bvh or get_mocap_sample by focusing on calibration data needed for reprojection and rendering pipelines.

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

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

The description explicitly states when the tool is required ('for any pipeline that reprojects, retriangulates, or renders against the original capture geometry'). While it does not mention when to avoid using it, the clear requirement context serves as good guidance. No alternative tools are mentioned, but the siblings are sufficiently different.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: that this provides a limited free sample (5 seconds/600 frames), mentions the data format (BVH), and indicates this is for validation purposes rather than full analysis. However, it doesn't specify response format, error conditions, or authentication requirements.

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

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

The description is efficiently structured with two sentences that each earn their place. The first sentence establishes the core offering and specifications, while the second provides context about alternatives and pricing. There's no wasted verbiage, and key information is 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?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description provides good contextual completeness. It explains what the tool returns (free sample with specific characteristics), when to use it, and alternatives. However, without an output schema, it could benefit from more detail about the return format or 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?

Schema description coverage is 100%, so the schema already documents both parameters completely. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

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

The description clearly states the tool's purpose with specific verbs ('get', 'validate') and resources ('motion capture sample', 'BVH skeletal animation'). It distinguishes from sibling tools by specifying this is a free sample (vs. paid full files via get_bvh) and mentions specific use cases (sim_to_real_retargeting, action_recognition).

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 when to use this tool ('first 5 seconds... Enough to validate format, joint hierarchy, and data quality') and when to use alternatives ('Full files are 30-120 seconds ($10 USDC via get_bvh)'). It clearly differentiates this free sample tool from the paid full-file sibling tool.

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

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

With no annotations provided, the description carries the full burden. It adds crucial cost context ('Free') and workflow sequencing (evaluate before purchasing), but lacks explicit safety confirmation (read-only status), error behavior, or return format details that would fully compensate for missing 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?

Two sentences with zero waste. Front-loaded with data contents, followed by cost model and usage guidelines. Every word 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 lookup tool with no output schema, the description adequately covers what data is returned, the cost model, and the workflow relationship to other tools. It explains the return values (demographics, history, meds) despite lacking formal 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?

Schema description coverage is 100% (case_path is fully documented with example format), establishing baseline 3. The description adds no additional parameter context, but none is needed given the single, well-documented parameter.

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

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

The description clearly states what data is returned (patient demographics, injury history, medications) and identifies the resource (rehab case). It distinguishes from sibling tools like get_rehab_report by positioning this as the free preliminary step versus purchased biomechanical reports.

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 explicit guidance: 'evaluate case relevance before purchasing biomechanical reports' clearly states when to use this tool (before purchase) and implies the alternative (purchasing reports). It also specifies use cases: insurance_claim_validation or PT_outcome_measurement.

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

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

With no annotations provided, the description carries the full burden and discloses key behavioral traits: output formats (JSON + TXT), performance constraints (Latency < 200 ms), and cost ($0.25 USDC). However, it omits safety characteristics (read-only vs. destructive), error handling behavior, or side effects.

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

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

Exceptionally dense and front-loaded. Every token serves a purpose: audience, content metrics, technical specs, and pricing. No filler words or redundant explanations. The structure moves logically from purpose to contents to operational constraints.

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

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

Given the lack of output schema, the description adequately compensates by listing report contents (biomechanical metrics) and formats. However, it could improve by describing the output structure (e.g., whether it returns file paths, raw data, or URLs) and error scenarios (e.g., invalid payment_tx handling).

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 the schema has 100% coverage (baseline 3), the description adds semantic value by stating the exact cost ('$0.25 USDC'), which clarifies the purpose of the payment_tx parameter. It also reinforces the exercise parameter domain by listing examples (Burpees, Pushups, Squats) that align with the schema's intent.

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 explicitly states it generates a 'Per-exercise biomechanical report' and distinguishes its scope with specific use cases (PT_outcome_measurement, medical_insurance_review) and detailed metrics (CoM stability, joint load, bilateral asymmetry, etc.). The 'Per-exercise' qualifier effectively differentiates it from sibling tools like get_rehab_summary and get_rehab_profile.

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

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

Provides implied usage context through specific use cases ('for PT_outcome_measurement or medical_insurance_review'), but lacks explicit when-to-use guidance versus siblings like get_rehab_profile or get_rehab_summary. No exclusions or prerequisites are mentioned beyond the payment requirement implied by the price listing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: this is a free sample/demo tool that returns non-numeric structural data (not full numeric data), mentions data quality and coverage demonstration, and implies a commercial upgrade path. It doesn't cover rate limits or authentication needs, but provides substantial context for a sample tool.

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

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

The description is extremely concise and front-loaded with the core purpose in the first phrase. Every sentence earns its place: the first establishes what the tool does, the second explains what it demonstrates, the third provides the upgrade alternative, and the fourth gives a usage example. Zero wasted words.

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

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

Given this is a simple single-parameter tool with no output schema, the description provides excellent context about what the tool returns (structure and metric categories without numeric values), its demo/sample nature, and the upgrade alternative. The only minor gap is lack of explicit information about the return format or potential errors, but for a sample tool, this is reasonably complete.

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

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

Schema description coverage is 100% for the single parameter, so the baseline would be 3. However, the description adds meaningful context beyond the schema by providing a specific example value ('Try case_path='PhysicalRehab/40-50/Male/LabrumTear'') and explaining this parameter defaults to a 'showcase case,' which helps users understand the parameter's purpose in practice.

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

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

The description clearly states the tool's purpose: to retrieve a 'FREE rehab biomechanics sample' that 'shows the structure and metric categories of a clinical summary without numeric values.' It distinguishes from sibling tools by specifying this is a sample/demo version versus 'get_rehab_summary' for full 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?

The description explicitly states when to use this tool ('FREE rehab biomechanics sample — shows the structure and metric categories...') and when to use an alternative ('Upgrade to get_rehab_summary ($0.50) for full numeric data'). It also provides a specific example case path to try.

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

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

With no annotations provided, description carries full burden and delivers: output formats (JSON + TXT), performance characteristics (Latency < 300 ms), cost ($0.50 USDC), and detailed content schema (bilateral asymmetry indices, ROM, fatigue markers). Discloses payment requirement implicitly through cost parameter and 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 dense sentences with zero waste. Front-loaded with purpose ('Cross-exercise biomechanical summary...'), followed by content details, technical specs, and cost. Every clause delivers distinct information (use cases, metrics, formats, latency, 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?

Comprehensive for a 2-parameter tool without output schema. Describes return value content (clinical synthesis, deficits), format, and operational constraints (cost, latency). Missing only failure modes (e.g., invalid payment) to achieve completeness given the payment requirement complexity.

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

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

Schema coverage is 100%, establishing baseline 3. Description adds value by clarifying case_path represents 'Cross-exercise' aggregation (not single-session) and confirming payment_tx cost ($0.50 USDC matches schema's $0.50 USD). This semantic context aids parameter understanding beyond raw 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 resource (cross-exercise biomechanical summary) and use cases (insurance_claim_validation, rehab_progress_tracking). Distinguishes from siblings like get_rehab_report via 'Cross-exercise' scope and 'clinical synthesis' focus. However, lacks explicit contrast with similar get_rehab_profile/get_rehab_report 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?

Provides specific use cases (insurance validation, rehab tracking) implying when to use, but offers no explicit 'when not to use' guidance or comparison to sibling alternatives like get_rehab_report. Usage context is implied rather than directive.

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

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

With no annotations provided, the description carries full disclosure burden effectively. It reveals cost ($15 USDC), technical constraints (latency <500ms), output format (NPZ), and integration targets. Could improve by mentioning error behavior for invalid payments.

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 dense but zero waste. Technical specs (120Hz/24DOF), compatibility, pricing, and usage instruction each serve distinct purposes. Front-loaded with the resource type.

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?

Substantially complete for a paid robotics data retrieval tool. Covers format, integration ecosystem, pricing model, and authentication mechanism despite missing output schema. Minor gap: no mention of failure modes for insufficient payment.

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 crucial workflow semantics: establishes the $15 cost and explicitly sequences the payment action ('after sending USDC'), clarifying that payment_tx is a post-payment confirmation hash, not the payment itself.

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 specificity: states it returns 'Robot-ready joint trajectories (NPZ)' for 'sim_to_real_kinematic_retargeting', with clear compatibility targets (MoveIt/ROS, Isaac Sim) and technical specs (120Hz, 24DOF) that distinguish it from sibling tools like get_bvh or get_keypoints_3d.

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 payment workflow guidance ('Pass payment_tx after sending USDC'), implying this is a paid resource retrieval tool. However, lacks explicit guidance on when to choose this over get_bvh or get_keypoints_3d for different use cases.

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

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

With no annotations provided, the description carries full disclosure burden. It successfully conveys cost ('Free') and evaluative purpose ('evaluate coverage and data freshness'), but omits explicit read-only confirmation, auth requirements, or rate limits that would fully establish 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?

Two dense sentences with zero waste. First sentence uses em-dash to front-load returned data components; second sentence delivers business logic and purchasing context. 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?

Lacks output schema, but description compensates by enumerating profile components (assets, feeds, intervals, terms) and business model context. Deducted one point for not explicitly confirming non-destructive read behavior given 'threat' domain sensitivity.

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 (region and location both documented), establishing baseline 3. Description adds implicit context that 'location' refers to a monitored site via 'Monitored location profile,' but does not elaborate parameter formats 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?

The description identifies specific resources retrieved (assets, feed types, scan interval, term sets) and the target (monitored location profile), functioning as a concrete noun phrase. However, it could more explicitly distinguish from sibling 'get_threat_summary' by clarifying this returns raw configuration/data versus aggregated 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?

Explicitly states this is a free evaluation tool to use 'before purchasing threat assessments,' directly naming downstream workflows (risk_underwriting, security_operations). Provides clear temporal/business logic for when to invoke versus paid alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: 'FREE live threat assessment sample' indicates no cost and real-time data, 'Proves data is live and continuously updated' clarifies freshness, and 'No flagged items or entities' sets expectations on output limitations. However, it lacks details on rate limits, authentication needs, or error handling.

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 sized and front-loaded, with every sentence earning its place. It starts with the core functionality, adds behavioral context, provides usage guidelines, and ends with practical examples—all without redundancy. The structure is efficient and easy to parse.

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 low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, behavioral traits, and parameter context. However, it lacks explicit information on output format or error cases, which could be helpful for an agent, though not strictly required given the simplicity.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the parameter's purpose beyond the schema: it provides an example ('culpeper-town'), mentions it's a 'location slug,' and notes it 'Defaults to showcase location,' which clarifies usage context not in the schema. This elevates the score 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's purpose with specific verbs ('get threat assessment sample') and resources ('current threat level, confidence score, event distribution, and scan freshness for a monitored location'). It distinguishes from sibling tools by explicitly mentioning 'No flagged items or entities (upgrade to get_threat_summary for full detail)' and referencing browse_catalog for location discovery.

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 when to use this tool versus alternatives: 'No flagged items or entities (upgrade to get_threat_summary for full detail)' tells users when to choose the sibling tool. It also suggests usage context with 'Try location='culpeper-town' or browse_catalog path='ThreatIntel' for all locations,' offering practical examples and 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?

Provides extensive behavioral details (latency <200ms, output schema, payment prerequisite) which is necessary given no annotations. However, description states pricing as '$0.50/$1.00' while the input schema parameter description states '$0.10/$0.25', creating a serious contradiction on cost—a critical behavioral attribute.

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 dense and front-loaded structure. Every clause earns its place: use cases, tier pricing/features, performance SLA, and prerequisite workflow—all in a compact format 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 no output schema, the description commendably details return values for both tiers. Coverage of latency and payment prerequisites is good. However, the pricing contradiction with schema parameters creates a material gap in reliability, reducing confidence in the description's completeness.

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, baseline is 3. Description adds semantic value by describing what each tier returns (confidence-scored alerts vs enriched entities), but contradicts the schema on tier pricing and content descriptions ('summary only' vs 'confidence-scored alerts').

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 verb ('Location threat assessment') plus specific resource (location) and three concrete use cases (risk_underwriting, facility_security_audit, insurance_risk_modeling). However, it does not explicitly distinguish from sibling tool 'get_threat_profile', which could cause selection uncertainty.

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 appropriate contexts (risk underwriting, security audits). Provides clear prerequisite workflow ('Browse ThreatIntel via browse_catalog first') and tier selection guidance by detailing the output differences between Lite and Full tiers.

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

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

No annotations provided, so description carries full disclosure burden. Successfully communicates cost ($5 USDC per view), temporal constraints (15-min signed URL), technical capabilities (Range support), and stateful requirements (payment verification). Missing: error behavior, USDC recipient address, or retry policies.

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

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

Two sentences with zero waste. Front-loaded with use cases and technical specs (1080p, synced cameras), followed by cost/temporal constraints and payment workflow. Every clause provides unique information not replicated 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?

Moderately complete for a 3-parameter tool with payment complexity. Mentions return type (streaming URL) but lacks output schema details or structure. Critical omission: payment recipient address (RTK wallet) is referenced but not specified in description or schema, hindering successful invocation despite good parameter coverage.

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. Description adds valuable workflow context beyond schema: 'Pass payment_tx after sending USDC' clarifies temporal sequence for the payment_tx parameter, and 'Multi-view' contextualizes the view parameter's purpose in the camera system.

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 specificity: states it retrieves 'Multi-view grappling video' with explicit use cases (pose_estimation_training, technique_analysis). Clearly distinguishes from siblings like get_bvh (motion capture files), get_keypoints_3d (skeletal data), and get_rehab_* (medical reports) by specifying video content and 1080p camera 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 partial workflow guidance ('Pass payment_tx after sending USDC') and use case hints, but lacks explicit prerequisites (e.g., 'use browse_catalog to find lesson_path first') or comparisons to siblings like get_video_url vs get_bvh for different analysis needs.

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

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

No annotations provided, so description carries full burden. Discloses search scope (what datasets), matching fields (labels, paths, competitor names), return structure ('full lesson detail with pricing'), and cost ('Free'). Missing auth requirements and rate limits, but strong coverage of functional behavior.

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

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

Two sentences, zero waste. First sentence defines scope and matching behavior; second sentence discloses return values, enabling workflow, and cost. Information-dense 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?

No output schema exists, and description adequately compensates by specifying 'full lesson detail with pricing' as the return. Covers all three dataset domains and the purchase workflow implication. Would need rate limits or pagination details for a 5.

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 detailed descriptions and examples already provided (e.g., 'kimura', 'BJJ'). Description aggregates that matching occurs against 'labels, paths, competitor names, techniques' but adds no syntactic guidance beyond the schema. Baseline 3 appropriate when schema is self-documenting.

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 specificity: declares 'Full-text search' (specific verb + mechanism) across three distinct dataset types (motion-capture, threat-intel, rehab), clearly distinguishing it from sibling 'browse_catalog' and specific 'get_*' retrieval 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?

Provides clear workflow context: states output includes pricing to 'immediately call purchase tools,' guiding the agent on the search→purchase sequence. Lacks explicit 'when not to use' contrast with browse_catalog, but 'full-text' vs implied browsing distinction is clear.

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