agenttune

Get questionnaire availability and specification

get_test_spec

Read-only

Fetch a complete questionnaire specification for mbti (32 items), enneagram (36), disc (16), attachment (36) or big-five (50). All five are available, with exact instrument/version IDs, response anchors and strict scoring instructions. The first four preserve the legacy AgentTune adaptations; instrument-specific source terms apply. Administer only when requested, keep responses local, preserve ties, and let users review any suggested communication preferences before installation.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`test`	Yes	Which test instrument.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`body`	Yes
`test`	Yes
`status`	Yes
`revision`	Yes
`available`	Yes
`markdown_url`	Yes
`canonical_url`	Yes
`instrument_id`	Yes
`evidence_status`	Yes
`instrument_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 26, 2026

addedOutput schema / properties / available
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / instrument_id

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / instrument_version

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "test",
-  "canonical_url",
-  "markdown_url",
-  "body",
-  "revision",
-  "evidence_status"
-]New value: +[
+  "status",
+  "available",
+  "instrument_id",
+  "instrument_version",
+  "test",
+  "canonical_url",
+  "markdown_url",
+  "body",
+  "revision",
+  "evidence_status"
+]

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "body": {
+      "type": "string"
+    },
+    "canonical_url": {
+      "type": "string"
+    },
+    "evidence_status": {
+      "type": "string"
+    },
+    "markdown_url": {
+      "type": "string"
+    },
+    "revision": {
+      "type": "string"
+    },
+    "test": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "test",
+    "canonical_url",
+    "markdown_url",
+    "body",
+    "revision",
+    "evidence_status"
+  ],
+  "type": "object"
+}

First observedJun 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses important behavioral expectations: preserving legacy AgentTune adaptations, applying instrument-specific source terms, keeping responses local, preserving ties, and requiring user review before installation. This adds meaningful operational context that annotations alone do not provide.

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?

The description is front-loaded with the primary action and resource, then adds necessary detail about instrument-specific behavior and usage constraints. It is slightly dense with multiple clauses, but every sentence contributes useful information without redundancy.

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?

For a single-parameter read-only tool with an output schema, the description covers what the tool returns, which instruments are available, important behavioral rules, and prerequisites for use. Nothing essential for an agent to invoke this tool correctly is missing.

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?

Schema coverage is 100% and the parameter description already documents the enum. The tool description adds value by specifying item counts per instrument, noting the legacy adaptations for the first four, and indicating that exact IDs and scoring instructions are included in the result. This goes beyond the schema's minimal 'Which test instrument.'

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 opens with a specific verb and resource: 'Fetch a complete questionnaire specification' and enumerates the exact instruments (mbti, enneagram, disc, attachment, big-five) with item counts. This clearly distinguishes it from sibling tools like list_resources or get_tuning, which focus on different resources.

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 provides clear context by stating 'Administer only when requested' and instructs on how to handle responses and user preferences. It does not explicitly name alternative tools or when-not-to-use conditions relative to siblings, but the usage context for this specific tool is sufficiently clear.

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

All agenttune tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.