MCC Solutions

Open a business account for a firm

register_firm_account

For a law firm, title or escrow company, lender, property manager, employer, HR or other business whose person asked you to open an MCC Solutions business account for them (notary, loan signings, apostilles, process serving, court runs and records). Opens the account with their consent; they confirm by email and the desk approves it, usually within one business day. After approval a user creates an agent key in the client portal so you can place orders. Net-30 invoicing is by owner approval. Nothing is charged.

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": {
      "company": "<company>",
      "name": "<name>",
      "email": "<email>",
      "consent": "<consent>"
    },
    "name": "register_firm_account"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The person's name
`email`	Yes	Their work email
`phone`	No
`states`	No	States they need work in
`volume`	No	Rough jobs per month
`company`	Yes
`consent`	Yes	true when the person asked you to open the account and agreed to MCC emailing them
`services`	No	What they expect to order
`firm_type`	No	e.g. law firm, title company, lender, property manager, employer
`wants_net30`	No
`billing_email`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the annotations by describing the full lifecycle: consent-based submission, email confirmation by the contact, desk approval typically within one business day, agent-key creation in the client portal before ordering, and net-30 invoicing gated on owner approval. It also states 'Nothing is charged,' which is important reassurance for a non-read-only, non-destructive write tool.

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 eligibility gate and consent condition are front-loaded, and the approval/invoicing flow follows in a compact sequence. The first sentence is dense with a parenthetical service list but remains readable; little wording is wasted.

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 an 11-parameter write tool with no output schema, the description covers prerequisites, approval timing, and post-approval next steps. It omits what the call returns (e.g., account identifier) and what happens if an account already exists, which matters given idempotentHint=false.

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?

At 64% schema coverage the schema documents most fields, and the description only adds meaning to a few: consent (tied to the person confirming by email), wants_net30 (owner approval), and firm_type (via the entity list). Fields like phone, states, volume, and billing_email get no additional guidance in the description.

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?

States a specific verb and resource ('open an MCC Solutions business account') and enumerates eligible entity types (law firm, title/escrow, lender, property manager, employer), plus the service scope the account is for. It does not name the sibling firm_account, so the distinction between opening an account and viewing an existing one is left implicit.

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

Usage Guidelines4/5

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

Gives a clear triggering condition: use this when a business person has asked you to open an account on their behalf, with their consent. It does not state when not to use it or point to firm_account for existing accounts, but the usage context is unambiguous.

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

All MCC Solutions tools Inspect

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

Need Help?