generate-codeful-mcp-tool

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.

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.

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:

   Copy

   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:

   Copy

   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.

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:

  Copy

  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.

Choose the smallest correct result shape.

Before reporting completion:

1. Confirm exactly one final .tool.js and one matching .tool.json were created for this skill.
2. 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.
3. 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.
4. Grep the output for imports, require, placeholders, guessed columns, and unsupported host access.
5. 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.
6. 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.
7. Delete all temporary schema artifacts.

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).
3. 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.
4. Keep the outputs separate: one .tool.js, one .tool.json, and one single-file .html using the selected CDN policy.

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.

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.