Skip to main content
Glama
parmarnaresh86

SAP Business One Order-to-Cash MCP Server

query_sql_direct

Run read-only T-SQL SELECT queries directly on SAP B1 SQL Server, bypassing Service Layer for complex joins or when Service Layer fails. Get data across tables with aggregations.

Instructions

Run a read-only T-SQL SELECT directly against a SAP B1 SQL Server database, bypassing Service Layer entirely. Use this when Service Layer is unavailable/misconfigured for a company, or when a question needs a join/aggregation across tables that's awkward via OData. Requires MSSQL_HOST, MSSQL_DATABASE, MSSQL_USER, MSSQL_PASSWORD (and MSSQL_INSTANCE for a named instance like SERVER\SQLEXPRESS01) to be set in this connector's environment — if not configured, this tool will error saying so. Multiple companies can live on the same SQL Server instance — pass "database" to target a specific one instead of the connector's default. Known databases on this server: DC_LiveDB — Dewang Corporation NCPL_110126 — Neshiel Agrochem Pvt Ltd NC_LIVE — Neshiel Corporation NOCPL_LIVE — Neshiel Ventures Private Limited Only SELECT statements are allowed; anything else is rejected.

SAP Business One key tables (T-SQL / MSSQL):

SALES & QUOTATIONS: OQUT(DocEntry,DocNum,CardCode,CardName,SlpCode,DocDate,DocDueDate,DocTotal,GrossProfit,DocStatus,Comments) QUT1(DocEntry,LineNum,ItemCode,Dscription,Quantity,Price,LineTotal,WhsCode,GrssProfit) ORDR(DocEntry,DocNum,CardCode,CardName,SlpCode,DocDate,DocDueDate,DocTotal,GrossProfit,DocStatus,Comments) RDR1(DocEntry,LineNum,ItemCode,Dscription,Quantity,Price,LineTotal,WhsCode,GrssProfit)

AR INVOICES & DELIVERY: OINV(DocEntry,DocNum,CardCode,CardName,SlpCode,DocDate,DocDueDate,DocTotal,GrossProfit,PaidToDate,DocStatus) INV1(DocEntry,LineNum,ItemCode,Dscription,Quantity,Price,LineTotal,WhsCode,GrssProfit) ODLN(DocEntry,DocNum,CardCode,CardName,DocDate,DocTotal,DocStatus) DLN1(DocEntry,LineNum,ItemCode,Dscription,Quantity,Price,LineTotal,WhsCode) ORIN(DocEntry,DocNum,CardCode,CardName,DocDate,DocTotal,DocStatus) RIN1(DocEntry,LineNum,ItemCode,Dscription,Quantity,LineTotal,WhsCode)

PURCHASING: OPQT(DocEntry,DocNum,CardCode,CardName,DocDate,DocTotal,DocStatus) PQT1(DocEntry,LineNum,ItemCode,Dscription,Quantity,Price,LineTotal,WhsCode) OPOR(DocEntry,DocNum,CardCode,CardName,DocDate,DocDueDate,DocTotal,DocStatus) POR1(DocEntry,LineNum,ItemCode,Dscription,Quantity,Price,LineTotal,WhsCode) OPDN(DocEntry,DocNum,CardCode,CardName,DocDate,DocTotal,DocStatus) PDN1(DocEntry,LineNum,ItemCode,Dscription,Quantity,Price,LineTotal,WhsCode) OPCH(DocEntry,DocNum,CardCode,CardName,DocDate,DocDueDate,DocTotal,DocStatus) PCH1(DocEntry,LineNum,ItemCode,Dscription,Quantity,Price,LineTotal,WhsCode)

INVENTORY: OITM(ItemCode,ItemName,ItmsGrpCod,InvntItem,SellItem,PrchseItem,OnHand,IsCommited,OnOrder,LastPurPrc,AvgPrice) OITW(ItemCode,WhsCode,OnHand,IsCommited,OnOrder) OWHS(WhsCode,WhsName,Street,City) OITB(ItmsGrpCod,ItmsGrpNam)

BUSINESS PARTNERS: OCRD(CardCode,CardName,CardType,GroupCode,Phone1,E_Mail,CntctPrsn,Balance,SlpCode,Territory) OSLP(SlpCode,SlpName,Memo,Commission,Phone,Email) OCRG(GroupCode,GroupName,GroupType)

FINANCE: OJDT(TransId,TransType,RefDate,Memo,Ref1,Ref2,Ref3,CreatedBy) JDT1(TransId,Line_ID,Account,Debit,Credit,SYSDebit,SYSCredit,FCDebit,FCCredit,RefDate,LineMemo,ContraAct) OACT(AcctCode,AcctName,GroupMask,ActType,Blocked,CurrTotal,LocTotal)

STATUS CODES: DocStatus = 'O' (Open) | 'C' (Closed) | 'W' (Cancelled) CardType: 'C' (Customer) | 'S' (Supplier) | 'L' (Lead)

NCPL_110126 SALES ORDER BROKERAGE — field names verified against live data, do not substitute others: RDR1.U_Brok_Seller = Seller Brokerage Rate (numeric, per-unit, e.g. rupees per Ton) RDR1.U_Brok_Buyer = Buyer Brokerage Rate (numeric, per-unit) RDR1.U_Sel_Brok_AP = basis flag (observed value "Amount" = the rate above is a flat per-unit amount, not a percentage) Do NOT use U_S_BrokPerQty, U_Seller_Brok_Per, or U_SPLRBT — these are unused/always NULL in this database and will silently produce wrong or zero results. If U_Brok_Seller or U_Brok_Buyer is NULL, treat as zero unless told otherwise.

Calculation: Seller Brokerage Amount = RDR1.Quantity * RDR1.U_Brok_Seller Buyer Brokerage Amount = RDR1.Quantity * RDR1.U_Brok_Buyer Total Brokerage = Seller Brokerage Amount + Buyer Brokerage Amount

A brokerage query/report should join ORDR (DocEntry, DocNum, DocDate, CardCode, CardName) to RDR1 (ItemCode, Dscription, Quantity, Price, LineTotal, U_Brok_Seller, U_Brok_Buyer) on DocEntry, and return both rates and both calculated amounts plus Total Brokerage per line. SAP B1's financial year is April-March — "April 2026" means DocDate between 2026-04-01 and 2026-04-30 unless the user says otherwise.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesA single T-SQL SELECT statement
databaseNoDatabase to query, e.g. NCPL_110126, NC_LIVE, DC_LiveDB, NOCPL_LIVE. Omit to use this connector's default (MSSQL_DATABASE).
Behavior5/5

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

With no annotations provided, the description carries the full transparency burden, and it delivers: it states the tool is read-only, rejects anything besides SELECT, errors when environment config is missing, and even warns about unused/UDF fields that could silently produce wrong results. This is unusually candid about failure modes and data caveats.

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?

The definition is long, but it is logically structured and front-loaded: core purpose and usage come first, followed by environment requirements, database list, table/column references, and a domain-specific brokerage section. It is not concise in volume, but most content earns its place as a working reference for composing correct SQL.

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 no output schema or annotations, the description is impressively complete: it covers invocation, target databases, allowed statements, environment prerequisites, key table schemas, and even field-level caveats. It omits result-format details, row limits, and timeout/performance behavior, which would make it fully complete for an unconstrained direct-SQL tool.

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 the baseline is 3. The description adds real value beyond the schema by clarifying that 'database' overrides the connector default, providing concrete database names, and emphasizing that 'query' must be a single SELECT statement. It doesn't radically expand query semantics, but it enriches both parameters usefully.

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 opens with a precise verb-resource-scope statement: 'Run a read-only T-SQL SELECT directly against a SAP B1 SQL Server database, bypassing Service Layer entirely.' This distinguishes it from sibling tools like call_service_layer and query_hana_direct, and the 'Only SELECT statements are allowed' clause further nails its exact role.

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?

It gives explicit conditions for use: when Service Layer is unavailable/misconfigured, or when a join/aggregation is awkward via OData. It also documents required environment variables, how to target a specific database, and lists known databases, giving an agent everything needed to decide when this tool beats its alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/parmarnaresh86/AgentSphere-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server