governance-framework-generator
Server Details
AI governance frameworks for Australian businesses. AI6 practices, Voluntary AI Safety Standard.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 3 of 3 tools scored.
Each tool has a distinct role in a clear sequential workflow: start_session initiates, submit_answers provides data, get_framework produces the output. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case, making the action and target clear: start_session, submit_answers, get_framework.
Three tools precisely cover the required steps for generating a governance framework—no more, no less. The count is well-scoped for the domain.
The tool set covers the entire lifecycle of generating a governance framework: session creation, data submission, and framework retrieval. No obvious gaps exist for the stated purpose.
Available Tools
3 toolsget_frameworkGet the generated frameworkAInspect
Returns the free preview of a tailored AI governance framework for the profiled Australian organisation, covering the first two of Australia's six AI6 practices (Accountability, Impact Assessment) from the Voluntary AI Safety Standard. The result includes a view_url — ALWAYS give this link to the user so they can view, print, or save their complete preview document in a browser. Also present the returned framework text to the user in full and verbatim (rendered as Markdown) — never summarise or excerpt it. The full six-practice framework (adding Risk Management, Transparency & Information Sharing, Testing & Monitoring, Human Oversight) is a one-time $49 AUD purchase at https://aiframework.com.au — there is no payment via this endpoint. The framework is informational only — it presents frameworks, not advice or compliance guidance — and its closing disclaimer must be preserved exactly.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description covers key behaviors: it instructs to present the output fully and preserve the disclaimer, indicates the tool is non-payment, and implies read-only access. It could be improved by explicitly stating idempotency or side-effect freeness.
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 informative but longer than necessary, with repeated instructions to present the output fully. It front-loads the primary purpose but could be streamlined without losing essential guidance.
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?
Despite no output schema, the description adequately describes the return values (view_url and text) and how to handle them. However, it misses the context for the input parameter, which reduces completeness for this 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?
The single parameter `session_id` is not explained in the description. With 0% schema coverage, the description should clarify what `session_id` represents and how to obtain it (e.g., from `start_session`). This is a critical gap.
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 ('returns the free preview') and the specific resource (an AI governance framework for Australian organisations). It also distinguishes the tool from siblings (`start_session`, `submit_answers`) by referencing the profiling process.
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 after profiling ('for the profiled Australian organisation') and explicitly notes that no payment occurs via this endpoint, directing to a paid alternative. It lacks a direct 'when not to use' statement but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_sessionStart a framework sessionAInspect
Begin generating an AI governance framework for an Australian business. Creates a session and returns a session_id plus the organisation profiling questionnaire (industry, size, AI usage, data handling, risk exposure). Ask the user each question, then call submit_answers. First step of three: start_session, submit_answers, get_framework. The output is an informational framework aligned with Australia's AI6 practices (Voluntary AI Safety Standard) — it presents frameworks, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it creates a session, returns specific data, and that the output is informational (not advice). No contradictions, though could mention idempotency or session uniqueness.
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?
Description is front-loaded with purpose, then details output, sequence, and disclaimer. All sentences are informative; no redundancy. Slightly verbose but efficient overall.
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 no parameters and no output schema, the description fully covers what the tool does, its output, and its role in a multi-step process. It is complete for the tool's complexity.
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?
Input schema has 0 parameters (coverage 100%). Description adds no parameter details because none exist. Baseline for zero parameters is 4.
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: 'Begin generating an AI governance framework for an Australian business. Creates a session and returns a session_id plus the organisation profiling questionnaire.' It also distinguishes itself from siblings by being the first of three steps.
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 states the sequence: 'First step of three: start_session, submit_answers, get_framework.' Advises to ask user each question then call submit_answers. Provides clear context on when to use and what follows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_answersSubmit questionnaire answersAInspect
Submit the completed organisation profile for an AI governance framework session. Stores the business's questionnaire answers (industry, size, AI usage, data handling, risk exposure) against the session created by start_session. All questionnaire answers are required, along with contact name, email, and organisation name. Required before calling get_framework. Second step of three.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | Keys are question ids from start_session; values are the selected option (string) or options (array of strings) for multi_select questions. | |
| contact | Yes | ||
| session_id | Yes | From start_session |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It discloses that answers are stored against a session and that all answers and contact info are required, but does not mention idempotency, side effects, or error behavior. Moderate transparency for a submission 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 sentences efficiently cover purpose, constraints, and sequence. Front-loaded with action verb 'Submit' and clearly structured with step context.
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 three parameters with nested objects and no output schema, the description covers purpose, required fields, step ordering, and references sibling tools. Missing return value or error handling, but acceptable for this type of 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 67%, with the description adding context that answers object keys come from start_session and that contact fields are required. This adds some value beyond the schema, but baseline is 3 due to high coverage.
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?
Description clearly states the tool submits completed questionnaire answers for an AI governance framework session, and explicitly distinguishes itself from siblings start_session (first step) and get_framework (third step).
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 specifies that this is the second of three steps and is required before calling get_framework, providing clear sequential context. It also states that all questionnaire answers are required, but does not explicitly exclude alternative usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!