Agent Workspace Practice

Score an agent workspace or an organisation

assess_workspace

Score an agent workspace across six dimensions: canonical knowledge, memory and context economics, verification and oversight, safety and permissions, telemetry and cost, provenance and delegation. Two variants: "practitioner" takes 18 answers (a single operator's workspace), "org" takes 12 (an organisation's agent readiness). Each answer is an integer 0-3 in question order, where 0 is the least mature option offered and 3 the most. Returns per-dimension scores, an overall percentage, a maturity band, and the two weakest dimensions with the gap that matters there. The question text lives at https://jamesross.ai/tools/maturity-check (practitioner) and https://jamesross.ai/tools/agent-readiness (org). Read it before answering on someone's behalf.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`answers`	Yes	Answers in question order: 18 integers for "practitioner", 12 for "org". Each is 0-3.
`variant`	Yes	"practitioner" for the 18-question workspace check, "org" for the 12-question organisational readiness check.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and discloses the scoring dimensions, the 0-3 answer semantics, and the full return payload (per-dimension scores, overall percentage, maturity band, weakest dimensions). It also flags the external source of the questions as a prerequisite. This is transparent and complete for a stateless scoring tool.

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 dense but well organized: purpose, variants, answer format, return shape, and prerequisite reading all appear in sequence with no filler. Every sentence contributes necessary invocation information.

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?

The tool has no output schema and no annotations, yet the description names every returned component and the input constraints, including the external question URLs. It also covers the nuance of answering on someone's behalf by directing to the source text. Nothing essential is omitted.

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

Parameters4/5

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

The input schema already covers both parameters fully (100% coverage), earning a baseline of 3. The description adds the exact expected array lengths for each variant, the meaning of 0-3 as least-to-most mature, and the requirement that answers be in question order, plus links to the source questions. That extra context justifies a 4.

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 opens with a clear verb and resource: 'Score an agent workspace across six dimensions', listing the dimensions and the two variant modes. This makes the tool's purpose unambiguous, though it does not explicitly differentiate from sibling tools, whose names are clearly unrelated.

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

Usage Guidelines4/5

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

The description explicitly distinguishes the two variants ('practitioner' takes 18 answers, 'org' takes 12) and tells the agent to read the linked question text before answering. It provides clear context for how to invoke the tool, though it does not discuss alternative tools or exclusion conditions.

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

All Agent Workspace Practice tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation4/5

Most tools target clearly distinct functions: assessment, redaction checking, context pricing, capability requests, and search. The only potential confusion is between lookup_pattern and search_architecture, but their descriptions clearly differentiate scope — narrower pattern lookup versus full-text corpus search.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb_noun pattern: assess_workspace, check_redaction, lookup_pattern, price_context_read, request_capability, search_architecture. There is no mixing of naming conventions or vague verbs.

Tool Count5/5

Six tools is a well-scoped count for this server's purpose. Each tool represents a distinct capability within the agent workspace practice domain, and none feel redundant or superfluous.

Completeness4/5

The set covers the core workflows: maturity assessment, knowledge search, pattern lookup, context cost analysis, and feedback on missing capabilities. A minor gap is the lack of a dedicated tool to read or list full resources, though this is partially mitigated by the resources exposed under the architecture:// scheme.

Resources

Need Help?