Skip to main content
Glama
Sign In
Solumbe

Solumbe

by BASHBOP
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Agent Experience (AX)

agent_experience
Read-only

Score a proposed code change from 0–100 for agent cost and safety, then get sub-scores, drivers, and recommendations to improve changeability, containment, guardrails, and clarity.

Instructions

Score Agent Experience (AX): a single 0–100 number answering "how cheap and safe is it for an agent to make this change here?", blending Changeability (token cost), Containment (blast radius), Guardrails (tests / validation / CODEOWNERS / CI), and Clarity (task groundedness). Returns sub-scores, drivers, and concrete recommendations for raising AX.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "agent_experience"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNoNumber of impact files to consider when scoring blast radius. Defaults to 8.
pathNoRepository path. Defaults to current working directory.
queryYesPlain-English change request to score, e.g. "add a new MCP tool".
includeMarkdownNoReturn a compact human-readable markdown report instead of the full JSON. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds real context beyond that: the score blends four named dimensions, blast radius is derived from impact files, and the return includes sub-scores, drivers, and recommendations. It stops short of disclosing analysis cost or which repository data is read, but for a read-only scoring tool this is meaningfully informative.

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?

One dense paragraph, front-loaded with what the tool does and why the score exists. Each clause earns its place, though the four-dimension parenthetical is jargon-heavy and could be easier to scan as a list.

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 read-only scoring tool with full schema coverage and no output schema, the description covers the score's composition and return shape well enough to call it correctly. Minor gaps remain around analysis cost and repository scope, but nothing essential is missing.

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 the schema itself documents all four parameters, including top, path, query, and includeMarkdown. The description only indirectly illuminates 'top' through its mention of blast radius and impact files; otherwise it adds no parameter detail beyond the schema. Baseline 3 is appropriate.

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?

The description states a specific verb and resource ('Score Agent Experience') and defines the composite metric precisely, including its four sub-dimensions. It does not differentiate this from plausible siblings such as convergence_score, review_gate, or change_impact, 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?

Usage is implied by the framing: score a plain-English change request to learn how cheap and safe it is for an agent. There is no explicit when-to-use or when-not guidance, and no sibling tool is named as an alternative, so the agent is left to infer routing.

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

Deploy Server

Other Tools