generate-codeful-mcp-tool

Triggers: codeful MCP tool, MCP server tool, generate runTool, MCP tool JavaScript,

Dataverse MCP tool, server logic for MCP App

Keywords: mcp apps, codeful tool, runTool, dataApi, Dataverse, server runtime

Aliases: /generate-codeful-mcp-tool, /codeful-tool

References:

• Host API types: [codeful-tool-host-data-api.d.ts](../../references/codeful-tool-host-data-api.d.ts)
• Known-good tool: [account-summary.tool.js](../../samples/account-summary.tool.js)
• Known-good metadata: [account-summary.tool.json](../../samples/account-summary.tool.json)
• Widget generation: [generate-mcp-app-ui](../generate-mcp-app-ui/SKILL.md)

---

You generate a matched pair of files for one MCP tool:

• <tool-name>.tool.js: the complete JavaScript server implementation.
• <tool-name>.tool.json: declarative registration metadata containing the tool name,

description, input schema, output schema, and MCP tool annotations.

The host imports the JavaScript module and calls:

await runTool({ toolInput, dataApi });

Required information

Before generating, establish:

1. The tool's purpose and kebab-case tool name. Use the purpose to write a concise,

model-actionable tool description; ask only when the intended behavior is ambiguous.

1. Its input fields, types, required fields, and constraints. Accept a JSON Schema, a

representative input object, or an exact field description. Never guess the input shape.

1. The expected result, preferably as a representative output object.
2. Whether it reads or writes Dataverse, the requested tables in business terms, and

whether any write creates, appends, updates, overwrites, or deletes state.

1. Whether the user also wants an MCP App widget.

Ask only for information that is missing. A sample input/output is preferred but not

mandatory when the user has supplied an equally precise contract.

Phase 1: Read the runtime and metadata contracts

Read:

${PLUGIN_ROOT}/references/codeful-tool-host-data-api.d.ts
${PLUGIN_ROOT}/samples/account-summary.tool.js
${PLUGIN_ROOT}/samples/account-summary.tool.json

The generated runtime is plain ESM JavaScript, and the sidecar is plain JSON. Type files

are generation-time references only and MUST NOT be imported by the output.

Phase 2: Verify Dataverse schema when needed

Skip this phase when the tool does not use Dataverse.

For a Dataverse-backed tool:

1. Confirm PAC CLI is authenticated to the intended environment.
2. Discover candidate tables:

   pac model list-tables --search "table terms"

--search is substring-based. Post-filter its output and accept a table only when its

logical name exactly matches the selected result. If multiple tables remain plausible,

ask the user to choose.

1. Create a unique temporary directory outside the final output path and generate types:

   pac model genpage generate-types --data-sources "logical1,logical2" --output-file "<temp>/RuntimeTypes.ts"

1. Read RuntimeTypes.ts. Extract the registered tables, exact readable/writable logical

columns, lookup shapes, choice names, and raw numeric choice values.

1. Use ONLY names and values verified in that file. Custom columns are unpredictable; do

not derive them from display names.

If discovery or type generation fails, stop and report the error. Do not fall back to

invented tables or columns. Delete the temporary types and directory after validation so

the final output contains only the requested .tool.js, .tool.json, and optional

widget files.

Phase 3: Generate the paired tool artifacts

Write <tool-name>.tool.js and <tool-name>.tool.json in the user's working directory

unless they requested another output directory. Both files MUST use the same basename,

which MUST equal the confirmed kebab-case tool name.

The JavaScript file MUST:

• Export exactly one MCP entry point named runTool, preferably:

  export async function runTool({ toolInput, dataApi }) {
    // complete implementation
  }

• Be self-contained JavaScript with no runtime imports, packages, network calls,

filesystem access, environment-variable access, or generated-type dependency.

• Validate all externally supplied toolInput before using it. Apply bounds to counts and

escape values interpolated into OData filters.

• Use singular Dataverse entity logical names. Use exact logical column names in select,

filter, orderBy, and row objects.

• Read choice and lookup labels from

"<column>@OData.Community.Display.V1.FormattedValue".

• Access query rows through page.rows. Follow page.loadMoreRows() only while

page.hasMoreRows is true and the function exists.

• Set lookups through the verified _<field>_value shape from RuntimeTypes.ts; never

emit raw Web API @odata.bind keys.

• Let dataApi failures throw. Catch only when adding useful context, and rethrow with the

original error as the cause. Never return a success-shaped fallback after a failed read

or write.

• Contain no placeholders, TODOs, ellipses, test credentials, or real environment IDs.
• Return JSON-serializable values only. Never return loadMoreRows, functions, class

instances, or cyclic objects.

• Emit telemetry only when the user explicitly asks for it, and never include tool inputs,

row contents, identifiers, or other user data in telemetry properties.

The JSON sidecar MUST be valid JSON with exactly these top-level fields:

{
  "name": "account-summary",
  "description": "Search accounts and return revenue and status summaries.",
  "annotations": {
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  },
  "inputSchema": {
    "type": "object",
    "properties": {}
  },
  "outputSchema": {
    "type": "object",
    "properties": {}
  }
}

• name: exactly the confirmed tool name and the shared file basename.
• description: concise, model-actionable guidance explaining what the tool does and when

to call it. Do not copy the user's prompt verbatim or include implementation details.

• annotations: MCP

ToolAnnotations

describing the tool's behavior. Always emit all four boolean hints:

• readOnlyHint: true only when the tool cannot modify Dataverse or any other state.
• destructiveHint: true when the tool may delete, overwrite, or otherwise cause a

destructive update. Set it to false for read-only tools and non-destructive creates

or additive writes.

• idempotentHint: true when repeated calls with the same valid input have no

additional effect. Reads, deterministic calculations, and updates that set the same

values are idempotent; creates and append-style operations are not.

• openWorldHint: always false because the codeful runtime cannot access arbitrary

external systems.

Infer these values from the generated implementation and requested behavior. If the

write semantics are genuinely ambiguous, ask before generating rather than guessing.

Treat annotations as advisory metadata, not as a substitute for runtime validation or

authorization.

• inputSchema: the complete JSON Schema for toolInput. Use an object root, list every

accepted field under properties, identify required fields with required, encode

runtime constraints such as bounds, formats, enums, and array item shapes, and set

additionalProperties: false unless the user explicitly requires extensible input.

• outputSchema: the JSON Schema for the model-visible structuredContent business

payload. For a plain-object return, describe the complete returned object because the

host promotes it to structuredContent. For an envelope return, describe only its

structuredContent property. Never include content, authored meta, or runtime

_meta in outputSchema.

Use standard JSON Schema keywords only. Do not include credentials, environment

identifiers, Dataverse discovery artifacts, host configuration, JavaScript expressions,

comments, or placeholders in the sidecar.

Result-channel contract

Choose the smallest correct result shape.

Simple structured result

Return a plain object when all useful output belongs in model-visible structured data:

return { records, totalCount: records.length };

The host promotes that object to MCP structuredContent.

Partitioned MCP result

Return an envelope when the channels have different audiences:

return {
  content: `Found ${records.length} records.`,
  structuredContent: { records },
  meta: { preferredView: "table" },
};

• content: model-visible conversational text, either a string or text content blocks.
• structuredContent: model-visible machine-readable object.
• meta: widget-only object. The host maps it to MCP _meta; widgets read result._meta.

The names content, structuredContent, and meta are reserved envelope keys. If a

business payload naturally has any of those keys, wrap the whole payload explicitly:

return { structuredContent: businessPayload };

Do not mix envelope keys with unrelated top-level business fields.

Phase 4: Validate

Before reporting completion:

1. Confirm exactly one final .tool.js and one matching .tool.json were created for

this skill.

1. Import the file as an ESM data URL with Node.js and assert that runTool is a function.

Importing MUST NOT execute data access or other top-level side effects.

1. Parse the sidecar with JSON.parse. Confirm it has exactly name, description,

annotations, inputSchema, and outputSchema; the name matches both filenames;

all four annotation hints are booleans, openWorldHint is false, the other hints

match the implementation's actual behavior, both schemas have object roots, and every

input constraint enforced by the runtime is represented in inputSchema.

1. Grep the output for imports, require, placeholders, guessed columns, and unsupported

host access.

1. When representative input/output was supplied, invoke runTool with an in-memory mock

dataApi from an inline Node script. Do not create a persistent test file.

1. Confirm the returned value matches the requested result contract, contains no

functions or non-serializable values, and its structured payload conforms to

outputSchema. Confirm the representative input conforms to inputSchema.

1. Delete all temporary schema artifacts.

Optional MCP App handoff

When the user asks for a widget:

1. Finish and validate the paired .tool.js and .tool.json first.
2. Build a representative result sample:

• Plain tool return -> treat it as structuredContent.
• Envelope return -> pass content, structuredContent, and _meta (renamed from the

authored meta field).

1. Invoke generate-mcp-app-ui with the visual requirements, tool name, input sample, and

representative full result. Forward an explicit CDN policy from the user's request.

If none was supplied, let the UI skill ask its required CDN-policy question; do not

assume public URLs are allowed.

1. Keep the outputs separate: one .tool.js, one .tool.json, and one single-file

.html using the selected CDN policy.

Refinement

When editing an existing codeful tool, read both paired files and change only the

requested behavior. Keep runtime validation and metadata schemas synchronized. Re-run

schema verification if the edit introduces a table, column, lookup, or choice value not

already verified for the file.

Completion response

State both generated tool file paths and summarize the description, tool annotations,

input contract, and structured result contract. If a widget was requested, also state the

HTML path and which result channels it consumes.