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
• Known-good tool: account-summary.tool.js
• Known-good metadata: account-summary.tool.json
• Widget generation: generate-mcp-app-ui

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.
2. 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.
3. The expected result, preferably as a representative output object.
4. Whether it reads or writes Dataverse, the requested tables in business terms, and whether any write creates, appends, updates, overwrites, or deletes state.
5. 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.

3. 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"

4. Read RuntimeTypes.ts. Extract the registered tables, exact readable/writable logical columns, lookup shapes, choice names, and raw numeric choice values.

5. 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.