Drafts a short AI use policy for a small business from eight questions. Free, answers not stored. Built by IG Digital Lab, Sacramento.
Scored across 2 tools
The two tools have clearly distinct roles: one returns the questionnaire, the other consumes its answers to produce the draft. The descriptions explicitly state the order of use, leaving no realistic chance of misselection.
Both names follow a consistent snake_case verb_noun pattern (get_policy_questions, draft_ai_use_policy). The verbs are distinct and descriptive of the action performed.
Two tools is below the typical 3-15 range, but the server's scope is a single narrow workflow (fetch questions, then generate a fixed-template draft), so each tool clearly earns its place. It is slightly minimal but not thin in a harmful way.
The core workflow is fully covered end to end: questionnaire retrieval and policy draft generation, with placeholders for omitted answers and a listed summary of gaps. Minor gaps exist around revising/regenerating a draft or validating answer formats, but these are workable given the server explicitly stores nothing.
Builds a short AI use policy draft in Markdown (ten sections, about two pages) from the answers to get_policy_questions: purpose, scope, approved tools, data rules (what never goes into free or unapproved AI tools), allowed and prohibited uses, human review of AI output, approval of new tools, incident reporting and a review date. It is a fixed template filled with the answers: no AI model is called, there is no network access, and this server does not store or log the answers. Only company_name is required. Every other answer left out becomes a bracketed placeholder in the draft, and the result lists them. Ask the person for the answers, do not invent them. Optional effective_date (YYYY-MM-DD) defaults to today (UTC). The output is a draft for internal use, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ai_tools | No | Which AI tools does the team use or plan to use? Name the product and, if you know it, the plan. | |
| approver | No | Who approves new AI tools and receives incident reports? A role or a name. | |
| industry | No | What industry or kind of work is it? | |
| allowed_uses | No | What may people use AI for? One use per entry. | |
| company_name | Yes | What is the company's name? | |
| data_handled | No | What kinds of non-public data does the team handle? The policy already covers client confidential information, personal data and credentials; add anything else. | |
| effective_date | No | Date the policy takes effect, YYYY-MM-DD. Defaults to today (UTC). | |
| review_cadence | No | How often will the policy be reviewed? | |
| prohibited_uses | No | What is off limits beyond the standard rules? One item per entry. |
| Name | Required | Description |
|---|---|---|
| disclaimer | Yes | |
| placeholders | Yes | Parts of the draft still to be filled in or checked. |
| effective_date | Yes | |
| policy_markdown | Yes | The policy draft, Markdown. |
| next_review_date | Yes | Null when review_cadence was not given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), it discloses that no AI model is called, no network access occurs, and answers are neither stored nor logged — meaningful trust and privacy context. It also sets expectations that the output is a fixed-template draft, not legal advice, and that omissions surface as bracketed placeholders.
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?
Purpose, inputs, defaulting behavior, and disclaimers are front-loaded in a dense block with no filler sentences. The downside is that it reads as one long run-on paragraph, making the gathering instructions harder to scan than a short bulleted structure would.
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 nine-parameter templating tool with an output schema, the description covers everything an agent needs: source of inputs, required vs optional, default handling, placeholder behavior, and the nature of the returned draft. Return-value detail is rightly delegated to the output schema.
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 already 100%, so parameters are documented, but the description adds operational meaning: only company_name is required, omitted answers become placeholders, and effective_date defaults to today (UTC). It does not restate the enum or item limits, which the schema already carries.
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 names a specific verb and artifact ("Builds a short AI use policy draft in Markdown"), states its size and structure (ten sections, about two pages), and explicitly derives its input from the sibling tool get_policy_questions, so an agent can tell exactly what this produces and how it differs from the sibling.
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 states the precondition (answers collected via get_policy_questions), the only required input (company_name), the behavior for missing answers (bracketed placeholders, listed in the result), and an explicit prohibition ("Ask the person for the answers, do not invent them"). That routes an agent correctly with no inference needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the short questionnaire behind draft_ai_use_policy: eight questions for a small business (company name, industry, AI tools in use, kinds of data the team handles, allowed uses, prohibited uses, who approves new tools, review cadence). Each question has an id, plain wording, type, limits and an example. Call this first, ask the person the questions, then pass their answers to draft_ai_use_policy. Takes no arguments, makes no network calls, stores nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| purpose | No | |
| howToUse | No | |
| nextTool | No | |
| questions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description reinforces this with 'takes no arguments, makes no network calls, stores nothing,' which is partly redundant with openWorldHint/readOnlyHint but usefully reassures the agent before it prompts a human for sensitive company data. It also previews the per-question fields, though the output schema already carries that.
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 plus a workflow clause; the scoping statement comes first and nothing is padding. The long parenthetical list of eight question topics is dense but earns its place by letting the agent preview the interview, though it makes the sentence harder to scan.
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 an output schema present, the description need not document return values, and annotations cover the safety profile. What remains — what the tool is for, how it fits with draft_ai_use_policy, and that it is side-effect free — is all stated.
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 tool takes zero parameters, which is the baseline-4 case, and the description confirms it explicitly with 'Takes no arguments' rather than leaving the agent to infer it from an empty 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?
States a specific verb and resource ('Returns the short questionnaire behind draft_ai_use_policy') and immediately enumerates the eight topics covered, so an agent knows exactly what it gets. It is unambiguously distinct from the sibling draft_ai_use_policy, which consumes the answers rather than producing the questions.
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?
Gives an explicit ordered workflow: 'Call this first, ask the person the questions, then pass their answers to draft_ai_use_policy.' The alternative sibling is named and the condition selecting it is spelled out, leaving nothing to inference.
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.
draft_ai_use_policyget_policy_questions
Add one secure layer between your agents and this server.