OpenAccountants

Get a tax skill

get_skill

Read-onlyIdempotent

Fetch a published skill by slug, including its current-version markdown, quality tier, named verifier (where accountant-verified), and a provenance/attribution footer.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes	Skill slug, e.g. 'us-schedule-c-and-se-computation'
`reason`	No	One sentence on WHY you're making this call, in the user's terms (for routing analysis only). Optional.

Output Schema

TableJSON Schema

Name	Required	Description
`skill`	Yes	The skill record (slug, name, jurisdiction, tier, etc.)
`key_facts`	No	Optional at-a-glance facts (rates/thresholds/deadlines/verifier/advisory) — present only where the skill carries a structured key_facts block; omitted otherwise.
`guardrails`	No
`provenance`	Yes
`next_action`	No
`verification`	No	Verification summary
`section_index`	No	Every section of the skill with {index, heading, level, chars, priority, included}. For any section with included:false, fetch it via get_skill_sections({slug, section_index}).
`current_version`	No	Current version. markdown_content holds the compute-core (rates, box maps, rules, worksheet contract); bulky reference sections may be omitted — see section_index.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJul 13, 2026

addedInput schema / properties / reason

Added value: +{
+  "description": "One sentence on WHY you're making this call, in the user's terms (for routing analysis only). Optional.",
+  "type": "string"
+}

Changed1 schema field changedJun 18, 2026

addedOutput schema / properties / provenance / properties / last_verified_at

Added value: +{
+  "description": "When the skill's facts were last verified (decay signal), or null if never.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed2 schema fields changedJun 2, 2026
- addedOutput schema / properties / guardrails
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
- addedOutput schema / properties / next_action
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedJun 2, 2026

changedOutput schema / properties / current_version / description

Previous value: -"Current version incl. markdown_content"New value: +"Current version. markdown_content holds the compute-core (rates, box maps, rules, worksheet contract); bulky reference sections may be omitted — see section_index."

addedOutput schema / properties / section_index

Added value: +{
+  "description": "Every section of the skill with {index, heading, level, chars, priority, included}. For any section with included:false, fetch it via get_skill_sections({slug, section_index}).",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedJun 2, 2026

addedOutput schema / properties / key_facts

Added value: +{
+  "description": "Optional at-a-glance facts (rates/thresholds/deadlines/verifier/advisory) — present only where the skill carries a structured key_facts block; omitted otherwise.",
+  "type": "object"
+}

Changed1 schema field changedMay 24, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "current_version": {
+      "description": "Current version incl. markdown_content",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "provenance": {
+      "properties": {
+        "attribution_required": {
+          "type": "boolean"
+        },
+        "source_url": {
+          "type": "string"
+        },
+        "tier": {
+          "enum": [
+            "accountant-verified",
+            "research-verified"
+          ],
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "skill": {
+      "description": "The skill record (slug, name, jurisdiction, tier, etc.)",
+      "type": "object"
+    },
+    "verification": {
+      "description": "Verification summary",
+      "type": [
+        "object",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "skill",
+    "provenance"
+  ],
+  "type": "object"
+}

First observedMay 20, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context about what the response includes (markdown, quality tier, verifier conditionally, provenance footer), going beyond the annotations to describe the data payload. There is no contradiction with annotations.

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 entire description is a single, information-dense sentence that front-loads the core action ('Fetch a published skill by slug') and then lists the key return elements. There is no wasted language, and the structure is logical and efficient.

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 read-only fetch operation, the description covers all essential aspects: what resource is accessed, how it is identified, and what the caller can expect to receive. An output schema exists, so return structure is already defined externally, and the description's mention of content types is sufficient. No critical missing information for an agent to call this correctly.

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 description coverage is 100%, and both parameters (slug and reason) are documented in the schema. The description merely references 'by slug' which aligns with the schema but adds no extra semantic detail beyond it. The schema already provides an example for slug and a rationale for reason, so the description offers no incremental parameter guidance.

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 starts with a specific verb 'Fetch' and a resource 'published skill by slug', then enumerates the exact content returned (markdown, quality tier, verifier, provenance footer). This clearly distinguishes the tool from siblings like list_skills and search_skills, which list or search across multiple skills.

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 implies the use case: fetching a specific skill by its slug. It makes clear that this is for retrieving a single published skill, which differentiates it from broader list/search tools. However, it does not explicitly mention when to avoid this tool or call a sibling instead, so no exclusion or alternative is named.

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

All OpenAccountants 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.