Skip to main content
Glama

Signed

by com.signed.mcp
OverviewDiscussionsAdmin

create_pitch

Add a deal to the authenticated user's pipeline: a company they've been pitched but haven't invested in. Give a name and/or a domain — a domain alone is enough, and the name is derived from it. New deals land in triage unless you pass a stage. Use this for a deal being considered; a company money has actually gone into is create_transaction's job instead. To record what you learned on the call, follow with create_note: notes on a pipeline deal feed the same analysis the deck does.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoWebsite URL, if it differs from the domain's homepage.
nameNoCompany name. Derived from the domain when omitted.
domainNoCompany website or domain ("https://acme.com/about" and "acme.com" both work). Strongly recommended — it's how the deal is deduped against what's already in the account, and what the logo comes from.
revenueNoAnnual revenue / ARR, in the company's currency.
taglineNoOne line on what the company does.
currencyNoISO 4217 code the round is priced in (EUR, GBP, CHF…), as the deck states it; don't convert. Defaults to your home currency, or to a currency sign on the economics ("€5M").
deck_urlNoLink to the pitch deck, if the founder sent one.
deal_stageNoWhere the deal starts. Defaults to `triage` — the queue of deals not yet looked at.
raising_amountNoTotal size of the round being raised, in the company's currency.
discount_percentNoDiscount the SAFE or note offers on the next round's price, in percentage points (20 means 20%).
raised_previouslyNoTotal raised across all prior rounds, in the company's currency.
raised_this_roundNoCommitted so far in this round, in the company's currency.
raising_at_valuationNoValuation the current round is being raised at, in the company's currency.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / currency
      Added value: +{
+  "description": "ISO 4217 code the round is priced in (EUR, GBP, CHF…), as the deck states it; don't convert. Defaults to your home currency, or to a currency sign on the economics (\"€5M\").",
+  "type": "string"
+}
    • changedInput schema / properties / raised_previously / description
      Previous value: -"Total raised across all prior rounds, USD."New value: +"Total raised across all prior rounds, in the company's currency."
    • changedInput schema / properties / raised_this_round / description
      Previous value: -"Committed so far in this round, USD."New value: +"Committed so far in this round, in the company's currency."
    • changedInput schema / properties / raising_amount / description
      Previous value: -"Total size of the round being raised, USD."New value: +"Total size of the round being raised, in the company's currency."
    • changedInput schema / properties / raising_at_valuation / description
      Previous value: -"Valuation the current round is being raised at, USD."New value: +"Valuation the current round is being raised at, in the company's currency."
    • changedInput schema / properties / revenue / description
      Previous value: -"Annual revenue / ARR, USD."New value: +"Annual revenue / ARR, in the company's currency."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=false, so the safety profile is covered. The description goes beyond them by disclosing the default landing stage ('New deals land in triage unless you pass a stage') and dedup behavior ('it's how the deal is deduped against what's already in the account'), which is genuinely useful operational context for a creation 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?

Purpose and the domain rule are front-loaded, and the routing/alternatives come after, which is the right order. It is a little dense (five sentences), and the closing rationale about notes feeding 'the same analysis the deck does' is slightly beyond what the agent needs to invoke the tool, but nothing 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 a 13-parameter, zero-required creation tool with annotations and no output schema, the description covers purpose, required-vs-optional input logic, default stage, dedup behavior, and sibling routing. Return-value behavior is not described, but no output schema exists and the create semantics make the outcome predictable.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning on the name/domain relationship — 'a domain alone is enough, and the name is derived from it' — clarifying that the no-required-param setup still needs a domain to dedupe. It does not cover the numerous financial parameters, but the schema already does that at full coverage.

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?

States a specific verb and resource ('Add a deal to the authenticated user's pipeline') and immediately scopes it with a precise qualifier ('a company they've been pitched but haven't invested in'). It explicitly names the sibling it is not (create_transaction), so an agent can distinguish it from the transaction/note tools without opening any schema.

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?

Gives an explicit when-to-use ('a deal being considered') and when-not ('a company money has actually gone into is create_transaction's job instead'), plus a follow-up recommendation (create_note) with the reason. Routing between the three siblings is unambiguous.

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

All Signed 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