Equitest

Send a valuation or cap table to investors

send_to_investors

Emails a valuation report (a tracked Deal Room link) or a cap table (a viewer invitation) to investor contacts, from " via Equitest" with replies going to the user. Two steps: call first WITHOUT confirmed to get a preview (recipients, skipped contacts, subject, message, daily limit) and show it to the user; call again with confirmed=true only after the user explicitly approves that exact preview. Limit 25 emails a day.

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": {
      "share_type": "<share_type>",
      "share": "<share>",
      "recipients": "<recipients>",
      "subject": "<subject>",
      "message": "<message>"
    },
    "name": "send_to_investors"
  }
}

Input Schema

Name	Required	Description
`days`	No	Link validity in days
`share`	Yes	Company name or id of the valuation (own valuations) or of the cap table (owner or editor)
`message`	Yes	Plain text body; the link is added below it
`subject`	Yes
`confirmed`	No	true only after the user approved the preview
`recipients`	Yes	Investor contacts by email, name or contact id (from list_investor_contacts)
`share_type`	Yes
`require_nda`	No	Valuations: the recipient accepts an NDA before viewing

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations establish the write/open-world/non-idempotent profile, and the description adds substantial context beyond that: sender identity ("<user> via Equitest"), reply-to routing to the user, the two-step preview-then-confirm protocol, the contents of the preview (recipients, skipped contacts, subject, message, daily limit), and the 25/day cap. These are exactly the behavioral facts an agent needs before triggering an irreversible external email.

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?

Effectively three sentences: what it sends, how replies route, and the mandatory two-step flow, with the operational limit front-loaded at the end as a constraint. Dense and purposeful, though the second and third sentences are long compound constructions that could be split for faster scanning.

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 high-stakes outbound-email tool with no output schema, the description still explains what the confirmation step returns (the preview contents) and what constraints apply (daily limit, reply routing, sender identity). Combined with the partially documented schema, an agent has everything needed to call this safely in the correct two-step order.

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 75%, and the description adds meaning the schema does not: confirmed is tied to an explicit approval workflow on an exact preview, share_type determines the delivery mechanism (tracked link vs. viewer invitation), and the cap of 25 emails/day contextualizes the recipients maxItems of 25. The days and require_nda parameters are left to the schema, which is acceptable at this coverage level.

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?

Uses a specific verb plus two clearly separated resources: emails a valuation report as a tracked Deal Room link, or a cap table as a viewer invitation. This distinguishes the two share_type branches without the agent needing to open the enum, setting it apart from siblings like add_cap_table_stakeholder or list_investor_contacts.

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 explicit when-to-call guidance for both modes: call first without confirmed to get a preview, call again with confirmed=true only after explicit user approval of that exact preview. The daily limit of 25 is also stated. The only gap is that it does not name any sibling alternatives (e.g. find_investors or list_investor_contacts for sourcing recipients).

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

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