vealth

Put your safety credential on record (step 1 of 2)

prepare_credential_record

Read-onlyIdempotent

Some jobs, like the credentialed construction-safety jobs in Los Angeles, are open only to a person whose credential a human has checked. This is how a CHST or STS (BCSP) gets on record. FREE, a signed statement, no fee, no gas, no money moves. You give the issuer (BCSP), the credential (CHST or STS), the certificate number exactly as the issuer shows it, your name exactly as the issuer's lookup shows it, and the expiry date if your certificate has one. The record lands PENDING: a person then reads the issuer's public lookup and marks it checked or not found, and nothing on this server can do that for you. Only a checked record inside its dates opens a credentialed job, and it never meets a job's separate need for the site's own authorization. The certificate number and the name stay private; never send a phone number, an email or an address. Returns MESSAGE_TO_SIGN and BODY_JSON; sign with that wallet's personal_sign, then call submit_credential_record within 5 minutes. Cost and signer: free, no gas; the person signs the result with their own wallet or passkey, and the house never holds a key.

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": {
      "workerWallet": "<workerWallet>",
      "issuer": "<issuer>",
      "credential": "<credential>",
      "certificateNumber": "<certificateNumber>",
      "holderName": "<holderName>"
    },
    "name": "prepare_credential_record"
  }
}

Input Schema

Name	Required	Description
`issuer`	Yes	The body that issued the credential. Today: BCSP.
`expiresOn`	No	Optional: the date the certificate runs out, as YYYY-MM-DD. Leave out if it shows none.
`credential`	Yes	The credential. Today: CHST or STS.
`holderName`	Yes	Your name exactly as the issuer's lookup shows it. A person matches it against that lookup; it is kept private.
`workerWallet`	Yes	The 0x… address that signs. Address only, never a private key.
`certificateNumber`	Yes	The number printed on the certificate, exactly as the issuer's lookup shows it. Never a phone number or an email.

Output Schema

Name	Required	Description	Default
`ok`	No
`tool`	No
`funded`	No
`payUsd`	No
`workId`	No
`claimId`	No
`claimable`	No
`next_call`	No
`proofRule`	No
`fulfillableBy`	No
`definitionOfDone`	No
`needs_from_caller`	No
`notClaimableReason`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the human-review gate (record lands PENDING, a person checks the issuer's public lookup, the server cannot do it), privacy constraints (certificate number and name stay private; never send phone, email, or address), the 5-minute signing window, and that the tool is free with no gas and no key custody. The 'record lands PENDING' phrasing is a slight ambiguity next to readOnlyHint, but the 'Returns MESSAGE_TO_SIGN and BODY_JSON' line makes clear this step prepares rather than persists.

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

Conciseness3/5

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

The flow, privacy rules, and follow-up step are front-loaded and useful, but cost is stated twice ('FREE, a signed statement, no fee, no gas, no money moves' then 'free, no gas'), and the opening job-market framing runs long before the action is named. Some sentences could be merged without losing information.

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

Completeness5/5

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

For a 6-parameter prepare step with an output schema and full annotation coverage, the description supplies everything an agent needs: purpose, prerequisites, the signing handoff, timing, privacy boundaries, and the pending-review consequence. No material gap remains for correct invocation.

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 description coverage is 100% and each parameter already documents its format and privacy handling, so the schema does the heavy lifting. The description adds modest value by restating the 'exactly as the issuer shows it' matching rule and the optional nature of expiry, but nothing about syntax or edge cases beyond what the schema provides.

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 names a specific verb and resource — getting a CHST or STS (BCSP) credential 'on record' — and the title fixes it as step 1 of 2. It explicitly routes to the sibling that completes the flow (submit_credential_record) and states the return payload (MESSAGE_TO_SIGN and BODY_JSON), so an agent can tell exactly what this call produces.

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 the triggering condition (credentialed construction-safety jobs in Los Angeles open only to human-checked credentials), the required follow-up (sign with personal_sign, then call submit_credential_record within 5 minutes), and an explicit exclusion ('it never meets a job's separate need for the site's own authorization'). Little is left to inference.

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

All vealth 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?