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, the description carries the full burden. It discloses performance specs (60 fps, latency <500ms) and payment requirements, but does not explicitly state that it is a read-only operation or discuss error handling 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?

The description is three sentences, front-loaded with purpose and specs, then payment and alternatives. Every sentence adds value, though it is dense with technical details and addresses.

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, so the description should explain return values. It mentions 'BVH skeletal animation' but lacks format details. Error handling and edge cases are not addressed. Adequate but 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 coverage is 100% with descriptions for each parameter. The description adds minimal extra meaning (e.g., default lesson behavior) but largely restates schema info, so baseline 3 is appropriate.

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

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

The description clearly states that the tool provides BVH skeletal animation for specific domains (robotic_grappling_training or imitation_learning) and includes technical specifications (60 fps, 56-joint hierarchy) that differentiate it from siblings like get_trial_bvh.

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?

Explicit payment instructions and an alternative (get_trial_bvh) are provided, giving clear guidance on when to use this tool vs the trial. However, no explicit 'when not to use' or prerequisites beyond payment are mentioned.

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. It mentions 'FREE' and the frame count formula, but does not disclose authentication requirements, rate limits, or whether the call is side-effect-free. It adequately conveys the basic behavior but leaves gaps in 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?

The description is a single, compact paragraph that leads with the key value proposition ('FREE'), explains the sample size and formula, states its purpose, and contrasts with the paid alternative. Every sentence adds useful 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?

The description covers the sample's nature (5 seconds, BVH), use cases, frame count derivation, and the existence of a full-file alternative. For a simple tool with no output schema and optional parameters, this is nearly complete. The only minor gap is not explicitly stating the output format (BVH) is a common skeletal animation format, but it's implied.

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?

Both parameters have schema descriptions (100% coverage), so the description adds little beyond schema. It implicitly ties subject and lesson_path to selecting the sample but doesn't elaborate on formats or constraints. Baseline 3 is appropriate as schema already documents the parameters sufficiently.

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 returns a free 5-second BVH sample, specifies the frame count formula, and distinguishes it from the paid full-file sibling tool get_bvh. It also mentions specific use cases (sim_to_real_retargeting, action_recognition), making the purpose unambiguous.

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

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

The description implies use for validation/quality checks and contrasts with get_bvh for full downloads ('Full files are 20–120 seconds ($10 USDC via get_bvh)'), but does not explicitly state when not to use it or list alternative tools beyond get_bvh. It provides enough context for an agent to decide, but lacks exhaustive guidance on exclusions.

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?

No annotations are provided, so the description must carry full burden. It discloses latency, payment requirement, and output formats, but does not mention idempotency, error states, or rate limits. The payment details are explicit.

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

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

The description is front-loaded with purpose and metrics. It includes necessary payment details and latency. Some redundancy exists (payment repeated from schema), but overall it is 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?

No output schema is provided, so the description should explain the report structure. It lists metrics and formats but not how they are organized. Prerequisites or error handling are missing. More context would improve 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?

Schema coverage is 100% (all parameters described in schema). The description repeats parameter information from the schema (e.g., payment_tx) but provides context on what the tool does with the parameters. It does not add new parameter details 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 clearly states 'Per-exercise biomechanical report' and lists specific metrics and use cases (PT_outcome_measurement, medical_insurance_review). This distinguishes it from sibling tools like get_rehab_summary which likely provides a summary.

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

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

The description implies it is for detailed per-exercise reports but does not explicitly say when to use this tool versus alternatives (e.g., get_rehab_summary). No exclusionary guidance is provided.

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, the description discloses latency (<300ms), payment requirement ($0.50 USDC on Base), and output formats (JSON+TXT). This provides good behavioral context beyond the schema. No contradictions.

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 informative but somewhat dense, mixing purpose, output details, latency, and payment instructions in a single paragraph. Could be more concise by separating concerns.

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

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

The description lists output contents but lacks a structured description of the return format or fields. Since there is no output schema, more detail on the output structure would improve 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?

Schema coverage is 100%, describing both parameters. The description adds payment details and an example for case_path, but does not add new parameter semantics beyond what is in the schema. The payment context is valuable.

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 produces a 'cross-exercise biomechanical summary' and lists specific use cases (insurance_claim_validation, rehab_progress_tracking) and content types (asymmetry indices, ROM, fatigue markers). This distinguishes it from siblings like get_rehab_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?

The description mentions two use cases but does not provide explicit when-to-use or when-not-to-use guidance relative to sibling tools such as get_rehab_report or get_threat_summary. Some implied usage but no exclusions.

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 data format (NPZ), compatible frameworks (MoveIt/ROS, Isaac Sim), frame rate (60 fps), latency (<500ms), and payment requirements (USDC on Base with specific wallet and chain). Does not mention error handling or rate limits, but covers essential behavioral 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?

Description is relatively concise for the amount of information provided, with core purpose upfront. However, it mixes functional description with operational payment details in a single paragraph, which could be better 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?

Given no output schema and 4 parameters, description covers input well and specifies output format and use cases. However, lacks details on NPZ file content structure and error handling. Adequate but not fully complete.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds context for robot platforms and mentions trial sample, but does not add significant value beyond schema descriptions for parameters like subject and lesson_path.

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 tool retrieves multi-robot joint trajectories in NPZ format for sim_to_real_retargeting or imitation learning, specifically for Unitree G1 (24 DOF) and H1 (19 DOF) platforms. Distinguishes itself from siblings like get_bvh by specifying format and use case.

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 payment instructions and mentions a cheaper trial alternative (get_trial_robotarget). However, does not explicitly explain when to use this tool vs. other siblings like get_mocap_sample or get_bvh. Some guidance exists but is incomplete.

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?

With no annotations, the description carries full burden. It discloses latency (<200ms) and pricing tiers. It explains payment requirements (USDC on Base, wallet address). However, it omits behavior on invalid payment_tx, location not found, or whether the tool is read-only or has side effects. Some transparency but gaps remain.

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 dense but efficient, with each sentence serving a purpose (purpose, pricing, latency, payment, prefatory advice). It could be better structured (e.g., bullet points) but contains no waste.

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 provides a reasonable overview of return values (confidence-scored alerts, event distribution, etc.). It includes latency and payment context. Missing details on error handling, pagination, or exact return format, but acceptable for a 4-param 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining payment_tx in detail (wallet address, chain) and reiterating tier pricing with examples. This goes beyond schema descriptions, providing meaningful context for parameter usage.

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

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

The description clearly states it is a location threat assessment for specific use cases (risk_underwriting, etc.). It differentiates between lite and full tiers. However, it does not distinguish itself from sibling tools like get_threat_profile or get_threat_sample, leaving the agent to infer differences from 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?

The description advises using browse_catalog first, which provides context. It also details pricing and payment steps. However, it does not specify when to use this tool versus alternatives (e.g., get_threat_profile), nor when not to use it. The guidance is present but incomplete.

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 payment amount, chain, wallet, and that it returns a 5-second sample in the same format as get_bvh. No annotations provided, so description carries full burden; it does well but omits error handling 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?

Single paragraph with clear labeling ('TRIAL —') and all essential info. Could be more structured (e.g., separate payment info), but remains concise 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?

Covers purpose, relationship to get_bvh, payment, and sample format. No output schema, but for a trial tool this is adequate given the clear comparison and payment instructions.

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 descriptions already cover both parameters well (subject with options, payment_tx with instructions). Description adds no additional parameter-level meaning. Baseline 3 due to 100% 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?

Clearly states it's a trial BVH sample, distinguishing from the full get_bvh tool. Verb 'get' is implied, resource is 'TRIAL BVH skeletal sample'.

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 says use to evaluate data quality before committing to the full version, providing clear context. Lacks explicit when-not-to-use, but alternatives are 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?

Discloses trial nature, output format (300 frames @ 60fps NPZ), robot platforms, and payment requirements. No annotations provided, so description carries full burden; covers key 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?

Front-loaded with key purpose ('TRIAL — 5-second robot-trajectory sample'), but the description is lengthy due to payment details. Each sentence is relevant, but could be more concise and 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?

Covers purpose, usage, output format, robot platforms, and payment. Lacks details on error handling or what happens with invalid tx hash. Overall sufficiently complete for a trial 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?

Schema coverage is 100% (baseline 3). Description adds payment instructions and context (e.g., 'Send $0.25 USDC on Base... pass tx hash here') beyond the schema's parameter descriptions, enhancing clarity.

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 identifies the tool as a trial 5-second robot-trajectory sample, distinguishing it from the full-priced sibling 'get_robotarget'. The verb is implied by the name and 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?

States 'use to evaluate retargeting quality before committing' providing clear use case. Lacks explicit when-not-to-use guidance but implies full version as 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?

Despite no annotations, the description discloses key behaviors: returns a 15-min signed streaming URL with Range support, requires a $5 USDC payment on Base to a specific wallet, and mentions Eth/Solana alternative. This adequately informs the agent of side effects and 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?

The description is 4 sentences, covering purpose, output, and payment details. It is slightly verbose but logically sequenced. Could be more concise by separating payment into a step.

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

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

For a tool with no output schema and payment requirements, the description covers core operation but lacks details about URL usage (e.g., how to stream with Range support) and response format. Payment flow is explained but may be confusing for an AI agent.

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 the description enriches parameters: 'view' is contextualized by '1080p synced cameras,' 'payment_tx' is explained with payment instructions, and 'lesson_path' notes a default. This adds value beyond the schema.

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

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

The description clearly states the tool returns a streaming URL for multi-view grappling video, specifying the use cases 'pose_estimation_training or technique_analysis.' It distinguishes from sibling tools like 'get_bvh' or 'get_calibration' by its unique purpose.

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

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

No guidance is given on when to use this tool versus alternatives (e.g., other get_ tools). There is no explicit context for when it is appropriate or inappropriate to use.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns pricing information and is free, but lacks specifics on rate limits, return format, or whether the search is read-only. However, the description adds valuable context beyond what annotations would provide.

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 concise sentences, each adding distinct value: scope of search and key return detail (pricing). No fluff and front-loaded with the 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 3 parameters and no output schema, the description is fairly complete: it explains what is searched, what is matched, and what is returned (full detail + pricing). Missing details like pagination or result limits, but overall adequate 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?

Schema coverage is 100%, so the schema already documents all three parameters. The description adds marginal value by stating it searches across specific datasets and matches labels/paths/subjects/techniques, but this is largely redundant with the schema's description of the query 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 the verb ('search') and the resource ('catalog' across three specific domains). It distinguishes from siblings like 'browse_catalog' by emphasizing full-text matching and return of lesson details with pricing.

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

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

The description implies when to use this tool: when you need to search and then directly call purchase tools. It provides clear context but does not explicitly state when not to use it or list alternatives among the many sibling tools.

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