hw-native-sys

by georgebisbas

Overview Schema Source Related Servers Discussions Admin

Python

Local

explain_abstraction

Explains a stack abstraction by name; if the name matches multiple layers, returns candidates instead of choosing one.

Instructions

Explain a stack abstraction. If the name matches several layers, returns candidates instead of picking one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Abstraction name or alias, e.g. "AIC", "tmov", "TMOV". Use search_abstractions() to discover names.
`layer`	No	Optional card layer or framework prefix, e.g. "ptoas", "pto-isa/instruction", "simpler/scheduler". Required when the same folded name exists in more than one layer.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.2Oct 2, 2026

addedInput schema / properties / layer

Added value: +{
+  "default": "",
+  "description": "Optional card layer or framework prefix, e.g. \"ptoas\", \"pto-isa/instruction\", \"simpler/scheduler\". Required when the same folded name exists in more than one layer.",
+  "title": "Layer",
+  "type": "string"
+}

changedInput schema / properties / name / description

Previous value: -"Abstraction name or alias, e.g. \"AIC\", \"HCCLWindow\", \"Ascend910B\", \"cube\". Use search_abstractions() to discover names."New value: +"Abstraction name or alias, e.g. \"AIC\", \"tmov\", \"TMOV\". Use search_abstractions() to discover names."

First observedv0.1.0Aug 11, 2026

TDQS

A3.5/5.0

Behavior3/5

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 does disclose a genuinely useful behavioral trait — it returns candidates rather than arbitrarily picking a layer — but says nothing about permissions, side effects, or (given the output schema exists) result shape beyond that one edge case.

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

Conciseness4/5

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

Two tight sentences with zero waste; the core purpose is front-loaded and the ambiguity behavior follows immediately. It could be slightly richer without becoming verbose, but nothing is padded.

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

Completeness4/5

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

For a low-complexity two-parameter lookup tool with full schema coverage and an output schema, the description covers purpose and the key ambiguity edge case adequately. The remaining gap is not naming alternatives among the many sibling explain_* tools.

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

Parameters3/5

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

Schema coverage is 100%, so both 'name' and 'layer' are already well documented in the schema with examples and conditional requirements. The description adds no additional parameter meaning, which is the correct baseline when the schema does the heavy lifting.

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

Purpose4/5

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

States a specific verb+resource ('Explain a stack abstraction'), which distinguishes it from siblings like explain_pass or explain_scheduler by scope. However, it does not explicitly contrast itself with search_abstractions or the other explain_* tools in the description body, so an agent must infer the boundary.

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

Usage Guidelines3/5

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

Offers some context: it notes that ambiguous names yield candidates, and the schema points to search_abstractions() for discovery and mandates 'layer' for folded-name collisions. But there is no explicit when-to-use-this vs the sibling explain_* tools, so guidance is only implied.

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