OpenAccountants

Get a skill's sections

get_skill_sections

Read-onlyIdempotent

Fetch the parsed sections of a skill's current version. Each section has a heading and its markdown content. Use this to pull a specific section that get_skill listed in section_index as not inlined (e.g. a supplier-pattern library) — pass section_index to fetch just that one. Omit it to get every section.

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	Yes	Skill slug
`section_index`	No	Optional. Return only this section (matches the `index` from get_skill's `section_index`).
`section_indices`	No	Optional. Return only these sections.

Output Schema

TableJSON Schema

Name	Required	Description
`slug`	Yes
`version`	No
`sections`	Yes
`key_facts`	No	Optional at-a-glance facts — present only where the skill carries a structured key_facts block; omitted otherwise.
`guardrails`	No
`next_action`	No

Schema Changelog

Changes observed during successful MCP inspections.

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

addedInput schema / properties / section_index

Added value: +{
+  "description": "Optional. Return only this section (matches the `index` from get_skill's `section_index`).",
+  "type": "integer"
+}

addedInput schema / properties / section_indices

Added value: +{
+  "description": "Optional. Return only these sections.",
+  "items": {
+    "type": "integer"
+  },
+  "type": "array"
+}

Changed1 schema field changedJun 2, 2026

addedOutput schema / properties / key_facts

Added value: +{
+  "description": "Optional at-a-glance facts — 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": {
+    "sections": {
+      "items": {
+        "properties": {
+          "heading": {
+            "type": "string"
+          },
+          "heading_level": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "markdown_content": {
+            "type": "string"
+          },
+          "section_index": {
+            "type": "integer"
+          }
+        },
+        "required": [
+          "heading",
+          "markdown_content"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "slug": {
+      "type": "string"
+    },
+    "version": {
+      "type": [
+        "integer",
+        "number"
+      ]
+    }
+  },
+  "required": [
+    "slug",
+    "sections"
+  ],
+  "type": "object"
+}

First observedMay 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavior: it returns 'parsed sections' with 'heading and markdown content', and clarifies the 'current version' constraint. It also explains how parameter omission affects the result (all vs. one). This goes beyond annotations without contradicting them.

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?

Two sentences with zero fluff, front-loaded with the core purpose and followed by usage guidance. Every clause earns its place, and the structure makes it easy to scan.

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?

With an output schema present, the return format is already defined. The description covers the main input behaviors (single vs. all sections) and the relationship to get_skill. It does not mention edge cases like invalid indices or empty results, but for a read-only, idempotent tool with clear parameter semantics, this is sufficient. Slightly more detail on `section_indices` could push it to 5.

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%, so each parameter is documented. The description enhances this by explaining the relationship between `section_index` and get_skill's `section_index`, and explicitly states that omitting it fetches all sections. This adds semantic value beyond the schema's bare descriptions, particularly for the `section_index` parameter.

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 clearly states the verb ('Fetch') and resource ('parsed sections of a skill's current version'), and distinguishes it from get_skill by referencing the `section_index` that get_skill provides. An agent can immediately tell this tool retrieves section content, not metadata.

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?

Explicitly explains when to use it (to pull a specific section that get_skill listed as not inlined) and how to control the output (pass `section_index` or omit it). It references the sibling tool get_skill indirectly but doesn't explicitly contrast it for other scenarios (e.g., 'use get_skill for metadata'), so not a full 5.

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.