Skip to main content
Glama
Sign In
b1-mcp-server

b1-mcp-server

by Anand95r
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

execute_service_layer_write

Performs guarded OData PATCH, POST, or DELETE writes to the connected SAP Business One Service Layer, enforcing database and method checks plus approval.

Instructions

Execute a guarded OData write (PATCH, POST or DELETE) against the currently connected SAP Business One Service Layer. These are real writes to the company database.

The verb must be in the connected profile's slAllowedMethods, and database must equal the connected Service Layer database exactly — connect_database prints both. A mismatch is denied.

Approval follows the profile's slWriteApproval, also printed by connect_database. "elicitation" (default): the server asks the user through an MCP approval form; clients without form elicitation cannot write. "client" or "none": the server executes after this client's own permission prompt, honoured only for Claude Code. On a "none" profile, prefer execute_service_layer_write_unattended, which does the same write without any approval; use this tool there only when the user asks to confirm the write. MCP_DRY_RUN previews but never executes a write, and MCP_SL_WRITES_ENABLED=false disables every write globally.

PATCH and DELETE accept one directly keyed entity endpoint only. POST accepts an entity set, a service operation, or one action on a keyed entity (Orders(12)/Close). Query options, navigation paths, absolute URLs, Login/Logout and $batch are denied.

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": {
      "database": "<database>",
      "method": "<method>",
      "url": "<url>"
    },
    "name": "execute_service_layer_write"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesRelative OData endpoint without the configured /b1s/v1/ or /b1s/v2/ root
bodyNoJSON object: required and non-empty for PATCH, optional for POST, forbidden for DELETE
methodYesMust also be allowed by the connected profile's slAllowedMethods
databaseYesConnected company database exactly as connect_database prints it; shown to the approver and checked by the server

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it states these are real writes to the company database, that method and database are server-verified against the connected profile, and how each approval mode (elicitation/client/none) behaves, including that clients without form elicitation cannot write at all.

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

Conciseness4/5

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

Purpose is front-loaded and the write-is-real warning precedes the mechanics, with every sentence carrying operational weight. The approval-mode paragraph is dense and packs several conditional clauses into one block, which costs some readability but no sentence is filler.

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?

For a no-annotation mutation tool with four parameters, the description covers preconditions, denial cases and global kill switches exceptionally well. The one gap is the response: no output schema exists and the description says nothing about what a successful write returns, which matters for a POST/PATCH where the agent may need the created or updated entity.

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

Parameters4/5

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

Schema coverage is 100%, so 3 is the floor; the description earns more by constraining the url parameter beyond the schema (query options, navigation paths, absolute URLs, Login/Logout and $batch are denied, and PATCH/DELETE accept only a keyed entity endpoint). It reinforces that method must appear in slAllowedMethods and that database must match exactly, though body-shape rules are left to the schema.

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 first sentence names a specific verb (execute), the exact resource (guarded OData write: PATCH/POST/DELETE) and the target system (SAP Business One Service Layer). It also distinguishes itself from the sibling execute_service_layer_write_unattended by name, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Explicit routing rules are given: on a "none" approval profile prefer execute_service_layer_write_unattended and use this tool only when the user asks to confirm the write. It also names connect_database as the source of truth for the allowed-methods and database values, and states that MCP_DRY_RUN / MCP_SL_WRITES_ENABLED suppress execution.

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

Deploy Server

Other Tools