IRIS MCP Blueprint

register_web_application

Create or update a CSP web application to expose an HTTP-based Business Service, like EnsLib.REST.GenericService, for development with unauthenticated access.

Instructions

Create or update a CSP web application that exposes an HTTP-based Business Service (typically EnsLib.REST.GenericService) to the outside world.

Delegates to the ObjectScript helper because 'Security.Applications' requires switching to the %SYS namespace, which is cleaner to do in ObjectScript than over the Native SDK.

Authentication is set to Unauthenticated for development convenience. Tighten this before going to production.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "register_web_application"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes	URL path of the web app (must start with '/'), e.g. '/rest/user/queryservice-rest-bs' or '/csp/myapp/api' depending on Security.Applications registration.
`dispatch_class`	No	Class that handles incoming requests. Defaults to 'EnsLib.REST.GenericService' which forwards everything to the Business Service whose config name appears next in the URL.	EnsLib.REST.GenericService
`description`	No	Free-text description shown in the Management Portal.	REST endpoint exposed via the MCP blueprint
`namespace`	No	Target namespace. If empty, uses the namespace of the current MCP connection.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.4Jun 12, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses important behaviors: delegation to ObjectScript helper for namespace switching, default authentication setting (Unauthenticated) with a production security warning, and default dispatch class. However, it does not specify if the operation is idempotent or any other side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three sentences) and well-structured, front-loading the purpose, then providing technical detail. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema (context signal) and high schema coverage, the description is fairly complete. It covers purpose, technical implementation details, and security caveats. One could argue for more detail on error conditions or rollback, but it's adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes all parameters. The description adds no additional meaning beyond what is in the schema (e.g., no extra context for path, namespace, etc.). Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create or update') and the resource ('CSP web application'), with specific detail about exposing an HTTP-based Business Service. It distinguishes from siblings like 'remove_web_application'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for registering web applications for Business Services but does not explicitly state when to use or avoid this tool over alternatives. No guidance on when not to use it (e.g., for non-Business Service apps).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.