Skip to main content
Glama
Sign In

Saybooks

by io.github.alviso
OverviewDiscussionsAdmin

Company profile

core_set_company_profile

The business's own identity: seller block, tax id, payment instructions, country, currencies, tax scheme, numbering. One per workspace. The invoice document's seller comes from here — a document without it is incomplete, not wrong (INV-22). Patch semantics: only the fields you pass change; the name is required only the first time. Effects: company profile written.

Input Schema

NameRequiredDescriptionDefault
nameNoLegal or trading name, as it should appear on documents.
tax_idNoEIN / VAT id — printed on documents where present.
addressNoPostal address, as it should print.
countryNoWhere the business is, ISO 3166 two letters (US, NZ, CZ, HU). Sets how dates and amounts print.
currencyNoDefault billing currency, ISO 4217 (USD, NZD, CZK, EUR). Every invoice carries one; this is the one proposed.
tax_labelNoWhat the tax is called on documents: GST, VAT, Sales tax, ÁFA, DPH.
currenciesNoEvery currency this business bills in, comma-separated (e.g. "USD, CZK"). An invoice may carry any of these and no other.
footer_noteNoOne line at the document foot (returns policy, thanks, registration no).
tax_rate_bpNoDefault tax rate in basis points (1500 = 15%). Applied to every line unless the line says otherwise. Only meaningful when registered.
tax_id_labelNoHow the tax id is captioned on documents: GST No., IRD number, VAT ID, EIN. Defaults to "Tax ID".
number_formatNoInvoice numbering. Tokens: {NNNN} the sequence (width = number of Ns), {YYYY} or {YY} the year of issue. Default INV-{NNNN}; INV-{YYYY}-{NNN} restarts each year.
tax_registeredNoRegistered for the tax (GST/VAT)? Pass it explicitly either way — false is an answer, the setup checklist stays open until one is given. Unregistered businesses cannot put tax on a line; registered ones print TAX INVOICE and their tax id.
payment_instructionsNoHow customers pay: bank details, reference format. Printed on every invoice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, non-open-world mutation, so the description's main added value is the patch behavior and conditional first-time name requirement. It also states the effect explicitly as 'company profile written,' but does not cover permissions, validation failures, or whether changes are reversible.

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 definition is compact and front-loaded: identity first, invoice dependency second, patch semantics third, and effect last. Every sentence contributes useful information without repetition or 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 13-parameter mutation with full schema descriptions and mutation/safety annotations, the description covers the essential context: what the profile is, its invoice dependency, and partial-update behavior. It is slightly incomplete around permissions, error behavior, and how this relates to sibling profile/logo/setup tools.

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 parameter descriptions already carry most semantics. The tool description still adds useful meaning beyond the schema by explaining patch semantics for all fields and that name is required only on first setup.

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

Purpose4/5

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

The description clearly identifies the resource as the business's own company profile and lists the identity areas it controls: seller block, tax id, payment instructions, country, currencies, tax scheme, and numbering. It does not explicitly state a verb like set/update in the first sentence and does not directly distinguish itself from the sibling read tool core_company_profile, so it falls short of a 5.

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?

It gives useful invocation context: one profile per workspace, patch semantics, and that name is required only the first time. However, it does not explicitly say when to use this tool versus core_company_profile or related setup tools, nor does it provide exclusions or alternatives.

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

All Saybooks toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources