References a GitHub repository for IIA resources through an environment variable (IIA_GITHUB_REPO), allowing the server to potentially sync or version the structured IIA documentation.
Converts IIA resources from HTML to markdown format with proper frontmatter, organizing professional standards and guidance documents for AI consumption.
Required as a runtime environment for the MCP server, listed as a prerequisite (v18+) for running the server that provides access to IIA resources.
Utilized for package management and running scripts to build, scrape content, and start the MCP server providing IIA resources.
Used as the implementation language for the MCP server components, including the scraper and server logic that delivers IIA content.
Parses YAML frontmatter for rich metadata in IIA content, enabling advanced features like relevance scoring and standard number detection.
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., "@IIA-MCP Server validate compliance for cybersecurity audit procedures"
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.
A Model Context Protocol (MCP) server that provides AI assistants with access to Institute of Internal Auditors (IIA) professional standards and resources.
This project creates an MCP server that scrapes IIA resources and formats them as markdown files for easy consumption by AI agents. The server provides comprehensive access to:
IIA Professional Standards (1000 and 2000 series)
Implementation Guidance and IPPF framework
Specialized Topics (cybersecurity, ESG, risk assessment, etc.)
Glossary and Templates
Recent Updates and changes
Related MCP server: Integrator MCP Server
Scraper (scraper.ts) - Web scraping tool that downloads IIA resources
MCP Server (iia_mcp_server.ts) - Serves scraped content via Model Context Protocol
Structured Output - Well-organized markdown files following IIA documentation patterns
Following the structure defined in Structure.txt:
iia-resources/
├── standards/
│ ├── 1000-series/ # Independence and Objectivity
│ ├── 2000-series/ # Performance Standards
│ └── index.md # Standards overview
├── guidance/
│ ├── ippf-framework.md
│ ├── coso-integration.md
│ ├── ethics-code.md
│ └── implementation/ # Detailed guidance
├── topics/ # Specialized audit topics
├── glossary/ # Definitions and acronyms
├── templates/ # Audit templates and tools
└── updates/ # Recent changes and updatesNode.js (v18+)
TypeScript
npm
# Install dependencies
npm install
# Build the project
npm run build# Run the scraper to download and format IIA content
npm run scrapeThis will:
Create the iia-resources/ directory structure
Download IIA content from their website
Convert HTML to markdown with proper frontmatter
Organize files according to the standardized structure
# Start the MCP server
npm start
# Or for development
npm run devEnvironment variables:
IIA_REPO_PATH - Path to IIA resources directory (default: ./iia-resources)
IIA_GITHUB_REPO - Repository reference (default: organization/iia-resources)
Dynamic document serving from markdown files
Categorized access to all IIA content types
Metadata-rich responses with source URLs
search_documents - Search by keywords, standard numbers, or topics
get_standard_details - Retrieve specific standard information
get_related_documents - Find related content for topics
validate_compliance - Check scenarios against IIA standards
get_document_updates - Track recent changes and updates
Content Caching for performance
Relevance Scoring for search results
Standard Number Detection for compliance validation
YAML Frontmatter Parsing for rich metadata
All scraped content includes YAML frontmatter:
---
title: "Standard Title"
url: "https://www.theiia.org/original-url"
category: "standards"
standard_number: "1100"
last_updated: "2024-01-15T10:30:00Z"
scraped_at: "2024-07-15T12:00:00Z"
---
# Content starts here...TypeScript with strict type checking
Async/await patterns throughout
Error handling and retry logic
Respectful scraping with rate limiting
This MCP server enables AI assistants to:
Reference IIA Standards accurately in audit guidance
Validate Compliance scenarios against official standards
Search Documentation by topic, keyword, or standard number
Stay Current with the latest IIA updates and changes
Access Templates for audit programs and reports
This project is designed for research and educational purposes, providing structured access to public IIA resources for academic study and professional development in internal auditing.
MIT License - See LICENSE file for details.
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
For issues and questions:
Check existing GitHub issues
Create new issues with detailed descriptions
Include error logs and environment details
Check for recent updates to IIA documents
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category | |
| since | No | ISO date string to check for updates since |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('Check for recent updates') without explaining any behavioral traits like what 'recent' means, if there are rate limits, authentication needs, or how updates are determined. This leaves significant gaps in understanding the tool's operation.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 complexity (checking updates with parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'updates' entail, the return format, or any behavioral context, leaving the agent with insufficient information to fully utilize the 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?
The input schema has 100% description coverage, clearly documenting both parameters ('category' with enum values and 'since' as an ISO date). The description adds no additional meaning beyond this, as it doesn't elaborate on parameter usage or constraints. This meets the baseline score when schema coverage is high.
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 purpose with a specific verb ('Check') and resource ('recent updates to IIA documents'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_related_documents' or 'search_documents', which might also involve document retrieval, so it doesn't achieve full 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, exclusions, or comparisons to sibling tools such as 'search_documents' or 'get_standard_details', leaving the agent with no usage instructions beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific IIA standard
| Name | Required | Description | Default |
|---|---|---|---|
| standardNumber | Yes | IIA standard number (e.g., "2010", "1100") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It implies a read-only operation ('Get') but doesn't address permissions, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this is insufficient behavioral context.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage guidelines, behavioral traits, and output, which would be needed for higher completeness in a real-world scenario.
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 100% description coverage, fully documenting the single parameter 'standardNumber' with examples. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 where the schema does the heavy lifting.
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 purpose with a specific verb ('Get') and resource ('detailed information about a specific IIA standard'), making it immediately understandable. However, it doesn't differentiate this tool from its siblings (like 'get_document_updates' or 'get_related_documents'), which would require explicit comparison to achieve a perfect score.
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 doesn't mention prerequisites, appropriate contexts, or exclusions, leaving the agent to infer usage from the tool name alone. This lack of explicit guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search IIA documents by keywords, standard numbers, or topics
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category (standards, guidance, topics, glossary) | |
| limit | No | Maximum number of results to return | |
| query | Yes | Search query (keywords, standard number, or topic) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It mentions what can be searched (keywords, standard numbers, topics) but doesn't describe how results are returned, whether there's pagination, authentication requirements, rate limits, or what happens with no matches. For a search tool with zero annotation coverage, this is inadequate.
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, efficient sentence that directly states the tool's function without any unnecessary words. It's appropriately sized and front-loaded with the core purpose.
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 complexity (search functionality with 3 parameters) and lack of both annotations and output schema, the description is incomplete. It doesn't explain return values, result format, error conditions, or behavioral constraints, leaving significant gaps for an AI agent to understand how to properly use this 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%, so the schema already fully documents all three parameters (query, category, limit). The description adds marginal value by listing searchable content types (keywords, standard numbers, topics) which aligns with the query parameter, but doesn't provide additional syntax or format details beyond what the schema provides.
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 purpose as searching IIA documents with specific search criteria (keywords, standard numbers, or topics). It uses a specific verb ('search') and identifies the resource ('IIA documents'), but doesn't distinguish it from sibling tools like 'get_related_documents' or 'get_standard_details' which might also retrieve document information.
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 doesn't mention when to choose search_documents over sibling tools like get_related_documents or get_standard_details, nor does it specify any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check compliance against IIA standards and provide recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| scenario | Yes | Audit scenario or situation to validate | |
| standardsToCheck | No | Specific standards to check against (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'check' and 'provide recommendations,' implying a read-only analysis, but doesn't specify if this involves data mutation, requires authentication, has rate limits, or details the output format. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 concise and front-loaded in a single sentence, with no wasted words. It efficiently communicates the core purpose, but could be slightly improved by adding minimal context to enhance clarity without losing brevity.
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 complexity of compliance checking, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'recommendations' entail, how results are returned, or any behavioral traits like error handling. This leaves gaps for an AI agent to understand the tool's full context.
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 (scenario and standardsToCheck) adequately. The description adds no additional meaning beyond what the schema provides, such as examples or context for parameter usage. Baseline 3 is appropriate when the schema does the heavy lifting.
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 purpose with a specific verb ('Check compliance') and resource ('against IIA standards'), and it includes an outcome ('provide recommendations'). However, it doesn't differentiate this tool from its siblings (e.g., get_standard_details, search_documents), which might also relate to compliance or standards, so it doesn't reach a score of 5.
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 its siblings (e.g., get_standard_details for details on standards, search_documents for document searches). It lacks explicit when-to-use or when-not-to-use instructions, and there are no prerequisites or alternatives mentioned, leaving usage context unclear.
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.0get_document_updatesget_related_documentsget_standard_detailssearch_documentsvalidate_complianceScored across 5 tools
Each tool has a clearly distinct purpose: get_document_updates focuses on recent changes, get_related_documents finds topic-based associations, get_standard_details provides standard-specific information, search_documents performs keyword-based retrieval, and validate_compliance assesses adherence to standards. There is no overlap or ambiguity in their functions.
All tool names follow a consistent verb_noun pattern using snake_case, starting with verbs like 'get', 'search', or 'validate' followed by descriptive nouns. This uniformity makes the tool set predictable and easy to understand.
With 5 tools, the server is well-scoped for its IIA document and standards management purpose. Each tool serves a specific, necessary function without redundancy, making the count appropriate for the domain.
The tool set covers key operations like retrieval (search, get details/updates/related documents) and compliance validation, supporting core workflows. A minor gap is the lack of tools for modifying or creating documents, but this may be intentional if the server is read-only.
AI governance MCP server for EU AI Act compliance and jurisdiction verification
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.