Provides queryable access to Sage Intacct REST API documentation, enabling AI assistants to search endpoints, browse schemas, generate example payloads, and check documentation quality.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@intacct-docs Generate an example payload for creating a vendor."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants queryable access to Sage Intacct REST API documentation. Load one or more OpenAPI specs and let your LLM search endpoints, browse schemas, generate example payloads, and check documentation quality — all without leaving the conversation.
1. Install
npm install -g @rowellewis/intacct-docs-mcpOr run without installing:
npx @rowellewis/intacct-docs-mcp2. Add to Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"intacct-docs": {
"command": "npx",
"args": ["-y", "@rowellewis/intacct-docs-mcp"],
"env": {
"SPEC_DIR": "/path/to/your/specs"
}
}
}
}Omit SPEC_DIR to use the bundled Sage Intacct spec.
3. Try it
"Search for endpoints related to accounts payable vendors." "Show me the request body schema for POST /objects/accounts-payable/vendor." "Generate an example payload for creating a journal entry."
Related MCP server: mcp-swagger
Tool | What it does |
| Fuzzy full-text search across paths, summaries, and descriptions. Supports multi-word queries and typo tolerance. |
| Full documentation for a specific endpoint — parameters, request/response schemas, examples. |
| Schema definition with all properties, types, and constraints. |
| Browse available schema names, filterable by prefix. |
| All API tags/categories with endpoint counts. |
| All endpoints under a specific tag. Use |
| Generates a realistic JSON request body for any endpoint, inferred from its schema. |
| Scores documentation quality (0–100) and lists issues by severity. |
| Readiness status, index counts, and startup timing. |
Full parameter reference, error codes, and examples: docs/public-contract.md.
Variable | Default | Description |
|
| Directory scanned for |
|
|
|
|
| Port when using HTTP transport |
|
| Bind address for HTTP transport ( |
|
| Response size cap — output is truncated with a notice when exceeded |
|
|
|
|
| Maximum HTTP request body size in bytes |
|
| Max requests per minute per IP (HTTP transport) |
npm install
npm run build # compile TypeScript
npm run dev # watch mode with tsx
npm test # run all testsNode.js >=18 required.
Project layout:
src/
├── app.ts # tool registry and handlers
├── config.ts # env vars → AppConfig
├── index.ts # entry point, transport selection
├── core/
│ ├── indexer.ts # in-memory indexes + fuzzy search
│ ├── formatter.ts # markdown response formatting
│ ├── fuzzy.ts # trigram similarity matching
│ ├── example-generator.ts
│ ├── validate.ts
│ ├── cache.ts
│ └── spec-quality.ts
└── transport/
├── http-server.ts # MCP Streamable HTTP transport + GET /health
└── stdio.ts # MCP stdio wrapperTests use Vitest.
HTTP transport (MCP Streamable HTTP — for URL-based MCP clients):
TRANSPORT=http HTTP_PORT=3000 npm startHealth: call the health tool — returns readiness, index counts, and startup duration. Or hit GET /health when running in HTTP mode.
Logs: structured JSON on stderr. Adjust verbosity with LOG_LEVEL.
Runbook: docs/ops-runbook.md
Server won't start — verify SPEC_DIR contains at least one *.openapi.yaml file, then run npm run build and check stderr.
Endpoint not found — use search-endpoints to discover paths. Methods must be uppercase (GET, POST, …).
Schema not found — use list-schemas with an optional prefix to browse what's available. Names are case-sensitive.
MIT
Generate an example JSON request body for an API endpoint. Example: method="POST", path="/objects/accounts-payable/vendor"
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | API endpoint path | |
| method | Yes | HTTP method |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states the action but does not mention whether the example is generated based on the endpoint's schema, if any authentication or prerequisites are needed, or what the output looks like. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a concrete example, front-loading the purpose. Every word is functional, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two required parameters and no output schema, the description is adequate for an agent to call the tool correctly. It could add context about the source of the example (e.g., based on the endpoint's schema) but is not severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description's example reinforces their usage but does not add semantic information beyond the schema's own descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Generate) and resource (example JSON request body for an API endpoint) with a concrete example. It differentiates from siblings like get-endpoint-docs or get-schema, which retrieve documentation or schemas rather than generate examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its example but does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks any mention of conditions or exclusions, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete documentation for a specific API endpoint including parameters, request/response schemas, and examples. Example: method=GET, path=/objects/general-ledger/account/{key}
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | API endpoint path (e.g., /objects/general-ledger/account/{key}) | |
| method | Yes | HTTP method |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It indicates a read operation ('Get') and describes the return content, but does not explicitly state that it is side-effect free, or mention error behavior, authentication, or rate limits. It is adequately transparent for a read-only tool, though not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a concrete example, front-loading the purpose and listing deliverables. No filler or redundant wording exists; every element contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description clearly explains the return contents (parameters, schemas, examples) and provides a usage example. It does not address error handling or edge cases, but these are not critical for a documentation retrieval tool, making it adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters. The description adds no additional semantic value beyond the example, which essentially repeats the schema's example for 'path'. Since the schema covers parameter meaning, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get complete documentation for a specific API endpoint' and enumerates the contents (parameters, request/response schemas, examples). This verb+resource structure distinguishes it from siblings like search-endpoints or get-schema, which target different actions or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific endpoint's documentation is needed, but it does not explicitly contrast with alternative tools like search-endpoints or get-schema, nor does it state when not to use it. The provided example reinforces the expected inputs but offers no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all API endpoints for a specific tag/category. Use list-tags first to see available tags. Example: tag="Accounts Payable"
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name (exact match, case-sensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool retrieves all endpoints for a tag, implying a read-only operation, but does not disclose possible pagination, return format, or performance implications. This is a minor gap for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an example, with zero filler. The core action is front-loaded and the prerequisite instruction is immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description covers the prerequisite, provides an example, and the tool name clarifies the returned resource. It does not describe the output structure, but no output schema exists and the meaning of 'endpoints' is reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already provides exact-match and case-sensitivity details. The description adds an example and the tag/category framing but does not significantly extend the schema's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all API endpoints') scoped to a tag/category, which clearly differentiates it from siblings like search-endpoints or get-endpoint-docs. The example tag further anchors the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to call list-tags first to discover available tags, which is a clear prerequisite. It does not mention alternatives or when not to use this tool, but the context is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed schema definition including all properties, types, and constraints. Example: schemaName=general-ledger-account
| Name | Required | Description | Default |
|---|---|---|---|
| schemaName | Yes | Name of the schema (e.g., general-ledger-account) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It states the returned content but does not explicitly declare read-only behavior, error cases, or response format. Acceptable for a simple retrieval tool, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence plus a concrete example. The action and result are front-loaded with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter and no output schema, the description adequately specifies what the agent will receive (properties, types, constraints) and how to call it. It lacks explicit details about edge cases or output structure, but is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents schemaName with a full description and example at 100% coverage. The description's example adds little beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies a specific verb ('Get'), resource ('schema definition'), and content ('all properties, types, and constraints'). It does not explicitly contrast with sibling tools like list-schemas, but 'detailed schema definition' implies a distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is clear: call this when you need the full schema definition. It does not explicitly state when to avoid it or mention alternatives such as list-schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report readiness status and index statistics. Useful for readiness probes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses the core behavior—reporting readiness status and index statistics—but does not describe side effects, return format, status codes, or failure behavior. For a simple health tool this is acceptable but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The primary function is front-loaded, and the use case ('readiness probes') is stated in a second short sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and simple tool purpose, the description is nearly complete: an agent can invoke the tool without further input details. The lack of any return-format or response semantics is a minor gap, but not critical for a health/readiness probe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there are no parameters to document. Per the baseline for zero-parameter tools, the description does not need to add parameter semantics, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Report') and resource ('readiness status and index statistics'), which directly corresponds to the tool name 'health'. It is not a tautology and is distinct from sibling documentation/search tools, though it doesn't explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes 'Useful for readiness probes', giving a concrete use case. It does not name alternatives or exclusion conditions, but the sibling tools are clearly different in purpose, so the context is sufficient for an agent to know when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available schema names, optionally filtered by prefix. Example: prefix="general-ledger"
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | Limit results to a specific spec name. Omit for all specs. | |
| limit | No | Maximum number of schemas to return (default: 50) | |
| prefix | No | Filter schemas whose name starts with this prefix (case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, but it only states the core listing/filtering behavior. It does not mention the spec filter, limit behavior, or what a caller should expect for empty results or errors. There is no contradiction, but disclosure is sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence followed by one illustrative example; there is no filler or repeated schema content. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with a fully self-documenting input schema, the description is nearly sufficient. The only notable omission is that the spec filter is present in the schema but not surfaced in the tool description, so agents relying on the description alone could miss a relevant option.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds a concrete example for prefix but does not clarify spec or limit beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('available schema names'), making the tool's function immediately clear. The phrase 'all available' plus optional prefix filtering distinguishes it from detail-retrieval siblings like get-schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose list-schemas over alternatives such as get-schema or search-endpoints, and no exclusions or when-not conditions are stated. The purpose implies a use case, but the description stops short of providing routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all API tags/categories with endpoint counts.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | Limit results to a specific spec name. Omit to list all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add value by specifying that the output includes 'endpoint counts' beyond just a plain tag list. However, it does not describe other behaviors such as pagination, ordering, or what happens when the optional 'spec' parameter is provided, leaving some behavior to inference from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It immediately states what the tool does and includes the key output detail (endpoint counts). Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is fairly complete. It names the resource and an important output characteristic. However, since there is no output schema, the description could have clarified the return format or clarified that omitting 'spec' is required to list all, but these are minor gaps for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, 'spec', has a clear description in the input schema. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List all API tags/categories with endpoint counts.' This clearly distinguishes it from siblings like get-endpoints-by-tag (which takes a tag and returns endpoints) and list-schemas (which lists schemas, not tags). An agent can immediately understand what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention when to choose list-tags over get-endpoints-by-tag or list-schemas, nor does it provide context about prerequisites or exclusions. The only implied usage is derived from the purpose itself, which is not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for API endpoints by path, operation ID, summary, or description keywords. Supports fuzzy matching and multi-word queries. Example: query="create invoice" limit=5
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | Limit results to a specific spec (e.g., "intacct", "general-ledger"). Omit to search all. | |
| limit | No | Maximum number of results to return (default: 10, max: 100) | |
| query | Yes | Search term(s) to match against endpoint paths, summaries, descriptions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses 'Supports fuzzy matching and multi-word queries' and gives an example, which adds behavioral insight. However, it does not mention the return format, pagination behavior, or any prerequisites like authentication. The lack of an output schema amplifies this gap, but the description does cover some core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences followed by an example. The purpose is front-loaded, and the example clarifies usage without excess. Every sentence contributes useful information, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description lacks a description of the return structure. It implies results are endpoints but doesn't specify whether it returns full details, IDs, or summaries. This is a notable gap for an agent that needs to interpret results. However, the core search behavior and parameters are covered, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly listing 'path, operation ID, summary, or description keywords' as matchable fields (the schema only mentions paths, summaries, descriptions) and provides a concrete example with query and limit usage. This enriches parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for API endpoints by path, operation ID, summary, or description keywords.' It uses a specific verb and resource, and the mention of 'operation ID' adds precision beyond the schema. While it doesn't explicitly differentiate from siblings like get-endpoints-by-tag, the scope (keyword search across all endpoints) is evident from the phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It gives an example of usage but does not mention when to prefer this over get-endpoints-by-tag or list-tags. There are no exclusions or context cues for selection, leaving the agent to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze OpenAPI spec documentation quality. Returns a score and list of issues.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | Limit analysis to a specific spec name. | |
| limit | No | Max number of issues to return (default: 50) | |
| severity | No | Minimum severity to include (default: "warning") | warning |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that a score and issue list are returned, but it does not mention read-only behavior, score range, issue categories, severity handling, or limits. The behavioral picture is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, front-loading the primary action and then the return value. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and three optional parameters, the description is too sparse. It omits what the score range is, what kinds of issues are reported, how severity and limit apply, and when a caller should prefer this over sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already documented including defaults, constraints, and enum values. The description adds no parameter-specific meaning, but the schema already carries that weight, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as analyzing OpenAPI spec documentation quality and returning a score with issues, which differentiates it from sibling tools like get-endpoint-docs and search-endpoints. It is not a tautology, though the exact notion of 'quality' is left somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or preconditions. The agent must infer from the name and schema that this is for quality assessment, which is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0generate-exampleget-endpoint-docsget-endpoints-by-tagget-schemahealthlist-schemaslist-tagssearch-endpointsspec-quality-reportScored across 9 tools
Each tool has a distinct focus: endpoint docs, endpoint search, schema retrieval, tag/schema listings, example generation, health, and spec quality. There is minor overlap between search-endpoints and get-endpoints-by-tag, and between get-endpoint-docs and generate-example, but descriptions make the differences clear.
Most tool names consistently follow a verb_noun pattern with lowercase hyphenation, such as get-endpoint-docs, list-tags, and search-endpoints. A few exceptions like health and spec-quality-report break the pattern slightly, but the overall style is predictable and readable.
Nine tools is an appropriate size for a documentation server. The toolset covers discovery, retrieval, schema access, example generation, and operational health without feeling bloated or sparse.
The toolset provides a complete workflow for API documentation consumers: discovering endpoints, retrieving endpoint details, exploring schemas, listing categories, and generating examples. The addition of health and spec-quality-report tools extends the surface sensibly rather than leaving obvious gaps.
Provide AI assistants with real-time access to official SEC EDGAR filings and financial data. Enab…
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Connect Exact Online accounting to Claude, ChatGPT and Copilot. 114 tools, OAuth 2.1, EU-hosted.
Give AI agents 30,000+ safe, token-optimized actions across Workday, SAP, Oracle + hundreds more.
