Skip to main content
Glama

trw_profile_explain

Explain which layer contributed each field value in a resolved profile, showing the full override chain across 6 layers including defaults, org, domain, task-type, session, and client.

Instructions

Explain the resolved profile's per-field layer attribution.

Use when:

  • A surprising ceremony/review/build-check gate fires and you need to see WHICH layer contributed the offending value.

  • Auditing the policy in force for the session (NIST 24h reconstruction).

Resolves the full 6-layer chain (defaults → org → domain → task-type → session → client) and reports, for every surface field, its effective value, the origin layer, and the full override chain.

Input (all optional — inferred when omitted):

  • domain: override the inferred domain layer (e.g. frontend).

  • task_type: override the inferred task-type layer (e.g. bugfix).

  • prd_path: PRD/file path used to infer the domain when not explicit.

  • task_name: task name used to infer the task-type when not explicit.

Output: dict with fields (list of {field, value, origin_layer, override_chain}), layers_applied, surface_snapshot_id, session_override_hash, and resolved_profile. On error: a {error: str} payload (fail-open, never raises).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNo
prd_pathNo
task_nameNo
task_typeNo
Behavior5/5

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

With no annotations, the description fully discloses behavior: it resolves a 6-layer chain, reports per-field attribution with override chain, and on error returns a fail-open payload (never raises). This transparently covers the tool's operational characteristics.

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

Conciseness5/5

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

The description is well-structured: a clear opening statement, separate 'Use when' section, input list, and output definition. No unnecessary words; all sentences add value. It is concise yet comprehensive.

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

Completeness5/5

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

Given the absence of annotations and output schema, the description fully covers input parameter semantics, output structure (dict with fields, layers_applied, etc.), and error behavior. It is complete for an agent to use correctly.

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

Parameters5/5

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

Despite 0% schema description coverage, the description explains each parameter's purpose (e.g., 'override the inferred domain layer'), their optionality, and hints at values (e.g., 'frontend'). This adds significant meaning beyond the bare schema.

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

Purpose5/5

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

The description explicitly states the tool's function: 'Explain the resolved profile's per-field layer attribution.' It uses a specific verb ('explain') and resource ('resolved profile's per-field layer attribution'), and details the output (effective value, origin layer, override chain). This clearly distinguishes it from sibling tools, which cover other aspects of the trw ecosystem.

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

Usage Guidelines5/5

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

The description provides two explicit use cases: 'when a surprising ceremony/review/build-check gate fires' and 'when auditing the policy in force for the session.' It also notes that all inputs are optional and inferred when omitted, guiding the agent on when to override defaults. No when-not guidance is given, but the specificity is sufficient.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wallter/trw-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server